Amazon Bedrock Managed Knowledge Base has introduced a broader maxAgentIteration range (0‑5) and two additional request styles—single‑shot Retrieval‑Augmented Generation (RAG) and retrieval‑only—available through the AgenticRetrieveStream API. The change lets teams pick the exact amount of model work per request, aligning performance and cost with the difficulty of the question.
What Changed in Bedrock Retrieval Modes
The service now supports three distinct modes controlled by maxAgentIteration:
- Retrieval‑only (value 0): Returns matching passages without invoking a foundation model.
- Single‑shot RAG (value 1): Performs one retrieval pass and generates an answer in a single model call.
- Agentic retrieval (values 2‑5): Allows the model to decompose the query, run multiple searches, evaluate evidence, and optionally refine the search before generating the final answer.
All three modes can target multiple knowledge bases, and the initial speculative retrieval does not count against the iteration limit.
When to Use Each Mode
Simple look‑ups—such as fetching a checklist or a single policy excerpt—benefit from the retrieval‑only or single‑shot RAG paths because they avoid the planning overhead of agentic loops. Complex, multi‑part questions—like comparing requirements across several entity types—are better served by agentic retrieval, which can break the problem into sub‑queries and gather evidence iteratively.
Choosing a mode is a matter of balancing latency, model usage, and answer completeness. Retrieval‑only incurs no model cost, single‑shot RAG adds a single generation call, and agentic retrieval adds one generation call plus up to maxAgentIteration‑1 planning rounds.
Architectural and Operational Implications
Because the same AgenticRetrieveStream endpoint now handles all three patterns, applications no longer need separate code paths or additional services for simple versus complex queries. Engineers can expose a single request interface and set maxAgentIteration per request based on context or user intent.
Iteration counting is explicit: each planning round consumes one foundation model call, and the final answer generation consumes the last call. Monitoring should therefore track the number of iterations per request to correlate latency and cost with the chosen mode. Trace events still provide visibility into planning steps and citation generation, aiding debugging and compliance audits.
Operationally, the expanded iteration range (0‑5) gives more granularity for performance tuning. Teams can experiment with values 2‑3 for moderately complex queries and reserve the higher end for edge cases that demand deeper evidence gathering.
Security and Governance Considerations
All retrieval activity continues to respect the underlying knowledge‑base permissions; the mode change does not alter access control semantics. However, because retrieval‑only responses expose raw passages, applications must ensure that downstream consumers are authorized to view the source text. The reduced need for custom orchestration also shrinks the attack surface associated with bespoke retrieval loops.
Related CloudNinjas coverage: AWS.
What This Means For Practitioners
- Adopt
maxAgentIterationas a per‑request knob to align latency and cost with query complexity. - Use retrieval‑only for audit‑style displays of source material; avoid unnecessary model calls.
- Leverage single‑shot RAG for fast, single‑pass answers where a single retrieval suffices.
- Reserve agentic retrieval for multi‑part or evidence‑heavy questions that benefit from iterative planning.
- Instrument iteration counts and trace events to monitor performance, cost, and evidence quality across modes.
