Managed Bedrock Knowledge Bases: agentic multi-KB retrieval is the API—observability is half the app

Most RAG systems embed a question, fetch nearest chunks from one index, and generate once. That design fails in a recognizable way: answers that span two corpora come back fluent and half-complete; the right source depends on the question; a second look has nowhere to happen.

AWS’s CDK walkthrough for enterprise agentic retrieval on Managed Amazon Bedrock Knowledge Bases says the product shift is larger than “managed vectors.” Retrieval became an agentic capability—multi-turn planning, tool-driven retrieval, grounded citations—exposed as AgenticRetrieveStream rather than home-built orchestration.

Three changes since the August 2024 single-shot CDK post: Managed Knowledge Bases remove the OpenSearch Serverless collection and OCU bill; Amazon Bedrock AgentCore supplies a Gateway that exposes each knowledge base as an MCP tool and a Runtime that hosts the reasoning agent; observability and evaluation are provisioned in the same deploy—two CloudWatch dashboards across seven telemetry layers, plus on-demand and continuous evaluation.

Agentic retrieval and Gateway integration are available only on Managed Knowledge Bases. Customer-managed DIY stores remain for residency, tuning or reuse constraints—but they do not get this agentic API surface. The sample routes across two knowledge bases, retrieves through the Gateway, and returns cited answers with CDK deriving stack order from construct wiring.

The architectural evidence is the dependency graph itself. Gateway needs both knowledge-base IDs; the agent needs Gateway URL and ARN; dashboards need KB IDs, Gateway ARN and agent runtime ID—seven values crossing four stacks. In raw templates that is hand-kept exports and deploy scripts; in CDK, passing the construct derives the edge.

Operationally the post is blunt: a single-shot pipeline is a function you can read; an agent that retrieves in a loop takes a different path per question. Without instrumentation you see neither the path nor whether the answer was faithful. Citations and faithfulness/correctness scores are framed as responsible-use requirements, not polish.

The steelman is that managed convenience trades control: teams with existing OpenSearch estates, custom embedding/rerank pipelines, or strict data-plane requirements may correctly stay DIY—and then agentic retrieval simply is not on the menu. Another counter: AgenticRetrieveStream’s internal planning may be enough without a full AgentCore Runtime + dual-KB CDK cathedral for many workloads.

Also thin: independent latency/cost numbers versus classic RAG, how often the agent over-retrieves, evaluation metric calibration, and multi-account/multi-Region operational reality. This is a reference architecture essay with a clear thesis, not a bake-off.

For platform teams, the decision forks: if you need agentic multi-KB retrieval as a service feature, Managed is the gate; if you need to operate the vector store, you forgo that API. Once you choose Managed, half the engineering budget should be assumed for dashboards, traces and eval loops—or you will ship a fluent generator you cannot audit.

CDK’s value here is specific: dense cross-stack references make Twitchy CloudFormation exports a reliability risk, not a style preference.

Watch whether AgenticRetrieveStream becomes the default enterprise RAG path on Bedrock, and whether customers publish faithfulness scores from these provisioned evals. If observability stays optional, agentic RAG will recreate the old RAG failure mode—confident answers with an invisible retrieval path. If it stays first-class in the CDK, “managed” will mean operable, not merely hosted.