# Single-shot and agentic retrieval with Amazon Bedrock Managed Knowledge Base > Source: > Published: 2026-11-09 20:13:18+00:00 ## [Artificial Intelligence](https://aws.amazon.com/blogs/machine-learning/) # Single-shot and agentic retrieval with Amazon Bedrock Managed Knowledge Base A banking operations employee starts the morning by asking an internal AI assistant which documents are needed to open a business account. The answer is in a single checklist. A few hours later, the same employee asks how those requirements differ across sole proprietorships, LLCs, and partnerships with multiple owners. That answer is spread across several policy guides. One assistant has to handle both questions, quickly and cheaply for the first and thoroughly for the second. Applications need a way to match retrieval effort to each request without building separate systems for simple and complex questions. Amazon Bedrock Managed Knowledge Base now supports single-shot Retrieval Augmented Generation (RAG) and retrieval-only requests through `AgenticRetrieveStream`. With single-shot RAG, the service searches your knowledge bases once and uses a foundation model (FM) to generate an answer from the passages it finds. With retrieval-only requests, the service returns the matching passages without generating an answer, so your application or the user can work with the source text directly. These modes join the existing agentic retrieval, where the service plans and runs multiple searches before answering. You can now use the same API for both of the employee’s questions: single-shot RAG for the checklist lookup and agentic retrieval for the cross-policy comparison. In this post, we explain how the new settings work and when to use each mode. We use an illustrative internal banking policy assistant to show how single-shot RAG handles direct questions and how agentic retrieval supports comparisons across policy documents. We also show how to configure retrieval-only requests when an employee needs to review source passages rather than a generated answer. ## Key benefits [Agentic retrieval](https://docs.aws.amazon.com/bedrock/latest/userguide/kb-test-agentic-retrieve.html) helps an assistant answer questions that require more than one search. A foundation model breaks the question into sub-queries, searches the relevant knowledge bases, and evaluates whether the results provide enough information to answer the original question. If it identifies gaps, it can refine the search and retrieve additional evidence, within the configured iteration limit. For application builders, this provides several benefits: - **Better support for multi-part questions –** Targeted searches can find evidence for each part of a question instead of relying on one search to cover everything. In the banking example, the assistant can look up requirements for sole proprietors and LLCs separately before comparing them. - **Follow-up searches when information is missing –** The planner can use what it finds to decide what to search for next. It can also retrieve a full document when a passage doesn’t provide enough context, helping address gaps that a single retrieval might leave unresolved. - **Answers with supporting evidence –** When response generation is enabled, the service combines retrieved information into an answer with citations. Trace events show the planning and retrieval steps, helping developers inspect how the answer was produced. - **Less custom orchestration –** The service manages the planning, retrieval, evaluation, and response-generation workflow through one API. Applications don’t need to implement their own loop to coordinate these steps. These agentic capabilities remain valuable for complex questions. For straightforward lookups, applications also need a way to retrieve and answer without additional planning. The expanded `maxAgentIteration` range closes that gap. With one parameter, you can choose one of three modes for each request: - **Retrieval-only** returns passages without generating an answer. - **Single-shot RAG** retrieves once and generates an answer, with no planning rounds. - **Agentic retrieval** plans and runs multiple searches for complex questions. Single-shot RAG uses one foundation model call to generate the answer, which can reduce latency and model usage compared with agentic retrieval. Retrieval-only requests make no foundation model calls. You can balance speed and answer quality for each request, without integrating a second API or maintaining separate code paths for simple and complex queries. ## How retrieval iterations are counted Before walking through the new values, it helps to anchor on how iterations are counted, because that is what makes the behavior predictable. One iteration equals one foundation model call. The loop always ends with a single answer-generation call. A value of *n* buys up to *n* minus 1 agentic planning rounds, with the last iteration reserved for generating the response. Each planning round is one query rewrite plus a retrieval. More iterations means more planning rounds and better results on hard questions. Fewer iterations means lower latency. One thing that doesn’t count: speculative retrieval. The initial retrieval that runs ahead of the first planning step is retrieval, not an iteration. It never counts against your maxAgentIteration value, and it only ever makes a request faster. Keep that distinction in mind as you read the following values. ## What’s new The range is now 0–5. All three modes support multiple knowledge bases, including `maxAgentIteration=0` and `1`. Single-shot retrieval doesn’t mean a single knowledge base. Agentic mode adds query decomposition, evidence evaluation, and iterative searches, rather than exclusive access to multiple knowledge bases. ### maxAgentIteration = 1: Basic RAG (the headline use case) This is single-shot RAG: one retrieval, then one answer. No agentic planning, no query rewriting. The API retrieves once against your query and generates a response grounded in those passages. This is the *retrieve once, then generate a response* pattern that previously wasn’t expressible through this API. Pair it with `generateResponse=true` to get a generated answer grounded in the retrieved passages. If you only need the passages, use `maxAgentIteration=0` instead, as described in the next section. If most of your traffic is well-scoped, direct questions, this is likely the setting you want as a default. ### maxAgentIteration = 0: Passages only, zero LLM calls This runs one guaranteed retrieval and generates nothing. No foundation model is invoked. It is equivalent to calling the Retrieve API directly. This makes it most useful for callers who are already standardized on `AgenticRetrieveStream` and would rather change a parameter than switch APIs. Because no large language model (LLM) is called, there is no answer to generate. Setting `generateResponse=true` at this value is invalid and returns a 4xx error, because generating an answer requires an LLM call. ### maxAgentIteration = 2 to 5: Agentic mode, unchanged In [agentic mode](https://docs.aws.amazon.com/bedrock/latest/userguide/kb-test-agentic-retrieve.html), a foundation model breaks complex questions into focused sub-queries and retrieves evidence in multiple steps, including across multiple knowledge bases. It evaluates the retrieved information and can refine its searches when evidence is missing. This approach can improve retrieval accuracy for multi-part and comparative questions that a single search might not fully address. With response generation enabled, a value of *n* allows up to *n* minus 1 planning rounds before generating an answer grounded in the retrieved evidence. Existing requests using values from 2–5 retain their current behavior. ## Choosing a value One way to reason about it: | **`maxAgentIteration`** | **What you get** | **Best for** | | 0 | One retrieval, no generation, zero LLM calls | Passage retrieval. Callers standardized on this API who want Retrieve-style behavior | | 1 | One retrieval plus one answer | Single-shot RAG for direct, well-scoped questions | | 2 to 5 | Up to *n* minus 1 planning rounds, then an answer | Multi-part, comparative, exploratory, and cross-knowledge-base questions | The lower the value, the faster and more predictable the call. The higher the value, the more the planner can decompose and refine on genuinely hard questions. Start low for simple traffic, raise it when accuracy on complex queries matters more than latency. ## In practice: An internal banking policy assistant Consider a fictional bank whose operations team uses an internal assistant backed by a knowledge base of account-opening procedures, documentation checklists, and policy guides. Employees use the assistant to locate and understand the bank’s documented requirements. The following examples illustrate how the application can select a retrieval mode for each workflow. They don’t describe a customer deployment or measured results. The following diagram shows how the banking assistant selects a retrieval mode for each request. An employee asks the assistant a question. The application chooses a retrieval mode and sends the request to `AgenticRetrieveStream`. With single-shot RAG, the service searches the knowledge base once and generates an answer. With agentic retrieval, the service splits the question into parts, searches several times, and then generates an answer with citations. With retrieval-only, the service returns source passages without generating an answer. The following sections explain each mode. ### Answer a direct documentation question An employee asks, “What documents are required to open a business checking account for a sole proprietor?” In this example, the bank maintains a dedicated checklist that contains the answer. The application sets `maxAgentIteration=1` and `generateResponse=true` to retrieve relevant passages and generate a response, without query rewriting or agentic planning. This is the single-shot RAG pattern: one retrieval, followed by one answer-generation call. It avoids a planning step when the question and supporting content are already well scoped. ### Compare requirements across policy documents Another employee asks, “How do account-opening requirements differ for sole proprietors and LLCs, and what additional checks, if any, apply to nonresident owners under our policy?” Answering this question might require information from separate procedures and ownership-verification guides. For this workflow, the application can set `maxAgentIteration=4` and `generateResponse=true`, allowing up to three planning rounds before generating an answer. The planner can break the question into sub-queries, retrieve relevant evidence, and refine its search if information is missing. The appropriate iteration limit should be evaluated against representative questions rather than assuming that a higher value always produces a better answer. ### Show source passages without generating an answer An employee reviewing an account-opening procedure might want the relevant policy text instead of a generated summary. The application sets `maxAgentIteration=0` and `generateResponse=false` to return passages with no language model calls. It can then display those passages and their source references for the employee to review. All three workflows use `AgenticRetrieveStream`. The application chooses the iteration limit and whether to return a generated answer. Selecting the mode is application logic, not automatic routing provided by this parameter. The assistant supports policy lookup and comparison. It doesn’t approve accounts or replace the bank’s review and authorization processes. ## Solution overview The following example shows a complete agentic request. The sections after it adapt it for single-shot RAG and retrieval-only modes. ### Select a retrieval mode for the banking assistant The sample code demonstrates the three workflows using fictional policy documents. ## Example: Single-shot RAG Setting up basic RAG is a one-line change from an agentic call. Set `maxAgentIteration` to 1 and keep response generation on. You consume the stream the same way you always have. The difference is what’s in it: a single retrieval and one grounded answer, with no planning trace events in between.