AWS Adds Single-Shot RAG and Retrieval-Only Mode to Bedrock

Amazon Web Services announced on November 9, 2026 that Amazon Bedrock Managed Knowledge Base now supports single-shot retrieval-augmented generation (RAG) and passage-only requests through AgenticRetrieveStream. An expanded 0–5 range for maxAgentIteration lets applications select source retrieval, a one-search answer, or the service’s existing multi-step agentic retrieval.

The update brings the basic RAG pattern, one retrieval followed by a generated answer, into the same streaming API used for complex searches. Single-shot RAG uses one foundation-model call for generation, while retrieval-only requests use none. AWS says single-shot operation can reduce latency and model usage relative to agentic retrieval, but the announcement supplies no measured latency or cost comparison.

One Parameter Selects the Retrieval Mode

A value of 0 returns matching passages without generating an answer; 1 retrieves once and generates an answer with generateResponse=true; and 2 through 5 preserve existing agentic behavior. Every mode supports multiple knowledge bases. Single-shot therefore refers to one retrieval, not a restriction to one knowledge base.

One iteration represents one foundation-model call. When generation is enabled, a limit of n reserves the final call for answer generation and allows as many as n minus 1 planning rounds. Each planning round pairs a query rewrite with a retrieval. The initial speculative retrieval runs before planning and never counts against the limit.

At 0, response generation must be off. Enabling it produces a 4xx error because an answer requires a model call. At 1, the stream carries one retrieval and one grounded answer with no planning trace events. Existing requests using 2 through 5 do not change.

Streaming Behavior and Operating Limits

The AgenticRetrieveStream API reference identifies messages, retrievers, and agenticRetrieveConfiguration as required request inputs, while generateResponse is optional. Generated answer chunks are emitted only when generation is enabled. The final result can contain retrieved items, a synthesized answer, and citations that connect spans of the answer to supporting results.

Retrieval-only operation is equivalent to calling Retrieve directly, but its response format differs: passages appear in the stream’s result event without score or location fields. Applications already using AgenticRetrieveStream can consequently obtain Retrieve-style behavior by changing a parameter instead of integrating a separate API.

For complex questions, the Amazon Bedrock User Guide describes a workflow that decomposes queries into sub-queries, checks whether the retrieved evidence is sufficient, conducts additional searches, and can expand to a full document. Agentic retrieval supports only fully managed Bedrock knowledge bases and permits up to five retrievers per request. Lowering the iteration ceiling can stop the agent sooner and potentially reduce accuracy on complex queries.

Application Teams Choose and Test the Mode

AWS illustrates the settings with a fictional bank’s internal policy assistant, not a customer deployment. A sole-proprietor documentation question uses maxAgentIteration=1, while a comparison of sole-proprietor and LLC requirements that also checks rules for nonresident owners uses 4, permitting up to three planning rounds. A request to inspect policy language uses 0 and returns source passages without a summary.

The application must select the mode; maxAgentIteration does not automatically route requests. The example assistant handles policy lookup and comparison, but it neither approves accounts nor replaces bank review and authorization.

For adoption, AWS recommends comparing single-shot RAG with the existing agentic configuration on the same knowledge base, using representative questions and expected answers. The evaluation should measure latency and request cost, verify correctness and support in retrieved passages, and include multi-document and unanswerable questions. Those results can guide selection of the lowest iteration limit that satisfies each workflow’s quality requirements.

The change makes retrieval depth an explicit per-request infrastructure decision. Direct lookups can avoid planning calls, while complex queries retain iterative evidence gathering. For enterprises, the central trade-off is whether reduced model usage preserves complete, supported answers on their own documents, rather than assuming a higher iteration limit is always better.