AWS adds agentic retrieval to Bedrock Knowledge Bases

Amazon Web Services announced agentic retrieval, a new retrieval mode for Bedrock Managed Knowledge Bases available through the AgenticRetrieveStream API. The feature addresses a fundamental limitation of traditional similarity-based retrieval: single-shot queries fail on multi-part, comparative, and exploratory questions that require decomposition and iteration.

The gap is concrete. When a user asks "Compare how Amazon talked about hiring, long-term investment, and customer obsession in 2020 vs 2023. Where did emphasis shift?" a single query embedding must represent three intents across two time periods. Top-k results tend to blend intents together or cluster tightly around the strongest signal. In contrast, a human analyst would decompose the question—search hiring in 2020, then in 2023, then investment philosophy in each year, read the results, notice gaps, refine the search, and run it again. Only then would they synthesize.

Agentic retrieval automates that workflow. The foundation model analyzes the query, reviews prior results, and emits sub-queries aligned to retrievable intents. The loop includes five trace event types: SpeculativeRetrieval (an initial probe that reduces end-to-end latency); Planning (the model reviews query and prior results, judges sufficiency, and decides whether to stop or iterate); Retrieval or FullDocumentExpansion (one event per sub-query, with the ability to fetch a full document if passage context is insufficient); and Result (the final deduplicated chunk set, with grounded response and citations if generation is enabled). Each iteration counts toward maxAgentIteration, which defaults to 3 for single knowledge base and 4–5 for multi-KB queries, though the planner may exit early.

For multi-knowledge base scenarios, the API accepts up to five Managed KB retrievers, each tagged with a natural-language description (e.g., "Public product documentation and API reference" or "Resolved customer support tickets and runbooks"). The planner routes each sub-query to the most relevant KB based on those descriptions; the final results identify which KB answered each chunk via sourceRetriever. Deduplication applies only to the final result event, so when multiple sub-queries retrieve the same chunk, it appears once in the results but remains visible in individual trace events for debugging.

Pricing reflects the multi-step nature: $4 per 1,000 agentic retrieval calls (the planner orchestration) plus $1 per 1,000 underlying Retrieve API calls. Teams using custom agent frameworks built on top of the standard Retrieve API eliminate that custom plumbing and its associated latency and reliability risk. Users configure the behavior via two main parameters: maxAgentIteration (the iteration ceiling) and foundationModelType (CUSTOM to bring a Bedrock model, or service-managed). Response generation is on by default; setting generateResponse=False returns retrieval results without synthesis.

Multi-part and comparative questions represent a longstanding challenge in document retrieval. A single embedding captures only one intent, so when a user asks something like "Compare how Amazon talked about hiring and long-term investment in 2020 vs. 2023," traditional retrieval must compress three distinct search intents—hiring 2020, hiring 2023, and investment philosophy across both years—into one query vector. The result is either a scatter of loosely related chunks or a tight cluster dominated by the strongest signal, neither of which serves the user well.

AWS has addressed this gap by embedding agentic planning directly into the Bedrock Knowledge Base API. Rather than requiring teams to build custom agent frameworks on top of the Retrieve API—each carrying its own latency, cost, and reliability overhead—agentic retrieval automates the decomposition-and-iteration workflow as a managed service. The foundation model sees the full question, the prior retrieval results, and the space of available knowledge bases (each with a user-supplied description), then decides how to search next and when it has gathered enough evidence to synthesize an answer.

The pricing model reflects the multi-step nature of the approach: $4 per 1,000 agentic retrieval calls covers the orchestration cost, while the underlying Retrieve API calls that actually fetch chunks cost an additional $1 per 1,000. This means teams can budget on the number of user queries, not the number of internal sub-retrieval steps, which may vary per question. For teams currently building custom agent loops, the managed service eliminates custom plumbing; for those using single-shot retrieval, it extends reach to questions that previously required manual decomposition.

No comments yet. Be the first to share your thoughts!