Amazon Bedrock adds single-shot RAG and retrieval-only modes

Amazon Web Services has updated its Bedrock Managed Knowledge Base to support three distinct retrieval modes through a single API endpoint. Released on November 9, 2026, this change allows developers to choose between agentic planning, single-shot generation, or raw passage retrieval by adjusting a single parameter. This update aims to reduce latency and cost for simple queries while preserving deep reasoning capabilities for complex tasks.

What happened

Previously, developers building retrieval-augmented generation (RAG) applications on Amazon Bedrock had to manage separate code paths or APIs for different types of user questions. Simple lookups, such as finding a specific checklist item, required the same heavy orchestration as complex comparative questions that needed multiple search iterations. This one-size-fits-all approach often resulted in unnecessary latency and higher model usage for straightforward requests.

The new update introduces the maxAgentIteration parameter to the AgenticRetrieveStream API, with a range of 0 to 5. This single setting controls the behavior of the retrieval process. By setting the value to 1, developers can trigger "single-shot RAG," which performs one retrieval and generates an answer without any agentic planning or query rewriting. Setting it to 0 enables "retrieval-only" mode, which returns source passages without invoking a foundation model at all. Values from 2 to 5 retain the existing agentic retrieval behavior, where the system plans and executes multiple search rounds.

This consolidation means applications no longer need to integrate a second API or maintain separate logic branches for simple versus complex queries. The service manages the workflow internally, allowing developers to match the retrieval effort to the specific needs of each request dynamically. As noted in the announcement, "Applications don’t need to implement their own loop to coordinate these steps."

How it works

The core mechanism relies on how the system counts iterations. One iteration equals one foundation model call. The process always concludes with a final call to generate the answer if response generation is enabled. Therefore, a maxAgentIteration value of n allows for up to n minus 1 agentic planning rounds, with the last iteration reserved for the final response generation. It is important to note that speculative retrieval, which runs ahead of the first planning step to speed up the process, does not count against this limit.

When maxAgentIteration is set to 1, the system bypasses the planning phase entirely. It retrieves relevant passages once based on the original query and immediately passes them to the foundation model for answer generation. This is ideal for well-scoped questions where the answer exists in a single document or section. When set to 0, the system performs one guaranteed retrieval but skips the foundation model call completely, returning only the raw text passages. This is equivalent to calling the Retrieve API directly but keeps the workflow within the AgenticRetrieveStream interface.

For values between 2 and 5, the foundation model acts as a planner. It breaks complex questions into sub-queries, evaluates the evidence retrieved, and decides if further searches are needed. This iterative process helps address gaps in information, making it suitable for multi-part questions or comparisons across different documents. The developer selects the mode via application logic, rather than relying on automatic routing by the parameter itself.

Key details

• The maxAgentIteration parameter now accepts values from 0 to 5, replacing the previous limited range.
• Setting maxAgentIteration=1 enables single-shot RAG, performing one retrieval and one answer generation with no planning rounds.
• Setting maxAgentIteration=0 enables retrieval-only mode, returning passages without any foundation model calls; generateResponse must be false.
• Agentic retrieval (values 2–5) allows up to n minus 1 planning rounds, supporting query decomposition and iterative evidence gathering.
• All three modes support multiple knowledge bases, meaning single-shot retrieval is not limited to a single data source.
• Speculative retrieval, which occurs before the first planning step, does not count toward the maxAgentIteration limit.

Why it matters

For software engineers building AI assistants, this update simplifies architecture and improves cost efficiency. Previously, optimizing for low-latency responses on simple queries might have required building a separate lightweight retrieval pipeline alongside a more complex agentic system. Now, a single API call can handle both scenarios. This reduces the operational overhead of maintaining multiple integrations and ensures consistent handling of citations and trace events across all query types.

The ability to toggle between modes also provides finer control over the trade-off between speed and accuracy. In high-volume applications, such as customer support bots or internal enterprise search tools, most queries are likely simple fact-checks. Using single-shot RAG for these requests reduces token consumption and response time. For the minority of complex queries that require cross-referencing multiple documents, developers can dynamically increase the iteration limit to ensure thoroughness. This flexibility allows for better resource allocation and a more responsive user experience.

What you can do

• Update your AgenticRetrieveStream calls to include the maxAgentIteration parameter in the agenticRetrieveConfiguration object.
• Set maxAgentIteration=1 and generateResponse=true for direct, well-scoped questions to enable single-shot RAG.
• Set maxAgentIteration=0 and generateResponse=false when you need to display source passages to users without generating an AI summary.
• Use values from 2 to 5 for complex, multi-part questions that require comparing information across different documents or knowledge bases.
• Test different iteration limits with representative questions to find the optimal balance between latency and answer quality for your specific use case.
• Ensure your application logic determines the appropriate mode based on query complexity, rather than relying on the API to auto-detect it.