Insight · September 4, 2026
Retrieval that
checks itself.
Classic RAG retrieves once and hopes. Agentic RAG puts a reasoning loop over retrieval, so it keeps searching until the evidence holds.
01 · The shift
Retrieval stopped being one step.
Retrieval augmented generation has a clean origin. Patrick Lewis and eleven co authors introduced it in 2020, in a paper called Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. The idea was simple and it held for years. Give a model a search step so it can pull facts from your documents instead of guessing from memory.
The shape of that step was always the same. Embed the question, run one search, paste the top passages into the prompt, generate an answer. One retrieval, one answer. It works, and for a large share of questions it is still all you need. But a single pass has no way to notice when it missed, and that is the gap agentic RAG was built to close.
02 · The problem
One search cannot answer a layered question.
Classic RAG retrieves once, responds once, and leaves no room to adapt. Ask it something that lives in one paragraph of one document and it does well. Ask it something that spans three documents, or needs a fact looked up before the real question can even be framed, and the single pass falls short. It grabbed the wrong chunks, or half the chunks, and the model writes a confident answer on top of thin evidence.
The model cannot fix this on its own, because it never sees that the retrieval was weak. It gets whatever came back and treats it as the truth. There is no second look, no rephrase, no decision to search somewhere else. The pipeline moved on. That missing judgment, sitting between the search and the answer, is the whole reason agentic RAG exists.
The one line to keep
“Classic RAG is a pipeline. Agentic RAG is a control loop.”
03 · What agentic RAG actually is
An agent over retrieval, running four patterns.
The 2025 survey by Aditi Singh and colleagues names agentic RAG as autonomous agents placed inside the retrieval pipeline, and sorts what those agents do into four design patterns. The same four turn up in almost every working system.
01
Reflection
The agent reads what it retrieved and asks whether it actually answers the question. Thin or off topic results get thrown out before they reach the model.
02
Planning
A hard question gets broken into sub questions the agent can answer one at a time, then reassembled. One search becomes a sequence.
03
Tool use
Retrieval is one tool among several. The agent can call a database, a live API, or a second index, and pick the right source for each step.
04
Multi agent
For large jobs the work splits across agents, one to retrieve, one to check, one to write, coordinated toward a single grounded answer.
04 · Not a bigger index
More chunks is not the same as more judgment.
The common first fix for weak retrieval is to feed the model more. A bigger vector store, more chunks per query, a longer context window. It helps a little and then it stops helping, because the problem was never how much you retrieved. It was that nothing decided whether the retrieval was any good.
Agentic RAG adds the decision, not the volume. The agent receives the question, forms a plan, runs a retrieval, reads the result, and then chooses. Good enough, so answer. Too thin, so search again with a better query. Wrong source, so switch tools. This is the same reasoning loop that defines an AI agent, pointed at retrieval. The loop is the product. The index is just where it looks.
05 · One question that shows the difference
A question no single search can reach.
Take a support question. Which of our plans covers the feature this customer is asking about, and is that customer on it. A single retrieval cannot answer this, because it is really two questions stacked on a third. What plan is the customer on. What features does that plan include. Does the asked for feature appear in that list.
Classic RAG embeds the whole sentence, pulls the chunks that look closest, and hopes the answer is somewhere in them. It usually is not. Agentic RAG plans instead. It looks up the account, reads the plan, retrieves that plan's feature list, checks the feature against it, and only then answers. If a step comes back empty, it retries that step rather than failing the whole question.
plan break the question into steps step look up the account · which plan step retrieve that plan's feature list step is the asked feature in the list check every step returned real evidence retry any step that came back empty answer only once the chain is grounded
A retrieval loop · answers only when the chain holds
06 · When it pays off
The loop earns its cost on questions that branch.
Reach for agentic RAG when the question spans sources, needs a fact before the real question can be asked, or has to be right often enough that a wrong retrieval is expensive. Research across a document set, a support agent that reads live account state, a compliance check that has to cite the exact clause. In each one the value is not a smarter answer. It is an answer the system stood behind because it checked its own evidence first.
This is why retrieval increasingly sits inside context engineering rather than beside it. The job is no longer stuffing a prompt with the right passages. It is managing what the model knows across a run, deciding what to fetch, when to fetch it, and whether to trust what came back. Agentic RAG is that decision made a working part of the system.
07 · When not to reach for it
A loop is complex, and complexity has a price.
Agentic RAG is harder to build and harder to run. Every extra pass is another model call, so a question that once cost one retrieval now costs several. The answers arrive slower, because the loop is thinking between searches. And the added moving parts can still lose the thread on a long enough chain. None of this is a reason to avoid it. It is a reason to spend it where it counts.
A single fact from a single document does not need a loop. A straight lookup with a clear answer does not need a loop. If classic RAG already answers the question well, the agent adds cost and latency for nothing. The skill is not building the most agentic system you can. It is knowing which questions deserve the loop and letting the rest stay a plain search.
Closing
Retrieval that checks itself.
Find the question your search keeps getting wrong, the layered one that lives across three places at once. Give it a loop that can look again. The first time it answers a question a single pass never could, you will stop treating retrieval as one step.
Written by · September 4, 2026
Donny Smith · ECD, Founder, Bttr.
Over the past 15 years, he has led creative teams and contributed to products used by millions of people worldwide, working with companies including Apple, Opendoor, JP Morgan, GE Aerospace, Pepsi, and Alterra Mountain Company.
LinkedInLewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, NeurIPS 2020 · Singh, Ehtesham, Kumar, Talaei Khoei, Agentic Retrieval-Augmented Generation, A Survey on Agentic RAG, arXiv 2501.09136, 2025
Share this perspective
More insights
Adjacent perspectives.
Bttr. Field Brief
The brief Bttr. writes for senior buyers.
Monthly. One signal worth your time on Brand Operating Systems, AI search visibility, and the infrastructure buildout. No filler.