Ask a naive RAG system a question like “Which of our regions missed their SLA last quarter, and what caused it?” and watch it faceplant. It embeds the whole sentence, pulls the top eight chunks that look vaguely similar, stuffs them into a prompt, and hopes the model can reason its way out. But the answer lives in two different documents — one listing SLA breaches, another explaining root causes — and neither is close enough to the query vector to rank in the top eight. The model gets half the context, confidently fabricates the rest, and you ship a wrong answer with a citation attached.
This is the structural limit of one-shot retrieval. Agentic RAG fixes it not by tuning the embedding model or cranking up k, but by giving retrieval something it never had: the ability to decide. That decision-making capacity is the spine.
The limits of one-shot RAG
Classic RAG is a straight pipeline. Embed the query, run a nearest-neighbor search, take the top k chunks, concatenate, generate. It works beautifully for questions that map cleanly to a single passage — “What is the default timeout for a Lambda function?” — and falls apart everywhere else.
The failure modes are predictable once you see the pattern:
- Compositional questions. Answers that require joining facts across documents. Top-k similarity has no notion of “I need one fact from here and another from there.”
- Vague or underspecified queries. “How do we handle failures?” retrieves everything and resolves nothing. The query needs sharpening before it can retrieve anything useful.
- Multi-hop reasoning. “Who approved the change that caused the outage?” requires finding the outage, then the change, then the approver — three sequential lookups, each depending on the last.
- No self-awareness. One-shot RAG cannot tell whether what it retrieved is any good. It retrieves once and commits, whether the chunks are relevant or garbage.
You can paper over some of this with hybrid search, reranking, and bigger context windows. Those help. But they are all still one shot. The system fetches, then generates, and never asks itself whether it fetched the right thing.
What “agentic” actually adds
Agentic RAG wraps retrieval in a control loop. Instead of a fixed fetch-then-generate sequence, the model reasons about the task and treats retrieval as a tool it can invoke — repeatedly, conditionally, and with different arguments each time.
The loop looks roughly like this:
while not satisfied and steps < budget:
plan = model.decide_next_action(question, evidence_so_far)
if plan.action == "retrieve":
results = knowledge_base.retrieve(plan.query)
evidence += model.filter_relevant(results)
elif plan.action == "answer":
break
answer = model.generate(question, evidence)
Four decisions live inside that loop that one-shot RAG never makes: whether to retrieve at all (some questions do not need it), what to retrieve (the model writes the search query, not the user), how many times to retrieve, and when the accumulated evidence is good enough to stop. Retrieval stops being a passive lookup and becomes an active, self-directed component. That is what “growing a spine” means — the system now holds itself upright and makes calls instead of flopping through a fixed pipeline.
Core patterns
Three patterns do most of the heavy lifting in production agentic RAG.
Query reformulation. The user’s phrasing is rarely the best search query. An agentic system rewrites it — expanding acronyms, splitting a compound question into parts, or generating several candidate queries and merging the results. When a retrieval comes back weak, it reformulates and tries again rather than committing to bad context.
Multi-hop retrieval. For questions that require chaining, the agent retrieves, reads, and uses what it learned to form the next query. Answering “what caused the SLA miss” becomes: retrieve the breach record, extract the incident ID, retrieve the incident report, extract the root cause. Each hop is a fresh, better-targeted search.
Self-critique and grounding checks. This is the idea behind research like Self-RAG and Corrective RAG (CRAG). The model grades its own retrievals for relevance and grades its draft answer for grounding — is every claim actually supported by a retrieved passage? If a claim is unsupported, it retrieves again or drops the claim. This is the single biggest lever against hallucination, because the system refuses to assert what it cannot cite.
Production realities
A control loop that can retrieve N times is a control loop that can retrieve N times when N gets ugly. The engineering discipline matters more than the pattern.
Latency compounds. Each hop is a full round trip: an LLM call to plan, a vector search, another LLM call to evaluate. A three-hop answer can mean six or seven sequential model invocations. Where hops are independent, fan them out in parallel. Where they are sequential, use a smaller, faster model for the planning and grading steps and reserve the large model for the final synthesis.
Token cost accumulates. Every hop re-sends accumulated evidence into the context window. Naively, a five-hop conversation can burn several times the tokens of one-shot RAG. Summarize intermediate evidence instead of carrying raw chunks forward, and cap how much context each hop contributes.
Guard the loop. Never ship an unbounded while. Enforce a hard ceiling on iterations, a token budget for the whole request, and a wall clock timeout. Track a confidence or novelty signal — if two consecutive hops add nothing new, stop. A runaway agent that retrieves forty times is worse than a wrong answer, because it is a wrong answer that also costs forty dollars.
Evaluate retrieval separately from generation. Measure retrieval quality (recall, precision, whether the right passages showed up) independently from answer quality (faithfulness, correctness). A good final answer built on lucky guesses is a landmine. Build a labeled question set and track both metrics as you tune. Frameworks like Ragas exist precisely for this split.
Building it on AWS
You do not have to hand-roll the whole loop. AWS gives you the pieces at two levels of abstraction.
The managed retrieval layer. Amazon Bedrock Knowledge Bases handles ingestion, chunking, embedding, and vector storage, and exposes a Retrieve API for raw passages and a RetrieveAndGenerate API for one-shot answers. In an agentic design you lean on Retrieve as the tool your loop calls — the agent owns the reasoning, the Knowledge Base owns the fetch.
The managed orchestration layer. Agents for Amazon Bedrock runs the reason-act loop for you. You attach a Knowledge Base and define action groups, and the agent plans, decides when to query, invokes tools, and iterates — emitting a reasoning trace so you can see why it retrieved what it did. That trace is not a nicety; it is how you debug and audit a multi-hop answer.
The build-versus-buy line is straightforward. If your loop is standard retrieve-reason-retrieve, let Agents orchestrate it and save yourself the state machine. When you need custom stopping logic, parallel fan-out, or tight control over every model call, drop to the Retrieve API and orchestrate yourself — with Step Functions for durable multi-step flows or a framework like LangGraph running on Lambda or ECS for tighter loops.
Closing take
Agentic RAG is not a wholesale replacement for classic RAG — it is classic RAG that finally learned to think about what it is doing. And it is not free. Every hop costs latency, tokens, and complexity, so reach for it when your questions genuinely demand it: compositional queries, multi-hop reasoning, high-stakes answers that must be grounded and defensible.
For a lookup that maps to a single passage, one-shot RAG is faster, cheaper, and completely adequate. Do not grow a spine where a reflex will do. But the moment your users start asking real questions — the kind that span documents and require the system to reason about its own uncertainty — passive retrieval breaks, and the loop is what holds the answer up.