Agentic search: definition and how it works

A classic search engine, or a classic RAG, works in a single pass: one query, the top results, one answer. If the right information isn't in those results, the answer can't contain it.

Agentic search replaces that single pass with a loop. The language model has search and reading tools, and decides on its own when to use them: rephrase the question, look for an exact term, open a document, read a full page, look at the context around a passage. It stops when it can answer with evidence, or when it can state that the information doesn't exist.

So it isn't a new retrieval method next to keyword or semantic search: it's a layer on top that uses them. Model and search vendors (Mistral, Amazon OpenSearch) use the term for this same idea.

Not to be confused with “agentic search” in marketing, which refers to AI agents (ChatGPT, Perplexity…) that research and compare brands on the web on a user's behalf. Here, it means searching your own documents.

On documents, an agentic search runs a loop like this for every question:

1. Target: identify the document(s) the question refers to (a company, a year, a contract).
2. Search: a first hybrid search, by keywords (exact terms, figures, acronyms) and by meaning (vector search), then reranking of the passages.
3. Assess: the agent reads the passages and judges whether they hold the evidence or only a hint.
4. Dig: if something is missing, it searches again in its own words, looks for an exact term across the whole document, or reads the full page where a table was cut.
5. Answer and cite: every claim links to the page it comes from. A figure that appears in no cited source has no place in the answer.

In Agentic Search, the starting passages are never replaced: tools can only add context. The agent always starts from at least a classic RAG, and can only do better.

What makes a search “agentic” is the tools the agent can call. Ours:

• search: search again with different wording (“litigation” when the question says “legal battles”).
• grep: look for an exact term in a document, find which page it's on, or prove it isn't there.
• read_page: read a full page, table headers included, when the excerpt isn't enough.
• open_doc and navigate: open a document and move around a passage, to read what comes before and after it.
• calculate: run calculations (ratios, changes) in code rather than “in its head”, each input tied to the passage it cites.

grep plays a special role: semantic search finds what looks like the question, grep finds what is literally there. It's also what lets the agent say “this figure isn't in the report” with certainty, rather than guess.

A classic RAG gets the ten best passages and answers in one pass. Its failures are predictable: a table split across two passages stays unreadable, a note on page 87 is never read if retrieval missed it, and without evidence the model refuses or guesses. In our tests, the page holding the evidence is in the top twenty results for only about 70% of questions: retrieval alone isn't enough.

We measured the gap on FinanceBench, a benchmark of analyst questions on SEC financial reports: 84 reports, 12,000 pages indexed together. Same starting retrieval, same model; the only difference is access to the tools.