Agentic RAG
A retrieval pattern where the agent decides when and what to retrieve — issuing its own search queries, refining them, and iterating — instead of a single up-front retrieval step.
Naive RAG retrieves once: take the user query, embed it, fetch the top-K chunks, prepend to the prompt. Agentic RAG retrieves iteratively: the agent reads the question, decides what to search, evaluates results, and issues follow-up queries until it has enough context to answer.
The pattern excels on multi-hop questions where the right answer requires combining facts across documents, on ambiguous queries where the first retrieval misses the intent, and on long-running research where the agent needs to follow leads. Manus, Perplexity Labs, and OpenAI Deep Research are all agentic-RAG-driven internally.
The cost is real: 3–10× more tokens than naive RAG for the same query, plus higher latency. The wins are reliability and depth on hard questions. For production stacks in 2026, the recipe is: naive RAG by default, agentic RAG when the query needs it (detected via classifier or user signal).
Where this shows up
Frequently asked
When does agentic RAG beat naive RAG?+
On multi-hop questions, ambiguous queries, and research tasks where the first retrieval misses the intent. For simple lookups on well-indexed corpora, naive RAG is cheaper and equally accurate.
How expensive is agentic RAG compared to naive RAG?+
Typically 3–10× more tokens and 2–5× more latency. Worth it on hard questions; wasteful on routine ones. Production stacks usually route per-query: naive by default, agentic when the query justifies it.