AWS Gives Bedrock Users Tunable RAG: One Dial, Zero to Five

Amazon Web Services announced on November 9, 2026 that Amazon Bedrock Managed Knowledge Base now supports single-shot retrieval-augmented generation and retrieval-only requests through AgenticRetrieveStream. An expanded 0–5 range for the maxAgentIteration parameter lets applications choose plain source retrieval, a one-search answer, or the existing multi-step agentic retrieval — all from a single setting.

The update folds the basic RAG pattern — one retrieval, one generated answer — into the same streaming API developers already use for complex searches. Single-shot RAG consumes one foundation-model call for generation. Retrieval-only requests use none. AWS says single-shot operation can reduce latency and model usage relative to agentic retrieval, but the announcement ships no measured latency or cost comparison. That gap is the story's open question.

What does the new parameter actually control?

The numbers map cleanly to modes:

• 0 returns matching passages without generating an answer.
• 1 retrieves once and generates an answer when generateResponse=true.
• 2 through 5 preserve the existing agentic behavior.

Every mode supports multiple knowledge bases, so "single-shot" means one retrieval — not one knowledge base. Existing requests set to 2 through 5 don't change.

One iteration equals one foundation-model call. With generation enabled, a limit of n reserves the final call for the answer and allows up to n minus 1 planning rounds. Each planning round pairs a query rewrite with a retrieval. A speculative retrieval runs before planning and never counts against the limit.

The rules are strict at the edges. At 0, generation must be off; enabling it triggers 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. Simple rule: zero means passages only, one means one pass plus an answer.

How does streaming behavior change?

The AgenticRetrieveStream API reference lists messages, retrievers, and agenticRetrieveConfiguration as required inputs, with generateResponse optional. Answer chunks arrive only when generation is enabled. The final result can include retrieved items, a synthesized answer, and citations connecting answer spans to supporting results.

Retrieval-only mode is functionally equivalent to calling Retrieve directly — but the response format differs. Passages arrive in the stream's result event without score or location fields. The practical payoff: applications already on AgenticRetrieveStream can get 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 retrieved evidence is sufficient, runs 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. AWS warns that lowering the iteration ceiling can stop the agent sooner and potentially reduce accuracy on complex queries.

How should teams pick a 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. 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 raw policy language uses 0 and returns passages without a summary.

The application must choose the mode itself; maxAgentIteration doesn't route requests automatically. The example assistant handles lookup and comparison, but it neither approves accounts nor replaces bank review and authorization.

AWS recommends benchmarking single-shot RAG against the 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 should drive selection of the lowest iteration limit that meets each workflow's quality bar.

The change turns retrieval depth into an explicit per-request infrastructure decision. For enterprises, the trade-off is now measurable: whether reduced model usage still yields complete, supported answers on their own documents — rather than assuming a higher iteration limit is always better.