面向 Amazon Bedrock Managed Knowledge Base 的智能体检索

用户会提出跨越 PDF、幻灯片、工单、转录文本和网页内容的多部分、比较型及探索型问题。经典的单次检索难以应对这类问题：回答会缺失上下文，支持工单会升级，分析师则不得不耗费数小时反复执行搜索。面向 Amazon Bedrock Managed Knowledge Bases 的智能体检索（agentic retrieval）正是为这些问题而设计。

设想分析师可能提出两个问题：“比较我们 2020 年和 2023 年的战略，有什么变化？”以及“各产品线中最大的三项风险是什么？”两者都不是一次查询即可完成的查找任务。多意图问题在嵌入空间中不存在能够良好表示它的单一位置，因此返回的 top-k 分块往往是多个相互竞争子意图的平均结果。

智能体检索会对检索进行规划和迭代，并可在同一次调用中生成响应。本文将重点说明：为什么经典检索难以处理多部分问题、AgenticRetrieveStream API 的工作方式（包括请求构建和 trace 解析），以及应在何时选择它而非标准 Retrieve API。

为什么单次检索难以胜任

通过一个实际示例可以直观说明二者之间的差距。假设你已将 25 年的 Amazon 股东信摄取到一个 Managed Knowledge Base 中。你的第一个问题很直接：

“这些文档中最重要的信息是什么？”

标准 Retrieve API 按混合评分返回五个分块。在我们的测试语料中，排名最高的结果得分很高，却价值很低：它讲的是 Amazon 标志的配色方案。后续分块则涵盖招聘、建设者和差异化等内容。检索器完成了它的任务，即根据与查询嵌入的相似性进行排序。但“最重要的信息”这一表述很模糊，评分器没有任何信号可判断什么才真正重要。

现在把问题升级为一个更现实的版本：

“比较 Amazon 在 2020 年和 2023 年如何谈论招聘、长期投资和客户至上。重点发生了哪些变化？”

单次检索现在必须用一个查询向量，服务于两个时间段内的三个意图。最终通常会出现两种结果之一：一批关联松散、分散的分块，或一个被最强信号主导的紧密分块集。两者都不是人类分析师会采用的方法。

人类分析师会怎么做

人类会拆解这个问题。他们会先搜索 2020 年的招聘，再搜索 2023 年的招聘，然后分别检索各年度的投资理念。他们会阅读结果，发现信息缺口，优化搜索条件，再次执行搜索。在掌握足够证据后，他们会进行综合分析。

智能体检索将这一工作流自动化，并以 API 的形式提供。

单次检索留下的缺口

• 多部分问题： 单个嵌入可能无法良好表示多意图查询，因此 top-k 结果往往会将不同意图混在一起。
• 比较推理： “比较 A 和 B 在维度 X 上的表现”需要分别为每个对象进行有针对性的检索，而不是一次混合搜索。
• 跨来源问题： 当证据分布在多个知识库中时，静态路由规则较为脆弱，可能无法针对每个查询良好适应。
• 充分性： 经典检索不会判断“是否已经足够”。它无论如何都会返回 k 个分块。
• 探索： 有些问题需要根据第一次搜索揭示的信息进行后续搜索。单次检索无法迭代。

团队此前曾通过基于 Retrieve API 的自定义 Agent 框架来弥补这一缺口。他们提示模型进行规划，并在循环中调用 Retrieve API，管理子查询、去重以及决定何时停止。这种方法确实可行，但会使每个应用程序都需要维护自定义编排管道，每个实例都带有自身的延迟、成本和可靠性风险。

什么是智能体检索

智能体检索是 Amazon Bedrock Managed Knowledge Bases 中一种新的检索模式，可通过 AgenticRetrieveStream API 使用。它不执行单次相似性搜索，而是运行一个由基础模型驱动的规划循环：模型会拆解你的问题，针对每个部分执行检索，判断是否掌握足够证据，并在需要时继续迭代。默认情况下，它会在同一次调用中生成有依据的响应。设置 generateResponse=False，即可只返回检索结果而不生成响应。

你可以通过按顺序传输的 trace 事件看到该循环的每一步。每个事件都包含步骤和状态，因此你可以了解规划器做了什么以及原因：

• SpeculativeRetrieval： 在首次规划步骤前运行的初始检索，用于降低端到端延迟。对于单个 KB，它使用原始用户查询；对于多个 KB，它会作为探测搜索，用于路由子查询。它不计入 maxAgentIteration。
• Planning： 基础模型（FM）分析查询、审阅先前结果，并生成与可检索意图对齐的子查询。在多轮迭代之间，模型也会在此判断证据是否充分，并决定停止还是再次搜索。
• Retrieval 或 FullDocumentExpansion： 每次子查询执行对应一个事件，各自具有独立状态。在智能体检索中，如果 Agent 判断某个段落的上下文不足以回答查询，此操作/事件可以获取完整文档。需要总结、列举元素，或需要文档不同部分信息的查询，通常能从此操作中受益。如果还需要更多证据，循环可能运行多轮迭代，但会受到 maxAgentIteration 的限制。
• Result： 最终事件。它包含跨各轮迭代收集并去重的源分块。对于多 KB 请求，每个分块都会标明其 sourceRetriever。由于默认启用响应生成，除非设置 generateResponse=False，否则 result 事件还会包含有依据的回答及引用。

关于去重和 trace 的说明。 去重仅适用于最终的 result 事件。当多个子查询检索到同一个分块时，该分块只会在最终结果中出现一次。trace 事件仍可用于审阅各个规划和检索步骤。

两个参数承担了大部分调优工作。第一个是 maxAgentIteration，即“规划加检索”迭代轮数的上限。对于单个 KB，建议使用 3；对于多 KB 或比较型查询，建议使用 4–5。不过，规划器可能在评估步骤发现证据充分后提前退出。有关默认值和最大值，请参阅 Quotas and limits。

第二个是基础模型配置。foundationModelType 字段决定智能体检索使用服务托管模型还是自定义模型。当将其设置为 CUSTOM 时，请通过 foundationModelConfiguration 提供模型。

定价说明： 智能体检索按调用次数计费，所选的编排模型决定费率。使用托管模型时，每 1,000 次智能体检索调用收费 4 美元，另加每 1,000 次底层 Retrieve API 调用收费 1 美元。如果选择 Amazon Bedrock 中可用的模型，则需支付该模型的标准 Bedrock 转嫁定价，以及每 1,000 次底层 Retrieve 调用同样的 1 美元费用。更多详细信息请参阅定价页面。

API 实战讲解

现在你已经了解规划循环的工作方式，接下来我们将实际查看 AgenticRetrieveStream API。

单个知识库

最直接的场景是：一个 KB、一个查询，让规划器自行拆解。你发送请求后消费流；流会在启用响应生成时传递 trace 事件、生成响应分块，以及最终 result 事件。

import boto3
bedrock_agent_runtime = boto3.client(
    "bedrock-agent-runtime",
    region_name=REGION,
)
MODEL_ARN = (
    "arn:aws:bedrock:us-west-2:"
    "<account-id>:inference-profile/<planner-model-id>"
)
response = bedrock_agent_runtime.agentic_retrieve_stream(
    messages=[{"role": "user", "content": {"text": QUERY}}],
    retrievers=[
        {
            "configuration": {
                "knowledgeBase": {
                    "knowledgeBaseId": KB_ID,
                    "retrievalOverrides": {
                        "maxNumberOfResults": 10,
                    },
                }
            }
        }
    ],
    agenticRetrieveConfiguration={
        "foundationModelType": "CUSTOM",
        "foundationModelConfiguration": {
            "type": "BEDROCK_FOUNDATION_MODEL",
            "bedrockFoundationModelConfiguration": {
                "modelConfiguration": {
                    "modelArn": MODEL_ARN,
                }
            },
        },
        "maxAgentIteration": 3,
    },
)

# 消费 trace 事件、生成响应分块和最终结果
for event in response["stream"]:
    if "traceEvent" in event:
        attrs = event["traceEvent"]["attributes"]
        print(f"[TRACE] step={attrs.get('step')} status={attrs.get('status')}")

        if attrs.get("step") == "Retrieval":
            for chunk in attrs.get("retrievalResponse", []):
                preview = chunk.get("content", {}).get("text", "")[:60]
                print(f"    {preview}")

    elif "responseEvent" in event:
        print(event["responseEvent"]["text"], end="", flush=True)

    elif "result" in event:
        print()

        for chunk in event["result"].get("results", []):
            source_retriever = chunk.get(
                "sourceRetriever", {}
            ).get("identifier", "")
            preview = chunk.get("content", {}).get("text", "")[:80]
            print(f"[RESULT] {source_retriever} | {preview}")

这就是完整循环：一次请求，无需编排代码，并按从上到下的顺序读取流。trace 事件会告诉你规划器做了什么，result 事件会提供去重后的分块。在生产环境中，应将这些 trace 事件记录到 Amazon CloudWatch，用于成本归因、延迟预算和调试。每次迭代都包含一次规划器调用及其子查询检索，因此迭代次数将同时驱动成本和实际耗时延迟。

多个知识库

多 KB 路由是智能体检索能够做到、其他 API 无法做到的能力。你可以在一个请求中注册最多五个 Managed KB 检索器，并为每个检索器附加自然语言描述。规划器会读取这些描述，并将每个子查询路由到最相关的 KB。

response = bedrock_agent_runtime.agentic_retrieve_stream(
    messages=[{"role": "user", "content": {"text": QUERY}}],
    retrievers=[
        {
            "configuration": {
                "knowledgeBase": {
                    "knowledgeBaseId": KB_PRODUCT_DOCS,
                    "retrievalOverrides": {
                        "maxNumberOfResults": 10,
                    },
                }
            },
            "description": "公开的产品文档和 API 参考资料。",
        },
        {
            "configuration": {
                "knowledgeBase": {
                    "knowledgeBaseId": KB_SUPPORT_TICKETS,
                    "retrievalOverrides": {
                        "maxNumberOfResults": 10,
                    },
                }
            },
            "description": "已解决的客户支持工单和运行手册。",
        },
    ],
    agenticRetrieveConfiguration={
        "foundationModelType": "CUSTOM",
        "foundationModelConfiguration": {
            "type": "BEDROCK_FOUNDATION_MODEL",
            "bedrockFoundationModelConfiguration": {
                "modelConfiguration": {
                    "modelArn": MODEL_ARN,
                }
            },
        },
        "maxAgentIteration": 5,
    },
)

流的消费方式相同。路由决策会显示在结果中：每个分块都带有 sourceRetriever ID，因此你可以看到哪个 KB 回答了哪个子查询。这些描述是规划器执行路由的契约，因此应将每条描述写成对其 KB 的一句话介绍。模糊的描述会导致模糊的路由。

选择合适的检索 API

Managed Knowledge Bases 提供两个查询接口：Retrieve 和 AgenticRetrieveStream。应根据问题的形态进行选择。

对于简短、边界明确且一次相似性搜索已足够的问题，请使用 Retrieve。它没有规划器，单次调用成本最低、延迟最小，并且你可以完全控制如何生成答案。

当问题具有多部分、比较性、探索性，或横跨多个知识库时，请使用 AgenticRetrieveStream。它会拆解问题、按意图检索、评估证据充分性，并能在同一次调用中生成有依据的响应；你也可以让它只返回分块，再使用自行控制的模型进行综合。由于它会发起多次模型调用，因此成本更高、耗时更长，但能够发现单次搜索可能遗漏的证据。

特性	Retrieve	AgenticRetrieveStream
输出	原始分块 + 相关性评分	去重后的分块（流式），可选的有依据回答
多 KB 支持	否	是，最多 5 个。
查询拆解	否	是
流式传输	仅同步	始终支持
用户查询大小，英文文本（字符）	10,000	10,000
每次调用的基础模型成本	无	多次调用
延迟	最低	最高
自托管 KB（VECTOR）	是	否（仅限 Managed KB）
相关性评分	直接在结果中提供	仅在 trace 事件中提供
重排序	可选	可选（所有检索器共用一个重排序器

Your users ask multi-part, comparative, and exploratory questions that span PDFs, slides, tickets, transcripts, and web content. Classic single-shot retrieval breaks down on these questions. Answers miss context, support tickets escalate, and analysts waste hours re-running searches. Agentic retrieval for Amazon Bedrock Managed Knowledge Bases is designed for these questions.

Consider two questions an analyst might ask: “Compare our 2020 and 2023 strategy. What changed?” and “What are the three biggest risks across product lines?” Neither is a single-shot lookup. A multi-intent question has no single point in embedding space that represents it well, so top-k chunks come back as an average of competing sub-intents.

Agentic retrieval plans and iterates over retrieval and can generate a response in the same call. This post focuses on why classic retrieval falls short on multi-part questions, how the AgenticRetrieveStream API works (including request construction and trace parsing), and when to choose it over the standard Retrieve API.

Why single-shot retrieval falls short

A worked example makes the gap concrete. Suppose you have ingested 25 years of Amazon shareholder letters into a Managed Knowledge Base. Your first question is direct:

“What is the most important message in the documents?”

The standard Retrieve API returns five chunks by hybrid score. In our test corpus, the top result is high-scoring but low-value: it covers the Amazon logo color scheme. The following chunks cover hiring, builders, and differentiation. The retriever did its job and ranked by similarity to the query embedding. But “ most important message ” is vague, and the scorer has no signal for what matters.

Now escalate to a realistic question:

“Compare how Amazon talked about hiring, long-term investment, and customer obsession in 2020 vs 2023. Where did emphasis shift?”

Single-shot retrieval must now serve three intents across two time periods with one query vector. You get one of two outcomes: a scatter of loosely related chunks, or a tight cluster dominated by the strongest signal. Neither is what a human analyst would do.

What a human analyst would do

A human would decompose the question. They would search hiring in 2020, then hiring in 2023, then investment philosophy in each year. They would read the results, notice gaps, refine the search, and run it again. With enough evidence in hand, they would synthesize.

Agentic retrieval automates this workflow as an API.

Gaps left by single-shot retrieval

• Multi-part questions: A single embedding may not represent a multi-intent query well, so top-k results tend to blend intents together.
• Comparative reasoning: “Compare A and B across dimension X” requires targeted retrieval per item, not one blended search.
• Cross-source questions: When evidence spans multiple knowledge bases, static routing rules are brittle and might not adapt well per query.
• Sufficiency: Classic retrieval doesn’t judge “enough.” It returns k chunks regardless.
• Exploration: Some questions need follow-up searches based on what the first results reveal. Single-shot retrieval can’t iterate.

Teams have addressed this gap with custom agent frameworks built on the Retrieve API. They prompt a model to plan and call Retrieve API in a loop, manage sub-queries, deduplicate, and decide when to stop. It works, but it becomes custom plumbing in every application, each instance carrying its own latency, cost, and reliability risks.

What agentic retrieval is

Agentic retrieval is a new retrieval mode in Amazon Bedrock Managed Knowledge Bases, available through the AgenticRetrieveStream API. Instead of one similarity search, it runs a planning loop driven by a foundation model: the model decomposes your question, retrieves against each part, judges whether it has enough evidence, and iterates as needed. It generates a grounded response by default in the same call. Set generateResponse=False to return retrieval results without generating a response.

You see every step of that loop as an ordered stream of trace events. Each event carries a step and a status, so you can see what the planner did and why:

• SpeculativeRetrieval: An initial retrieval that runs before the first planning step to reduce end-to-end latency. With a single KB, it uses the raw user query. With multiple KBs, it is a probe search used to route sub-queries. It doesn’t count toward maxAgentIteration.
• Planning: The foundation model (FM) analyzes the query, reviews prior results, and emits sub-queries aligned to retrievable intents. Between iterations, this is also where the model judges sufficiency and decides whether to stop or search again.
• Retrieval or FullDocumentExpansion : One event per sub-query execution, each with its own status. In agentic retrieval, this action/event can fetch a full document if the agent determines that the passage context is insufficient to answer the query. Often, queries that require summarization, listing elements, or information from various parts of a document benefit from this action. The loop may run several iterations if more evidence is needed, bounded by maxAgentIteration.
• Result: The final event. It contains the deduplicated source chunks collected across the iterations. For multi-KB requests, each chunk identifies its sourceRetriever. Because response generation is enabled by default, the result event also contains the grounded answer and citations unless you set generateResponse=False.

A note on deduplication and the trace. Deduplication applies only to the final result event. When multiple sub-queries retrieve the same chunk, that chunk appears only once in the final results. Trace events remain available for reviewing the individual planning and retrieval steps.

Two parameters do most of the tuning. The first is maxAgentIteration, the ceiling on planning-plus-retrieval iterations. Use 3 for a single KB and 4–5 for multi-KB or comparative queries, though the planner may exit early after its evaluation step finds the evidence sufficient. See Quotas and limits for defaults and maximums.

The second is the foundation model configuration. The foundationModelType field determines whether agentic retrieval uses the service-managed model or a custom model. When you set it to CUSTOM, provide the model through foundationModelConfiguration.

Note on pricing: Agentic retrieval is priced per call, and the model you choose for the orchestration sets the rate. With the managed model, you pay $4 per 1,000 agentic retrieval calls plus $1 per 1,000 underlying Retrieve API calls. If you choose a model available in Amazon Bedrock, you pay standard pass-through Bedrock pricing for that model plus the same $1 per 1,000 underlying Retrieve calls. See more details on the pricing page.

API walkthrough

Now that you have seen how the planning loop works, we examine the AgenticRetrieveStream API in practice.

Single knowledge base

The most direct case: one KB, one query, let the planner decompose. You send the request, then consume the stream, which delivers trace events, generated-response chunks when response generation is enabled, and a final result event.

import boto3
bedrock_agent_runtime = boto3.client(
    "bedrock-agent-runtime",
    region_name=REGION,
)
MODEL_ARN = (
    "arn:aws:bedrock:us-west-2:"
    "<account-id>:inference-profile/<planner-model-id>"
)
response = bedrock_agent_runtime.agentic_retrieve_stream(
    messages=[{"role": "user", "content": {"text": QUERY}}],
    retrievers=[
        {
            "configuration": {
                "knowledgeBase": {
                    "knowledgeBaseId": KB_ID,
                    "retrievalOverrides": {
                        "maxNumberOfResults": 10,
                    },
                }
            }
        }
    ],
    agenticRetrieveConfiguration={
        "foundationModelType": "CUSTOM",
        "foundationModelConfiguration": {
            "type": "BEDROCK_FOUNDATION_MODEL",
            "bedrockFoundationModelConfiguration": {
                "modelConfiguration": {
                    "modelArn": MODEL_ARN,
                }
            },
        },
        "maxAgentIteration": 3,
    },
)

# Consume trace events, generated-response chunks, and the final result
for event in response["stream"]:
    if "traceEvent" in event:
        attrs = event["traceEvent"]["attributes"]
        print(f"[TRACE] step={attrs.get('step')} status={attrs.get('status')}")

        if attrs.get("step") == "Retrieval":
            for chunk in attrs.get("retrievalResponse", []):
                preview = chunk.get("content", {}).get("text", "")[:60]
                print(f"    {preview}")

    elif "responseEvent" in event:
        print(event["responseEvent"]["text"], end="", flush=True)

    elif "result" in event:
        print()

        for chunk in event["result"].get("results", []):
            source_retriever = chunk.get(
                "sourceRetriever", {}
            ).get("identifier", "")
            preview = chunk.get("content", {}).get("text", "")[:80]
            print(f"[RESULT] {source_retriever} | {preview}")

That is the whole loop: one request, no orchestration code, and a stream you read top to bottom. The trace events tell you what the planner did. The result event gives you the deduplicated chunks. In production, log these trace events to Amazon CloudWatch for cost attribution, latency budgeting, and debugging. Each iteration is one planner invocation plus its sub-query retrievals, so the number of iterations is what drives both cost and wall-clock latency.

Multiple knowledge bases

Multi-KB routing is what agentic retrieval does that the other APIs cannot. Register up to five Managed KB retrievers in one request and attach a natural-language description to each. The planner reads those descriptions to route each sub-query to the most relevant KB.

response = bedrock_agent_runtime.agentic_retrieve_stream(
    messages=[{"role": "user", "content": {"text": QUERY}}],
    retrievers=[
        {
            "configuration": {
                "knowledgeBase": {
                    "knowledgeBaseId": KB_PRODUCT_DOCS,
                    "retrievalOverrides": {
                        "maxNumberOfResults": 10,
                    },
                }
            },
            "description": "Public product documentation and API reference.",
        },
        {
            "configuration": {
                "knowledgeBase": {
                    "knowledgeBaseId": KB_SUPPORT_TICKETS,
                    "retrievalOverrides": {
                        "maxNumberOfResults": 10,
                    },
                }
            },
            "description": "Resolved customer support tickets and runbooks.",
        },
    ],
    agenticRetrieveConfiguration={
        "foundationModelType": "CUSTOM",
        "foundationModelConfiguration": {
            "type": "BEDROCK_FOUNDATION_MODEL",
            "bedrockFoundationModelConfiguration": {
                "modelConfiguration": {
                    "modelArn": MODEL_ARN,
                }
            },
        },
        "maxAgentIteration": 5,
    },
)

You consume the stream the same way. The routing decision shows up in the result: each chunk carries a sourceRetriever ID, so you can see which KB answered which sub-query. The descriptions are the contract the planner routes on, so write each as a one-sentence pitch for its KB. Vague descriptions lead to vague routing.

Choosing the right retrieval API

Managed Knowledge Bases give you two query surfaces: Retrieve and AgenticRetrieveStream. You pick based on the shape of the question.

Use Retrieve for short, well-scoped questions where one similarity search is enough. It has no planner, the lowest cost per call, and the tightest latency, and you keep full control over how you generate an answer.

Use AgenticRetrieveStream when questions are multi-part, comparative, exploratory, or span multiple knowledge bases. It decomposes the question, retrieves per intent, evaluates sufficiency, and can generate a grounded response in the same call, or return chunks for you to synthesize with a model you control. It costs more and takes longer because it makes multiple model calls, but it finds evidence a single search can miss.

Feature	Retrieve	AgenticRetrieveStream
Output	Raw chunks + relevance scores	Deduplicated chunks (streaming), optional grounded answer
Multi-KB support	No	Yes, up to 5.
Query decomposition	No	Yes
Streaming	Sync only	Always
User query size, English text (characters)	10,000	10,000
Foundation model cost per call	None	Multiple invocations
Latency	Lowest	Highest
Self-Managed KB (VECTOR)	Yes	No (Managed KB only)
Relevance scores	In results directly	In trace events only
Reranking	Optional	Optional (one reranker across retrievers)
Guardrails	Supported	BLOCK only (MASK unsupported)

How agentic retrieval performs on benchmarks

We evaluated agentic retrieval on MuSiQue (Trivedi et al., 2022), a public benchmark of multi-hop questions. On these questions it showed 20 percent absolute recall improvement over single-shot retrieval, with the largest gains on the hardest questions. Single-hop questions show smaller gains (under five points).

Each MuSiQue question is designed to require two, three, or four retrieval steps, and a human annotator identified the exact document chain needed to answer it. That chain is an oracle decomposition: the ideal retrieval plan to measure against.

Question Complexity	Δ (Gain) with Agentic Retrieve	Agentic Hops (avg)
2-hop questions	+22.8	1.98
3-hop questions	+31.9	3.50
4-hop questions	+37.3	4.78

Two patterns stand out. First, the harder the question, the bigger the gain. The more steps a question requires, the more a single search misses, and the more agentic retrieval recovers. Questions that need several steps simply cannot be answered in one pass.

Second, the system takes about as many steps as the question actually needs. The benchmark tells us the ideal number of steps for each question (the chain a human expert traced). Agentic retrieval’s own number of steps stays within roughly one of that ideal, so it searches enough to answer the question without wandering.

Example

We demonstrate how agentic retrieval solves a 4-hop query in the MuSiQue dataset.

Query: “When did the explorer reach the headquarters location of the group Study in Brown’s record label is part of?”

Agentic Retrieve Trace:

Hop	Retrieved Gold Documents (about)
0	Study in Brown
1	Emarcy Records
2	The Right Stuff Records
3	< recovered same documents as 2>
4	Santa Monica California

We illustrate the retrieval process using the following t-SNE plot over the corpus representation space. It shows how single-step Retrieve results (dotted-red boundary) compare to multi-step agentic retrieve. In each hop, agentic retrieve breaks down the query. It arrives at the document containing the answer.

Best practices

These practices reduce cost, improve latency, and keep agentic retrieval predictable in production.

• Start with a small, fast planner model. Agentic retrieval makes many short calls. A large planner rarely justifies the latency.
• Set maxAgentIteration based on scope. Use 3 for single-KB, 4–5 for multi-KB. Measure, then tune.
• Write retriever descriptions like product marketing. Be specific, concrete, and distinctive.
• Stream the trace to Amazon CloudWatch Logs with a correlation ID per request. This supports replay and debug.
• Plan costs by iterations, not by tokens alone. Iterations drive both cost and wall-clock latency.
• Combine with reranking. Agentic retrieval can use a reranking model to improve the relevance of retrieved results. For AgenticRetrieveStream, configure reranking through agenticRetrieveConfiguration.rerankingModelType. When using a custom reranking model, provide its configuration through agenticRetrieveConfiguration.rerankingConfiguration.
• Treat results as evidence, not as an answer. Synthesize with a model you control so you can enforce tone, citations, and guardrails.

Security, governance, and observability

Agentic retrieval inherits the access model of Managed Knowledge Bases. The calling AWS Identity and Access Management (IAM) principal needs four actions: bedrock:AgenticRetrieveStream to invoke the stream; bedrock:Retrieve and bedrock:GetDocumentContent, scoped to specific knowledge base ARNs, to retrieve passages and full document content; and bedrock:InvokeModelWithResponseStream to invoke the planner model and stream the generated response. For the full policy and setup, see the documentation.

Two details are specific to agentic retrieval and worth calling out. Guardrails are configured through policyConfiguration.bedrockGuardrailConfiguration, and only the BLOCK action is supported; the MASK action is not supported with agentic retrieval. Because the planner generates intermediate sub-queries, those sub-queries are as important to audit as the final results. Log the full trace to Amazon CloudWatch so you can review what the planner searched for, not just what it returned.

For observability, Managed Knowledge Bases emit CloudWatch metrics for invocations, client errors, server errors, and throttles. AgenticRetrieveStream also emits the TotalIterationCount metric. Managed knowledge base telemetry integrates with Amazon Bedrock AgentCore Observability. See the documentation for the full metric list, namespaces, and log routing options.

Conclusion

This post explained why single-shot retrieval falls short on multi-part questions, introduced the AgenticRetrieveStream API, and showed when to choose it over standard Retrieve. Agentic retrieval moves planning, iteration, and sufficiency evaluation into the Managed Knowledge Bases service, so you get a single, observable API with consistent security, logging, and cost behavior instead of custom orchestration in every application.

Start with Retrieve for direct lookups, and reach for AgenticRetrieveStream when users ask multi-part, comparative, or exploratory questions, or when evidence spans multiple knowledge bases. To build your first agentic knowledge base, follow the companion notebook on GitHub. For API details, see the AgenticRetrieveStream API reference, or explore the feature in the Amazon Bedrock console.

---

About the authors

Omar Elkharbotly

Omar is a Senior GenAI/ML Specialist Solutions Architect at AWS. He works with enterprise customers across the UK and Ireland to design and deploy generative AI and machine learning solutions using Amazon Bedrock, Amazon Bedrock AgentCore, and the broader AWS AI/ML stack to build scalable, production-ready applications.

Shreya Pawaskar

Shreya is a Delivery Consultant specializing in AI/ML at AWS Professional Services. She helps enterprise customers design and deploy agentic retrieval and generative AI solutions on Amazon Bedrock. She holds a Master’s degree in Computer Science from the University of California, Irvine. Outside of work, she enjoys hiking Bay Area trails and discovering new restaurants.

Sailik Sengupta

Sailik is a Senior Scientist in the Agentic AI team at AWS. They specialize in designing large scale retrieval and reranking systems, and alignment and decoding of language models. They hold a Ph.D. in Computer Science from Arizona State University and was awarded an IBM Ph.D. Fellowship for their work on AI-driven Cyber-defenses. Their work spans large language model alignment, embedding models, game theory, automated task planning, and cybersecurity, with contributions published at venues including ACL, ICLR, NAACL, AAAI, EMNLP, NeurIPS, etc. Outside of work, he loves to travel, hike, and read books.