.png)
AWS has released Agentic retrieval for Amazon Bedrock Managed Knowledge Base, exposed through the new AgenticRetrieveStream API. The feature targets multi-part, comparative, and exploratory questions that break classic single-shot retrieval, and it can plan retrieval steps and generate an answer in the same call.
The core problem is not recall, it is intent structure. A query like “What is the most important message in the documents?” is underspecified, so a standard Retrieve call will still return chunks that are semantically close to the embedding of the question, even if they are not operationally useful.
The AWS example is blunt: in a corpus of 25 years of Amazon shareholder letters, the highest-scoring chunk for that vague query discussed the Amazon logo color scheme. That is a normal failure mode for vanilla retrieval. The scorer is doing similarity search, not task inference.
The harder class of questions is the one enterprises actually ask:
“Compare how Amazon talked about hiring, long-term investment, and customer obsession in 2020 vs 2023. Where did emphasis shift?”
That is not one query. It is several retrieval intents stitched together by comparison logic. A single embedding does not represent “hiring,” “long-term investment,” and “customer obsession” equally well, so top-k retrieval tends to average across sub-intents and miss the shift the analyst cares about.
AgenticRetrieveStream changes the contract from “return the best chunks” to “plan, retrieve, and answer.” Instead of treating retrieval as a single lookup, Bedrock can break a question into sub-questions, issue multiple retrieval steps, and synthesize the response from the gathered evidence.
That makes the feature useful for:
The important architectural shift is that retrieval becomes stateful and iterative. The system can use conversation history, refine the search path, and keep going when the first evidence set is incomplete.
For production systems, that means the unit of evaluation is no longer just “top-k relevance.” It is end-to-end answer quality under iterative retrieval. If a question routinely decomposes into multiple intents, the agentic path is the right default to test.
The post emphasizes two implementation details: request construction and trace parsing.
The request goes to the new streaming API rather than the standard Retrieve API. That matters because the caller is not waiting for a final chunk list only; it is also consuming intermediate retrieval and planning signals. In practice, this is the hook that lets an application understand how the system reasoned over the request and where it spent retrieval budget.
Trace parsing is the part engineers should pay attention to. Once retrieval becomes iterative, observability matters more than raw latency. You want to know:
If you are migrating an existing Bedrock KB workflow, this is where the operational work lands. The API is not just a drop-in replacement for Retrieve; it changes what you log, what you inspect, and how you debug retrieval quality.
Use the standard Retrieve API when the question is narrow and already well-formed. Exact lookups, single-policy questions, and known-item search still map cleanly to one-shot retrieval.
Use AgenticRetrieveStream when the query has any of these properties:
The tradeoff is predictable. Agentic retrieval should improve answer quality on hard questions, but it will also introduce more moving parts: more steps, more trace data, and potentially higher latency. For workloads dominated by direct factual lookups, the extra orchestration is unnecessary. For analyst workflows, support triage, and document-heavy enterprise search, it is the more realistic retrieval primitive.
