Bedrock's New Retrieval Modes: Give Each Customer Question a Budget

AWS's November 9 announcement makes a useful product choice more explicit: a knowledge assistant can return source passages, retrieve once and write an answer, or spend additional effort searching. The company describes those choices within one interface, rather than requiring every question to follow the same agentic path. See the original announcement.

For founders building customer portals, support tools or internal knowledge products, the opportunity is to give different questions different budgets. A customer asking where to find an export guide should not automatically receive the same treatment as someone comparing two migration procedures. Extra searching has to earn its place through a better customer outcome.

There is an immediate adoption check. The live parameter reference now permits a minimum of zero, consistent with the announcement, although a search-reader copy we encountered still showed two. Use the current official documentation and verify the intended environment before promising a new mode to customers.

This guide provides a question-routing worksheet, a fictional product example and a controlled pilot plan. The recommendation is to approve additional retrieval for a defined task class only when it improves a supported, usable answer within that class's waiting and cost limits. We have not called the new modes, measured their performance or inspected a customer bill. The proposed tests below are product acceptance work, not reported experimental results.

1. Read the release as a choice about customer effort

According to AWS, maxAgentIteration=0 with generateResponse=false returns passages without an LLM call; one with generation enabled retrieves and answers without planning; two through five retain agentic behavior. With generation enabled, the last iteration is reserved for the answer, so four allows up to three planning rounds. The value does not mean four searches, four documents or four independently checked answers. AWS also says multiple knowledge bases are available in all three modes. These are vendor descriptions, not our runtime observations.

The founder's decision begins one level above those settings: what is the customer trying to finish? Finding an exact paragraph, understanding a documented procedure and comparing several procedures are different tasks. A single chat box can conceal those differences and encourage a team to buy the most elaborate response for every request.

Consider the cost imposed on the customer. A long explanation can be an obstacle when the customer needs a source they can send to a colleague. A fast excerpt can be inadequate when they need to understand which instructions apply to their situation. Waiting for a second search is defensible when it resolves a named gap; waiting for an impressive-looking stream of activity is harder to justify.

Make that tradeoff part of the product brief. Write “help the workspace administrator find and understand the applicable export procedure” before writing “add agentic RAG.” That sentence supplies a completion condition, an audience and a boundary. It also leaves room for a well-organized help page to outperform a conversational feature.

2. Separate finding evidence, explaining it and deciding what to do

Retrieval selects material from a searchable collection. A passage is a returned piece of that material. Generation produces new wording using a model. RAG, or retrieval-augmented generation, combines retrieved information with generation; the original RAG research describes combining model knowledge with an external retrieval mechanism. It is historical context, not evidence about this week's AWS feature. Agentic retrieval adds planning: the system may break a question into smaller searches and assess whether it has enough information. Routing is the application's choice of which path to use. These terms describe separate responsibilities. A retrieval mode does not, by itself, define which customers deserve an answer, which documents they may see or whether the resulting advice is appropriate.

For a founder, that separation prevents a common purchasing mistake. A builder may demonstrate a comparison across two documents and call the assistant “autonomous.” Ask what changed in the customer's ability to finish the task. Did the comparison include the relevant exception? Could the customer open the evidence? Was the assistant permitted to decide eligibility, or only to explain the documented rule?

Keep product authority separate from explanation. An assistant that explains an export procedure should not silently become the system that approves an export or changes retention settings. Those actions require their own authorization and confirmation behavior. Additional retrieval can improve the information available to a decision without granting permission to execute it.

3. Verify availability before buying a migration

The live parameter reference, read directly on November 10, lists a minimum of zero. An older search-reader copy showed two. The direct page resolves that specific discrepancy; it does not establish that your installed SDK, account and deployed application have successfully used the new mode. Keep a dated copy of the documentation used for the purchasing decision.

Ask the builder for a small availability receipt before approving migration: target Region, account, knowledge-base type, SDK version, request settings, response or validation error, and test time. Use non-sensitive test documents. A successful console demonstration in somebody else's environment is insufficient evidence that your deployed application accepts the same request.

Check the prerequisite as well. AWS's agentic retrieval guide specifies a managed knowledge base. A team already using a customer-managed vector store should not assume that a parameter change transfers the feature to that architecture. Establish the existing setup before estimating migration effort.

Keep the customer-facing experience independent of the rollout. If the new setting is unavailable, retain the existing tested path or a separately validated source-search experience. Do not quietly substitute a longer agentic run while describing it as the faster path. If no acceptable fallback exists, leave the feature in a clearly limited pilot.

This checkpoint is narrow. It does not require a founder to implement the API. It requires enough evidence to distinguish “announced,” “accepted by our environment,” and “acceptable for our users.” Those are three different milestones.

4. Route by the missing information, not by question length

A short question can require several sources. “Does this apply to my old workspace?” may depend on a launch date, an account type and an exception. A long question can be a straightforward request for a particular document. Character count is a poor substitute for understanding the task.

Start with explicit product intents where possible. A “Show the guide” control can request source material. “Explain this section” can request an answer grounded in that section. “Compare these procedures” can justify a broader search, subject to evidence and permission boundaries. This is a proposed interface pattern, not a built-in AWS router.

For free-text requests, identify the gap that additional searching might close. “We have the new procedure but not the legacy exception” is a useful escalation reason. “The answer is short” is not. Nor is a model's confident statement that it should think harder a reliable quality measure.

Define a stop condition for each route. Stop when the allowed sources support the required points, the waiting budget expires, the permitted work is exhausted, or a conflict needs human resolution. Do not escalate a question whose answer is absent merely to make a refusal feel more diligent.

Ambiguity calls for a different response. If the user has not identified the workspace type, asking a focused clarification may be more useful than retrieving both policies and guessing. Keep that interaction short and explain why the detail matters. Avoid asking the customer for information that the application can already retrieve appropriately from their account.

5. Use one product scenario to expose three different promises

Imagine Workspace Guide, a fictional assistant for a small collaboration product. Its approved help collection contains a current export guide, an older-workspace exception and a retention settings explanation. The following cases are design examples. They are not AWS demonstrations, customer reports or measured results.

A workspace administrator asks, “Where is the export guide?” The intended result is an accessible source with a meaningful title and relevant excerpt. A source-only path is a reasonable candidate. The acceptance task is to find the correct current guide without having to read a generated essay. If the result points to an obsolete guide, removing generation has not made the product correct.

The same administrator asks, “What should I prepare before requesting an export?” A concise explanation may be appropriate if the approved guide contains the complete answer. The reviewer should check every required preparation step, any limitation and the link back to the section. Returning a relevant paragraph does not establish that the generated checklist preserved all its conditions.

A third question asks, “How does export preparation differ for older and newer workspaces?” Additional retrieval is worth testing because the answer may need the exception and the current guide together. The product should expose unresolved conflicts instead of blending them. If one guide's revision date is missing, the answer must not invent a chronology to declare the conflict solved.

Finally, consider “Can you export my workspace now?” That is outside this knowledge feature's authority. The answer can explain where to start the approved request; it cannot treat a successful comparison as approval to move customer data. This case belongs in the test set even though none of the retrieval modes should execute it.

The product promises are therefore distinct: help locate evidence, help understand it, and help compare it. Operational action remains a separate capability. That distinction should be visible in the acceptance notes and in what the interface tells the customer.

6. Give the builder a reusable question-budget worksheet

Use the following worksheet for each task class. It is a proposed founder artifact, not an AWS configuration schema. Complete it before seeing the most polished demo, then fill the observed-results column from saved runs. Avoid setting thresholds retroactively to fit the preferred result.

Decision field	What the founder and builder should record
Customer and task	Who is asking, and what must they be able to finish?
Allowed evidence	Approved collection, document versions and applicable access scope.
Initial route	Source-only, single-shot explanation, or additional retrieval candidate; environment verified separately.
Escalation reason	The specific missing point another search could resolve.
Required support	Necessary facts, exceptions and citations; who can judge them.
Waiting limit	Maximum useful elapsed time from the user's initial request, including escalation.
Spending limit	Per-attempt ceiling and task-class operating budget, including failed work.
Unresolved outcome	Clarification, useful source handoff, honest non-answer or human review.
Evidence receipt	Settings, actual route, source versions, timings, errors and reviewer decision.
Release decision	Owner, allowed audience, stop conditions, fallback and next review trigger.

A filled planning record might read: WG-01; older-versus-newer export preparation; administrator; current guide plus legacy exception; additional retrieval candidate; required difference is the preparation exception; stop if document applicability conflicts; provide both sources and request review. Waiting and spending limits remain to be agreed before the run. This is a planning record, not a passing test result.

Attach the corresponding source excerpts to the completed record in an access-controlled review space. A screenshot of a good answer alone cannot show whether the sources changed, whether a fallback ran or whether the user had permission to see the passage.

Assign a reviewer who understands the underlying procedure. The founder can judge clarity and whether the output serves the task; a procedure owner should judge exceptions and applicability. If neither can verify a claim, mark it unresolved instead of accepting it because it has a citation.

7. Compare routes without hiding the customer journey

Freeze a small, representative question set and source snapshot for the first comparison. Include direct lookups, explanations, cross-document questions, missing information, ambiguous requests, contradictory documents and unauthorized access attempts. Select the set from real task patterns where available, with sensitive details removed appropriately. Do not manufacture an evaluation from only questions the demo already handles well.

Run the relevant routes against the same question and evidence snapshot. Preserve route settings and failures. If the builder changes the prompt, documents or routing rule between candidates, label that as another variant; otherwise you cannot tell whether retrieval effort caused the improvement.

Review answers without route labels when practical. Score task completion, necessary-point coverage, source support, unresolved uncertainty and ability to open the evidence. The ALCE research distinguishes fluency, correctness and citation quality. That is a useful evaluation distinction; its historical results do not supply a current Bedrock accuracy rate.

Measure waiting from the initial customer request to the usable outcome. If a quick route fails and then escalates, include both stages and the handoff. A fast first token does not establish that the customer received the right information sooner. Record timeouts and abandonment separately from successful completions. Repeat non-deterministic cases, vary route order to expose warm-cache or traffic effects, and keep repeated attempts linked to the same question. If you cannot control those conditions, record them as comparison limits. A route that begins earlier should not receive credit for an easier test window.

For a bounded task with a defined start and finish, keep all genuine attempts in the denominator, including failures. This borrows the measurement discipline in GOV.UK's completion-rate guidance; it does not turn every general knowledge query into a government-style transaction. State your own completion definition and report human-assisted completion separately.

A small pilot can expose a broken route. It cannot establish universal superiority or the absence of rare failures. Publish the size and composition of the internal test set in the release note, and retain difficult cases for the next revision.

8. Budget the entire attempt, including escalation and review

A smaller iteration limit is a control on a kind of work, not a complete invoice estimate. The Bedrock pricing page separates index storage, retrieval, agentic planning and model choices, with additional service charges possible. Do not infer a new mode's exact total price from the iteration number or promise that source-only requests are free.

Ask for observed usage and a billable-component explanation for the precise path being piloted. If pricing treatment for a new setting is unclear, keep it as an unresolved purchasing question. Obtain clarification before presenting a customer price derived from an assumed saving.

For your internal decision, use two views. Cost per attempt reveals the work consumed whether or not it helped. Cost per accepted completion divides the total cost of the evaluated attempts by the completions that met your written standard. Keep the period, cohort and included cost categories identical. If no attempt qualifies, report no accepted completion rather than a misleading average.

Include both stages of a retry or escalation, relevant ongoing storage, and the human effort needed to correct answers or maintain source applicability. Separate one-time setup from recurring operation. A pilot's invoice may not resemble a busy month's traffic, and a lower service bill can coexist with more customer-support work.

The GOV.UK performance-data guide pairs cost with completion and satisfaction rather than treating any one measure as sufficient. Apply that logic here: approve extra work when the task improves enough to justify the additional waiting and expenditure. A route that saves money by leaving more people stranded is a product tradeoff to examine, not an automatic optimization.

9. Preserve access and trust when the answer format changes

Source-only results still expose information. Removing the answer generator does not remove the need to verify what a user may retrieve. Likewise, additional retrieval must not broaden the user's permitted collection merely because a second knowledge base could contain a useful exception.

The AgenticRetrieveStream reference describes userContext for access-control filtering and a streamed response containing results and generated-response fields. The builder should demonstrate how the application passes the correct identity and interprets the actual response, rather than assuming an older result renderer remains compatible.

AWS's knowledge-base overview also distinguishes managed and customer-managed capabilities, including differences in document-level permission support. These product descriptions are not a guarantee that your imported collection, connector and identity mapping are configured correctly.

Test with an allowed user, a user lacking access and a user whose access has changed. Inspect excerpts, citations, cached answers and review exports, not only the final chat bubble. OWASP's authorization guidance supports least privilege, denial by default and permission checks on each request. The application-level implication is to verify access along every route and fallback.

Finally, make status language match the product's knowledge. “Relevant sources found” is different from “Your answer is verified.” If a comparison is incomplete, show the missing point. A source preview should identify itself as an excerpt rather than appear to be a newly approved instruction. Changing the amount of generated text must not quietly change the authority customers attribute to the output.

10. Release only the task classes that earned their route

Start with a narrow audience and a reversible route change. Keep the existing tested experience available, record which path actually served each attempt, and name the person who can disable the new behavior. Expand after reviewing failures and customer understanding, not merely after a successful launch-day demonstration.

Stop a task class if it exposes unauthorized content, presents an unsupported exception as settled, loses the source handoff, or repeatedly exhausts its agreed waiting or spending limit. Define these conditions before release. Confirm how cancellation affects work already running; do not assume closing a chat stops billable processing. If a spending ceiling cannot be enforced precisely, label it an alert threshold and choose a conservative release scope. A global average can hide one small group receiving consistently worse answers.

This approach fits teams with a maintained collection, bounded customer questions and someone able to judge the answers. It is a poor starting point for an unowned document dump, a product that cannot establish access boundaries, or questions requiring professional judgment that the documents cannot supply. Fix the collection or the service promise before increasing retrieval effort.

Existing Bedrock users have a concrete feature to investigate, subject to the environment check. Teams using another provider can adopt the same question-budget worksheet without migrating. Teams with a small, clear help center should also compare against ordinary search and direct links before adding a conversation layer.

For today's planning meeting, choose one task class, name the useful result and fill the worksheet. Ask the builder to return an availability receipt and comparable saved attempts. Decide which route that task has earned only after reviewing the evidence. That yields a specific product decision from the announcement while keeping vendor claims, your test plan and your actual results distinct.

References

Sources checked November 10, 2026. AWS pages describe the service; they are not independent performance validation. The papers provide historical concepts and evaluation methods. All scenarios and the worksheet above are proposed by YBuild.