> For the complete documentation index, see [llms.txt](https://experience-digital-transform.gitbook.io/experience-digital-transformation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://experience-digital-transform.gitbook.io/experience-digital-transformation/ai-wallet-use-case/chapter-03-the-ai-integration-assistant.md).

# Chapter 03: The AI Integration Assistant

AI-Enabled GovBuild Education Wallet Building Block

This chapter explains the AI Integration Assistant in detail. Chapter 1 established why provider-published, agent-agnostic skill files are the right tool to absorb the integration work of adopting wallets; Chapter 2 defined the standards stack, the wallet provider's OpenAPI surface, and the validation boundaries the skill files target. This chapter shows the mechanism working: the architecture of the Skills Marketplace that delivers the assistant, the skills that wallet providers publish to it, the two workflows through which providers list and implementers adopt, and the governance that makes AI-generated artefacts trustworthy. A working implementation of everything described here is deployed and staged at <https://giga-marketplace.assembly.govstack.global/>

## 3.1 The AI Integration Assistant Architecture

#### 3.1.1 What the assistant is

The AI Integration Assistant is not a single application operated by one vendor. It is the combination of three separable parts introduced in Chapter 2 (Section 2.4.5): the provider-published skill file, the AI coding agent, and the underlying model held together by a fourth: the Skills Marketplace, the distribution and governance layer where skills are published, vetted, versioned, discovered, and installed. An implementer's "assistant" is therefore whatever agent and model they already trust, loaded with skills drawn from the marketplace. The marketplace is what turns a collection of skill files into an ecosystem: it gives every provider the same route to implementers and every implementer the same assurance that what they install has been checked.

The actor at the centre is a system integrator with domain skills. Their workflow is deliberately short: install the skills from the chosen provider or providers; use the skills and prompts to bring the usecase in and apply the provider's capabilities to it; check the results against a real wallet; adopt what passes. Everything in this chapter serves that loop.

Five actors operate this loop:

<table data-header-hidden><thead><tr><th width="125.33331298828125"></th><th></th></tr></thead><tbody><tr><td>Actor</td><td>Responsibility</td></tr><tr><td>Wallet provider</td><td>Authors, publishes and maintains the skills for its own products (Section 3.1.4).</td></tr><tr><td>Marketplace operator</td><td>Runs the catalogue and holds the governance roles, reviewer and super admin (Section 3.3.3).</td></tr><tr><td>System integrator</td><td>Installs the skills, runs the agent, and owns the generated application and its repository.</td></tr><tr><td>Reviewing engineer</td><td>Approves every AI-generated artefact before it becomes a deliverable (Sections 3.2.1 and 3.3.4).</td></tr><tr><td>Developer</td><td>Builds and submits showcase applications (Section 3.1.3).</td></tr></tbody></table>

The assistant itself is not an actor: it is the composition of an agent, a model, and installed skills that the integrator operates. The credential-journey actors, the student, guardian, registration officer, registrar and relying parties, remain as defined in Chapter 1 (Section 1.2.2), and this chapter uses "integrator" for the person driving the build.

<img src="https://95341731-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FDXDTZNhGJPQlyqg12XmE%2Fuploads%2FF1JukX8FNsrH8YnlSJbX%2Funknown.png?alt=media&amp;token=734c7109-5923-49cf-8f89-42cba2589d3a" alt="Figure 3.1. The AI Integration Assistant: providers publish vetted skills to the marketplace; the integrator installs them into the agent and model of their choice to generate the education application." height="291" width="605">

#### 3.1.2 Block architecture of the Skills Marketplace

The marketplace platform separates the public catalogue from the web application by an HTTP API, so the two can be deployed and scaled independently. Its components are:

<table data-header-hidden><thead><tr><th width="117.3333740234375"></th><th width="236.3333740234375"></th><th></th></tr></thead><tbody><tr><td>Component</td><td>Role</td><td>Implementation</td></tr><tr><td>Web application</td><td>The public marketplace and showcase, plus a role-based admin dashboard: Provider Console, Governance Console, and Developer Console.</td><td>Next.js web app with branding; server-rendered catalogue pages.</td></tr><tr><td>Marketplace service</td><td>Owns public catalogue reads, item details, and the internal skill-context API that agents and the web app consume.</td><td>Standalone Node service exposing an HTTP API (API health check endpoint, catalogue, item endpoints).</td></tr><tr><td>Datastore</td><td>Catalogue items and versions, organisations, accounts and roles, the review queue, and the audit log.</td><td>PostgreSQL as the only datastore. A UUID keys every row, so identifiers are opaque and non-enumerable wherever they appear.</td></tr><tr><td>Deployment</td><td>Each deployable ships as a container image; the full stack runs with Docker Compose in development and Helm on Kubernetes in the sandbox.</td><td>Covered in Chapter 5 (Cloud Deployment).</td></tr></tbody></table>

Catalogue URLs name the provider that owns each item, so provenance is visible in the address itself:

<table data-header-hidden><thead><tr><th width="397.33331298828125"></th><th></th></tr></thead><tbody><tr><td>Path</td><td>Page</td></tr><tr><td>/marketplace/&#x3C;provider></td><td>Provider detail</td></tr><tr><td>/marketplace/&#x3C;provider>/&#x3C;source>/&#x3C;skill></td><td>Skill detail</td></tr><tr><td>/marketplace/&#x3C;provider>/&#x3C;source>/&#x3C;skill>/review</td><td>Public review and assurance trail</td></tr><tr><td>/providers/&#x3C;provider>/usecases/&#x3C;usecase></td><td>Use-case detail</td></tr><tr><td>/&#x3C;provider>/.well-known/skills/index.json</td><td>Agent Skills discovery index</td></tr></tbody></table>

The .well-known discovery index matters for agents: an AI coding agent pointed at a provider can enumerate that provider's published skills mechanically, without scraping web pages. Bare /skill/\<slug> and /usecase/\<slug> paths redirect to the canonical provider-scoped URL, because a slug often travels alone - in a manifest's uses\_skills list, a showcase entry, or an agent prompt.

Current implementation and reference architecture: The Skills Marketplace currently implements the core workflow described in this chapter: skills are published from public GitHub repositories, pinned to a source commit, assessed through automated checks and human review, and made available for installation in a compatible AI integration assistant. The reference architecture can be extended with additional assurance and localisation controls, including skill-specific conformance suites, publisher-signed bundles, country-specific schema and rulebook overlay.

#### 3.1.3 What the catalogue holds: skills, usecases, and applications

<table data-header-hidden><thead><tr><th width="90"></th><th width="325"></th><th></th></tr></thead><tbody><tr><td>Catalogue object</td><td>What it is</td><td>How it is submitted</td></tr><tr><td>Skill</td><td>A provider capability: a SKILL.md bundle plus openapi/, schemas/, rulebooks/, and examples/ directories, exactly as specified By naming a public GitHub repository from the Provider Console: every directory holding a SKILL.md becomes one skill, pinned to a chosen commit, tag, or branch head.ied in Chapter 2 (Section 2.6.1).</td><td>From the Provider Console, file by file or as a single .zip.</td></tr><tr><td>Usecase</td><td>A journey-tagged prompt chain: the prerequisites an app builder needs, plus one or more journeys, where each journey carries agent prompts that each reference their own skills.</td><td>Authored from a form in the Provider Console.</td></tr><tr><td>Application</td><td>A developer showcase: title, description, demo video, and the skills or usecases used to build it.</td><td>From the Developer Console.</td></tr></tbody></table>

The usecase object connects the marketplace back to Chapter 1: the four education service journeys (registration and enrolment, credential issuance, wallet storage, and sharing and verification) are published as a use case, with prompts that compose the individual skills into the end-to-end build demonstrated in Chapter 4.

#### 3.1.4 Skills: each provider is responsible for its own

A core design decision is that each wallet solution provider authors, publishes, and maintains the skills for its own products. The marketplace checks and reviews what is submitted (Section 3.3), but the knowledge inside a skill knows which endpoints to call, in which order, and with which payloads comes from the party that knows the product best and is accountable for keeping the skill in step with the live API as it evolves. No central team reverse-engineers vendor documentation, and no provider depends on another's goodwill to be represented accurately.

Each provider maintains fine-grained, composable skills for its own products. These skills are kept in an open repository and published to the marketplace, allowing them to be used independently or combined into broader workflows. As one worked example, the skills for the EU Business Wallet and Consent Building Block are available in the repository (<https://github.com/L3-iGrant/skills>) under the Apache 2.0 licence. The full table of 13 sets of core skills is provided in the annex.

<table data-header-hidden><thead><tr><th width="103.33331298828125"></th><th width="332"></th><th></th></tr></thead><tbody><tr><td>Set of core skills</td><td>What it teaches the agent</td><td>Builds on</td></tr><tr><td>igrantio-ows-overview</td><td>Organisation Wallet Suite architecture, glossary, and the full API reference. Read first.</td><td>none</td></tr><tr><td>igrantio-issuer-backend</td><td>Tenant backend for credential issuance (proxy + webhooks + SSE).</td><td>proxy, webhooks, sse</td></tr><tr><td>igrantio-issuer-frontend</td><td>Issuer UI: request issuance, render the QR or deep link, live status.</td><td>frontend-client</td></tr><tr><td>igrantio-verifier-backend</td><td>Tenant backend for verification (proxy + webhooks + SSE).</td><td>proxy, webhooks, sse</td></tr><tr><td>igrantio-verifier-frontend</td><td>Verifier UI: presentation request, QR or DC API, disclosed claims.</td><td>frontend-client</td></tr><tr><td>igrantio-backend-proxy</td><td>API key hiding, multi-tenant reverse proxy building block.</td><td>overview</td></tr><tr><td>igrantio-backend-webhooks</td><td>Register, receive, and HMAC-verify OWS webhooks.</td><td>overview</td></tr><tr><td>igrantio-backend-sse</td><td>Stream webhook events to the browser over SSE.</td><td>webhooks</td></tr><tr><td>igrantio-frontend-client</td><td>Dependency-free typed OWS browser client plus React hooks.</td><td>overview</td></tr><tr><td>igrantio-usecase-ui</td><td>Default look and feel: theme, app shell, primitives, strings-driven i18n.</td><td>frontend-client</td></tr><tr><td>igrantio-qr-code</td><td>Wallet QR panel: centre logo, success tick, refresh, open-in-wallet, transaction code.</td><td>frontend-client</td></tr><tr><td>igrantio-individuals</td><td>Onboard users as Consent BB individuals (userId to individualId mapping).</td><td>none</td></tr><tr><td>igrantio-consent-records</td><td>Record, read, withdraw, and erase consents against data agreements.</td><td>individuals</td></tr></tbody></table>

Two properties of these skills carry the governance model into the build itself. First, every skill opens with an integrator intake: environment (demo, staging, or custom), API key location, tenancy, webhooks, and frontend choices are presented as a series of questions, each with a recommended default, so the agent can lock in the setup before writing any code. Second, the backend skills ship a runnable reference implementation, so the agent scaffolds from working code rather than inventing an integration from prose.

#### 3.1.5 Creating a skill for any wallet stack

Any wallet software provider can create skills for its own stack by following the same recipe, starting from the public starter template: a skeleton bundle with a SKILL.md manifest carrying placeholder fields, plus empty openapi/, schemas/, rulebooks/, examples/ and references/ directories, ready to copy and fill. The steps are:

* Write the SKILL.md manifest: declare the name, description (the trigger an agent matches on), version, provider, the target API and OpenAPI files, the protocols implemented, the schemas and rulebooks the skill depends on, the authentication scheme, and the licence, as in the sample manifest in Chapter 2 (Section 2.6.3).
* Assemble the bundle: Place the OpenAPI 3.1 specifications under openapi/, the credential and record schemas under schemas/, the policy rules under rulebooks/, and worked request/response samples under examples/, following the bundle layout in Chapter 2 (Section 2.6.1).
* Include runnable reference code: a references/directory containing a working implementation (for example, a typed client, a proxy, or a webhook receiver) lets an agent scaffold review-ready integration code rather than pseudocode.
* Keep it in step with the live API: The skill is versioned against a specific API release; when the API changes, the provider publishes a new skill version, which re-enters review.
* Submit through the Provider Console: The bundle goes through the automated checks and human review described in Section 3.3 before it is listed.

## 3.2 How the Assistant Works

#### 3.2.1 The eight-step method

Here we specify an eight-step methodology for the AI-enabled build. The marketplace-and-skills mechanism realises each step as follows, with a qualified engineer manually reviewing every output before it is treated as a deliverable (human review, Section 3.3.4; no AI approves AI output):

<table data-header-hidden><thead><tr><th width="65.33331298828125"></th><th width="104"></th><th width="244.3333740234375"></th><th></th></tr></thead><tbody><tr><td>#</td><td>Step</td><td>How the assistant realises it</td><td>Output</td></tr><tr><td>1</td><td>Identify standards and specs</td><td>The provider of the skill encodes the applicable standards and profile choices in the skill bundle; the standards register (Chapter 2, Section 2.1) fixes the boundary conditions.</td><td>Standards register; requirements log</td></tr><tr><td>2</td><td>Specs as code</td><td>OpenAPI 3.1 specifications and JSON Schema credential definitions are included inside the bundle as machine-readable artefacts the agent acts on directly (Chapter 2, Section 2.4.2).</td><td>OpenAPI contracts; credential schemas</td></tr><tr><td>3</td><td>Design wallet architecture</td><td>The overview skill and the use-case prompt chains map requirements to components; the agent documents the mapping.</td><td>Architecture diagrams; component spec</td></tr><tr><td>4</td><td>Generate application code</td><td>The agent scaffolds from the skill's runnable reference implementation: backend proxy, webhook receiver, SSE stream, typed client, and UI.</td><td>Integration code; prompt and run logs</td></tr><tr><td>5</td><td>Ensure interoperability</td><td>Issuer and verifier flows are validated at the OpenID4VCI and OpenID4VP boundaries before provider-specific extensions are used (Chapter 2, Section 2.7).</td><td>Interoperability notes; flow documentation</td></tr><tr><td>6</td><td>Model education credentials</td><td>Diploma, transcript, and micro-credential schemas plus the qualification rulebook define the education domain; journeys are expressed as use-case prompts.</td><td>Education domain model; journey blueprints</td></tr><tr><td>7</td><td>Integrate with DPI building blocks</td><td>Consent skills, the National Learner Registry specifications, and documented mock patterns wire the wallet flows to the DPI building blocks (Chapter 2, Section 2.3).</td><td>Integration scripts; adapter notes</td></tr><tr><td>8</td><td>Iterate on feedback</td><td>Feedback lands as new bundle versions and regenerated artefacts; every version re-enters the review pipeline.</td><td>Iteration log; final knowledge product</td></tr></tbody></table>

#### 3.2.2 Workflow 1: a provider lists to the marketplace

The listing workflow is deliberately app-store shaped: automated checks run on every submission, and nothing is published without a named human decision.

<table data-header-hidden><thead><tr><th width="126"></th><th></th><th></th></tr></thead><tbody><tr><td>Step</td><td>What happens</td><td>Detail</td></tr><tr><td>1. Register organisation</td><td>The provider registers in the Provider Console.</td><td>A super admin verifies the organisation before anything it submits can be published.</td></tr><tr><td>2. Submit bundle</td><td>The provider uploads SKILL.md plus openapi/, schemas/, and rulebooks/.</td><td>Pinned to a commit, tag, or branch head that the provider chooses by file or as a single .zip.</td></tr><tr><td>3. Automated checks</td><td>The check suite runs instantly on submission.</td><td>The check report is attached to that version and travels with it.</td></tr><tr><td>4. Reviewer decides</td><td>A reviewer claims the item from the review queue.</td><td>Approve, reject, or request changes; every decision is logged.</td></tr><tr><td>5. Published</td><td>The item is listed in the public catalogue.</td><td>With provider, version, target API release, licence, and directory placement.</td></tr><tr><td>6. Endorsed</td><td>The marketplace operator may mark the item Official.</td><td>A super admin endorses; everything else shows as Community.</td></tr></tbody></table>

The content of the automated check gate and the human review gate is specified in Section 3.3.1.

#### 3.2.3 Workflow 2: an integrator adopts and deploys

The adoption workflow turns "read the docs and integrate" into "install and build":

<table data-header-hidden><thead><tr><th width="112.66668701171875"></th><th></th><th></th></tr></thead><tbody><tr><td>Step</td><td>What happens</td><td>Detail</td></tr><tr><td>1. Browse</td><td>Pick a provider's skills, or a usecase that composes them.</td><td>The catalogue, showcase, and review trails inform the choice.</td></tr><tr><td>2. Install skills</td><td>npx skills add &#x3C;provider>/skills, or download the bundle .zip into the agent.</td><td>The same bundle installs into any supported agent (Chapter 2, Section 2.6.2).</td></tr><tr><td>3. Get API key</td><td>Create an account with the wallet provider and procure the organisation API key.</td><td>For OWS: organisation account, API key, data agreements, and webhook registration.</td></tr><tr><td>4. Prompt the agent</td><td>Describe what to build; the agent applies the installed skills.</td><td>Claude Code, opencode, Codex CLI, Pi, or any agent that reads SKILL.md.</td></tr><tr><td>5. Test with a wallet</td><td>Run the result against a real end-user wallet in a demo or staging environment.</td><td>Iterate until the journeys pass end-to-end.</td></tr><tr><td>6. Deploy</td><td>Deploy the application anywhere.</td><td>No runtime, API keys, or learner data ever sit with the marketplace.</td></tr></tbody></table>

The division of responsibility is explicit, and it is what keeps the marketplace out of the data path:

| The integrator brings                                      | The provider brings                                                                   | The marketplace brings                                                 |
| ---------------------------------------------------------- | ------------------------------------------------------------------------------------- | ---------------------------------------------------------------------- |
| The agent and the model; the application, UI, and hosting. | Skills, OpenAPI specifications, schemas, rulebooks, reference code, and the live API. | Discovery, automated checks, human review, versioning, and provenance. |

<img src="https://95341731-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FDXDTZNhGJPQlyqg12XmE%2Fuploads%2FygJvXNHIeYHZFUKKvivj%2Funknown.png?alt=media&amp;token=004b1a78-23a6-4325-99cc-2a27c1a5158f" alt="Figure 3.2. The two marketplace workflows: a provider lists a skill bundle through the two-gate pipeline, and an integrator adopts and deploys it." height="176" width="605">

#### 3.2.4 Inside an agent session

Concretely, an integrator building the diploma-issuance step of a National Learner Registry application in Claude Code does this:

`$ npx skills add L3-iGrant/skills`

`installed: igrantio-issuer-backend`

`igrantio-verifier-backend`

`igrantio-consent-records`

`$ claude`

`> /igrantio-issuer-backend`

`Build the diploma-issuance step of my`

`National Learner Registry app.`

`environment? demo`

`api key? in .env, backend only`

`tenancy? single tenant`

`webhooks? POST /webhooks/ows`

`frontend? Next.js, show offer QR`

`scaffolding proxy, webhook receiver,`

`SSE stream and QR panel from`

`references/ ...`<br>

The agent then works through a fixed sequence:

* Reads SKILL.md, the OpenAPI specifications, the credential schemas, and the rulebooks.
* Runs the integrator intake, one question at a time, each with a recommended default.
* Scaffolds from the skill's runnable reference implementation: a backend proxy that hides the API key, a webhook receiver with HMAC verification, an SSE stream to the browser, and a typed client with React hooks and a QR panel.
* Wires OpenID4VCI issuance and renders the credential offer as a QR code and deep link.
* Confirms issuance from the webhook event, exactly as specified in Chapter 2 (Section 2.6.1). The deployed build implements this bundle format with a source-pinned GitHub submission and the check-and-review pipeline; the reference design's tests/conformance suite, publisher bundle signature, use-case objects, developer showcase, and .well-known discovery index remain on the roadmap. Registers the credential in the Certificate Registry; that is, after issuance is confirmed, the application records the credential’s issuance, status, and revocation metadata. This is distinct from the National Learner Registry (NLR), which maintains the learner’s profile and Unique Learner Identifier (ULID); the complete credential remains in the learner's wallet (see Chapter 2, Sections 2.2.1 and 2.7.4).
* Presents the diff for human review. AI output is a hypothesis until it passes the sandbox.

The same bundle runs unchanged in opencode, Codex CLI, or Pi; only the invocation differs (/skill-name in Claude Code, @skill-name elsewhere). This is the agent-agnostic, model-agnostic boundary of Chapter 2 (Section 2.4.5) exercised in practice.

## 3.3 Governance

#### 3.3.1 Marketplace vetting: Two gates

Every submission passes two gates before it is listed. The automated check gate runs instantly on submission and attaches its report to the version. It verifies that:

* SKILL.md parses, and the slug is valid;
* name, description, licence, and provider are declared;
* Every openapi/\*.yaml file is valid OpenAPI 3.x;
* Every schema parses;
* The declared rulebooks are present;
* Every declared depends\_on path resolves inside the bundle.

The human review gate follows. A reviewer claims the item from the queue and inspects the bundle together with the check report. This is where judgement that cannot be automated is applied: the GovStack Wallet BB role mapping and the OpenID4VCI/OpenID4VP boundary conditions of Chapter 2 (Section 2.7) are assessed here. The reviewer approves, rejects, or requests changes, and every decision is recorded in the audit log to retain an assurance trail.

#### 3.3.2 Listing, provenance, and endorsement

Once published, an item's provenance is permanent and public. Each listing carries its provider, version, target API release, and licence and exposes its full review trail – the automated check reports and the human approval audit at a public URL (Section 3.1.2). Skills and usecases endorsed by the marketplace operator are displayed as Official; all others are displayed as Community. Endorsement is a superadmin action, distinct from review approval, so the bar for being listed and the bar for being recommended are kept separate. Items can be delisted, and a new version of a published item re-enters the pipeline rather than silently replacing what was reviewed.

#### 3.3.3 Roles and separation of duties

Marketplace governance is enforced through roles. Governance roles are granted by a super admin and can never be self-assigned at registration where a provider cannot review its own submissions, and a reviewer cannot endorse.

<table data-header-hidden><thead><tr><th width="126.6666259765625"></th><th></th></tr></thead><tbody><tr><td>Role</td><td>Can do</td></tr><tr><td>Developer (builder)</td><td>Browse and install; submit applications to the developer showcase.</td></tr><tr><td>Provider</td><td>Everything a developer can, plus register an organisation and publish skills and usecases for review.</td></tr><tr><td>Reviewer</td><td>Governance: claim the review queue, inspect bundles and check reports, approve, reject, or request changes, and moderate showcase applications.</td></tr><tr><td>Super admin</td><td>Everything a reviewer can, plus verify organisations, manage users and roles, suspend accounts, endorse Official, and delist items.</td></tr></tbody></table>

#### 3.3.4 Governance of AI-generated artefacts in the build

The vetting above governs what enters the marketplace. A parallel discipline governs what the assistant produces during a build, unchanged from the commitments in Chapters 1 and 2:

* Every artefact an agent produces is reviewed by a qualified engineer before it is treated as a deliverable.
* AI-generated code is treated as a hypothesis until it has been validated against the working prototype and the provider's sandbox.
* Prompts, agent runs, and reviewer trails are retained as audit evidence.
* All assistant workflows are scripted and reproducible from the same inputs, so a build can be regenerated and independently checked.

The marketplace platform itself is held to the same evidential standard. Its end-to-end test suite exercises the full submit-review-publish cycle, both bundle download formats, authentication, authorisation, and the role APIs; a capacity gate sends 10,000 requests at 100 concurrent clients and requires zero errors with p95 latency below 500 ms. Chapter 4 shows this machinery applied to the education prototype, and Chapter 5 covers how the platform and prototype are deployed.

<br>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://experience-digital-transform.gitbook.io/experience-digital-transformation/ai-wallet-use-case/chapter-03-the-ai-integration-assistant.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.