Grounding Agents in Enterprise Knowledge

Amazon Bedrock Knowledge Bases, the RAG pipeline, and GitHub Copilot context.

§ IFrame

The Thursday cert arc has so far answered two of the three questions a production agent forces. The audit-trails lesson (05-28) answered what did the agent do with traces and provenance logs. The pre-tool-gates lesson (06-04) answered what may the agent do with refuse-or-proceed verdicts ahead of every action. Today closes the triad with the question that comes before either: what does the agent know, and why should anyone believe its answer?

A foundation model knows its training data and nothing after, nothing private, nothing about your runbooks, your codebase, or your chain-flow tables. Retrieval-augmented generation is the standard cure, and both of today's certs examine it from their own side. AWS AIP-C01 tests RAG as architecture: Bedrock Knowledge Bases, embeddings, vector stores, and the RetrieveAndGenerate flow. GitHub GH-600 tests RAG as developer experience: how Copilot assembles context from open files, indexed repositories, and instruction files so that its answers come from your code rather than the model's memory of someone else's. One mechanism, two exam vocabularies.

Huyen frames RAG plainly: retrieve the relevant knowledge at query time, attach it to the prompt, and let the model generate from what was retrieved rather than from parametric memory alone (AI Engineering, ch. 6, pp. 278–279). The rest of the chapter, and the rest of this lesson, is the unglamorous machinery that makes "retrieve the relevant knowledge" true.

§ IIDomain Foundations — The RAG Pipeline as an Ingestion System

Both certs reward the same mental model, and it is the model today's Ops lesson built for a different source. RAG has two planes. The ingestion plane runs ahead of any query: walk the document source, split documents into chunks, embed each chunk into a vector, and land vectors plus metadata in a store. The query plane runs at request time: embed the question, search the store for nearest chunks, optionally re-rank, then generate with the retrieved chunks in the prompt and citations pointing back at them.

Three ingestion decisions dominate answer quality. Chunking decides the grain: too large and retrieval drags in noise that dilutes the prompt, too small and no chunk carries enough context to answer with. Fixed-size with overlap is the baseline; hierarchical and semantic chunking preserve structure for documents that have it. Embedding choice decides the geometry of similarity, and the embedding model used at ingestion must be the one used at query time, or the two planes are searching different spaces. Sync cadence decides freshness, and it is the cursor-lag of the document world: a knowledge base that last ingested in March answers June questions with March truth, confidently.

Retrieval itself is older than the embedding era, and Huyen's treatment keeps both families honest: term-based retrieval (BM25 lineage) matches exact vocabulary and rare identifiers; embedding-based retrieval matches meaning across paraphrase; production systems routinely run both and fuse the rankings (AI Engineering, pp. 285–286, 293–296). Hybrid-plus-rerank is the default answer shape for "how do we improve retrieval quality" questions on both exams, and it happens to be the architecture of this vault's own lattice.

§ IIIAIP-C01 Flavor — Bedrock Knowledge Bases

Bedrock packages the whole pipeline as a managed object. A Knowledge Base binds three things: a data source (S3 most commonly, plus web crawlers and connectors), an embedding model, and a vector store (OpenSearch Serverless as the managed default; Aurora PostgreSQL with pgvector, Pinecone, and others as alternatives). An ingestion job is the managed sync: it walks the source, applies the configured chunking strategy, embeds, and writes vectors. Ingestion jobs run on demand or on schedule, and incremental syncs pick up changed documents. The exam expects you to know that chunking strategy is set per data source, that fixed-size, hierarchical, semantic, and none (pre-chunked) are the options, and that changing chunking or embedding model means re-ingesting.

The query plane exposes two API shapes, and the distinction is a reliable exam question. Retrieve returns the matched chunks with scores and source URIs, and leaves generation to you: the right call when the agent's orchestration layer wants to gate, filter, or combine retrieval with other context before any model sees it. RetrieveAndGenerate runs the full loop, returning a generated answer with citations attached. Citations are the trust artifact: each generated claim links back to the chunk and document that grounded it, which is the agentic version of the settled-zone rule. An answer that cannot cite its chunk is an answer from parametric memory, and the whole architecture exists to avoid trusting that by default.

Two more AIP-C01 surfaces complete the picture. Metadata filtering attaches key-value metadata to documents at ingestion and filters retrieval on it at query time, so a query can scope to one product line, one tenant, or one date range; this is also the standard answer for multi-tenant isolation inside a shared knowledge base. And the agent integration: a Bedrock Agent associates with one or more Knowledge Bases, decides per turn whether to retrieve, and writes its retrievals into the same trace the 05-28 lesson examined. Guardrails from the 06-04 lesson apply to RAG output too, screening generated answers regardless of what grounded them.

§ IVGH-600 Flavor — Copilot Context and Knowledge

Copilot answers the knowledge question at a different scale: the enterprise's code. The GH-600 exam wants the context hierarchy. At the bottom, open tabs and the active file feed completion context; the working set is the implicit retrieval. Above that, workspace and repository indexing gives Copilot Chat semantic search over the codebase, so an answer about where fill reconciliation happens retrieves the actual module rather than guessing from naming conventions. Enterprise plans add knowledge bases: curated collections of repositories and documentation that organization admins assemble so that chat answers ground in approved internal sources. The mechanism underneath is the same two-plane pipeline as §II, indexing ahead of time, retrieving at question time.

The steering layer is instruction files. A copilot-instructions.md at repository root injects standing guidance into every Copilot interaction in that repo: house conventions, banned patterns, required disciplines. Path-scoped instruction files refine it per directory. This is retrieval too, in the broad sense; it is context the developer wrote for the model, deterministically included rather than similarity-matched. The exam distinguishes the two: instructions shape how Copilot answers everywhere; knowledge bases shape what it can answer from.

§ VWorked Example — One Question Through Both Stacks

Take a concrete agent from this vault's own world: an operations assistant asked, "What confirmation horizon does our exchange-flow indexer use, and why twelve blocks?"

On the AWS side, the runbook corpus lives in S3 behind a Knowledge Base with hierarchical chunking (runbooks have headings worth preserving), Titan embeddings, and OpenSearch Serverless. The agent calls Retrieve rather than RetrieveAndGenerate because its orchestrator applies a metadata filter first (domain = chain-ops) and the 06-04 pre-tool gate screens the assembled prompt before generation. Retrieval returns the indexer runbook's reorg section with scores and URIs; generation produces an answer citing that chunk; the trace records query, chunks, filter, and verdict per the 05-28 discipline. Three Thursday lessons, one request path.

On the GitHub side, the same question lands in Copilot Chat scoped to a knowledge base containing the indexer repository and its docs directory. Repository indexing retrieves the constant, the config that sets it, and the design note that justifies twelve; copilot-instructions.md has already standing-ordered that answers about financial pipelines cite the file they derive from. The developer gets the same grounded answer with file-path citations instead of S3 URIs.

The symmetry is the study aid: data source → chunk/index → embed → store → filter → retrieve → generate-with-citations, whether the corpus is runbooks or repositories. Learn it once, answer it twice.

§ VIConnection to Today's Ops and Dev Lessons

Today's trio is one pipeline drawn three times. The Ops lesson walked a chain and landed transfer rows; the Knowledge Base walks a document source and lands embedded chunks; both stage, both sync on a cursor-like cadence, both refuse to let queries touch what has not earned trust. The Ops lesson's finality gate reappears here as citation-grounding: depth confers trust on a row, a verifiable source chunk confers trust on a generated claim. And the Dev lesson's distributional sanity check has a direct RAG sibling in retrieval evaluation: presence of an index proves ingestion ran, while only measured retrieval quality (relevance of returned chunks, groundedness of answers against them) proves the pipeline can be believed. Same epistemics, third corpus.

Paired Ops → Archmagus-Stack/δ-Chain/Synthesis-Lessons/2026-06-11-chain-indexing-and-on-chain-data-pipelines-event-extraction-reorg-safe-ingestion-and-the-backfill-discipline
Paired Dev → Polyglot-Dev/R/2026-06-11-r-and-python-for-on-chain-event-analysis-tidy-data-frames-distributional-sanity-checks-and-the-two-language-discipline

§ VIIPractice Questions

§ VIIIClosing

The Thursday triad is complete: trace what the agent did, gate what it may do, ground what it knows. Grounding is the oldest of the three problems wearing the newest clothes, because it is ingestion engineering with a generative consumer at the end. Declare the chunk grain, keep ingestion and query in one embedding space, sync before the corpus goes stale, retrieve hybrid, and never ship an answer that cannot point at the chunk that taught it.

Take the five questions cold tomorrow. Then trace one answer your own tools gave you this week back to its source. If you cannot, you have been generating from parametric memory and calling it retrieval.