AWS Publishes Four-Stack Bedrock Blueprint for Observable Agentic Retrieval
The sample separates cross-knowledge-base routing from retrieval within a selected knowledge base, but ties the pattern to AWS-managed services and their operating requirements.
Listen to this story
The audio brief
Story brief
3 key pointsAWS has released a four-CloudFormation-stack reference implementation for retrieval agents that route questions across multiple Bedrock knowledge bases and expose their decisions for inspection. The design pairs AgentCore with MCP Gateway tools and AgenticRetrieveStream, which decomposes queries and can support repeated retrieval. Its convenience depends on Managed Knowledge Bases; customer-managed stores lack the...
- 01
Four stacks cover knowledge bases, Gateway configuration, the instrumented agent runtime, and CloudWatch dashboards.
- 02
AgenticRetrieveStream performs sub-query decomposition, iterative retrieval, and citation-backed answering inside a selected knowledge base.
- 03
The blueprint requires Managed Knowledge Bases; AWS says customer-managed options lack its agentic-retrieval API and Gateway integration.
AWS has published a deployable pattern for enterprise retrieval agents that must choose among knowledge bases, retrieve more than once, and leave a record of what happened. The reference implementation uses four CloudFormation stacks to combine Bedrock Managed Knowledge Bases, AgentCore, MCP-based tools, dashboards and evaluations in one setup.
The design splits retrieval into two jobs. An agent running in Bedrock AgentCore selects the tool for the knowledge base matching a question’s topic. That tool reaches the selected knowledge base through AgentCore Gateway and the Model Context Protocol, or MCP, which connects models to tools. Inside the knowledge base, AgenticRetrieveStream breaks a question into sub-queries, retrieves iteratively, and returns a grounded answer with citations. The agent can then decide whether to retrieve again before responding.
The managed-service boundary
That comparison defines the blueprint’s limit as well as its convenience. The Gateway exposes each knowledge base through a native connector as an MCP retrieval tool, without a Lambda function or extra container. But the architecture depends on capabilities AWS says are available on its Managed Knowledge Bases rather than customer-managed ones.
Evaluation arrives with the runtime
The four stacks create knowledge bases and their data sources, configure the Gateway, build and host an OpenTelemetry-instrumented agent runtime, and create two CloudWatch dashboards. AWS groups the telemetry into seven layers: knowledge-base health, ingestion, retrieval quality, Gateway activity, the agent’s span tree, token use and evaluation scores.
Those layers do not all use the same data path. The runtime automatically emits spans, token use and metrics, while the sample’s driver notebook publishes custom metrics for retrieval quality, token use and evaluation. A cited answer alone does not show whether the agent selected an appropriate tool or how many tokens a session consumed.
A deliberately narrow routing test
The sample uses separate knowledge bases for a synthetic financial filing and a publicly available report on tornadoes. Each is exposed as its own tool, letting the agent make a topic choice while keeping monitoring signals separate. One knowledge base with two data sources would remove the routing choice the example is intended to demonstrate.
Deployment still requires permissions across Bedrock, AgentCore, IAM, CloudWatch, X-Ray, ECR, CodeBuild, S3, Lambda and CloudFormation, plus model access and CloudWatch Transaction Search. AWS says the runtime stack’s CodeBuild container build takes roughly eight to 10 minutes.
Sources
- aws.amazon.comBuild observable enterprise agentic retrieval using Managed Amazon Bedrock Knowledge Base with AWS CloudFormation | Amazon Web Services