Eager retrieval fires once with a single query derived from the user's turn, usually a paraphrase. For multi-hop questions ('which papers cited the same theorem as paper X?') one query cannot retrieve everything needed. The agent has to chain queries: retrieve, read, formulate the next query, retrieve again. Lazy retrieval via a search tool lets the model do that chaining inside its reasoning loop. The cost is one extra tool round-trip per retrieval; the benefit is context that grows on demand with what the question actually needs, rather than being guessed at turn start. This is the pattern OpenAI's Deep Research, Claude's research mode, and most coding-agent systems use.
Eager retrieval is the classic RAG pattern. At the start of the turn, the system takes the user's question, runs one retrieval, and stuffs the top-k chunks into the context block before the model sees anything. The model never gets to choose what to look up.
This works fine when the question can be answered from a single retrieval. The user asks a factual question, the retriever finds the right chunk, the model reads it and answers.
It breaks on multi-hop questions where one query is not enough. 'Which papers cited the same theorem as paper X?' requires first finding paper X, then identifying the theorem, then searching for other papers that cited that theorem. A single retrieval at turn start cannot do this, it does not yet know what the theorem is.
Lazy retrieval reshapes the problem. Instead of running retrieval before the model thinks, the system exposes search as a tool the model can call during reasoning. The model reads the question, calls search with one query, reads the results, formulates the next query based on what it just learned, and calls search again. Each call is a round trip but the context only grows with what the question actually needs.
The trend in 2026 is for any agentic or research-style product to use lazy retrieval. OpenAI's Deep Research, Anthropic's research mode for Claude, Perplexity Pro, and most code agents like Cursor and Windsurf all retrieve iteratively inside the reasoning loop.
Eager retrieval guesses the answer at turn start; lazy retrieval discovers it during reasoning. The shift in 2026 is about which model that better fits the question shape.
The eager pattern fires retrieval once before the model sees anything. The query is derived from the user's turn, often a paraphrase or a query-rewrite call, and the resulting top-k goes into the context block as a pre-assembled evidence section. It works for single-hop questions because one targeted query is enough to fetch the answer.
The pattern breaks for **multi-hop questions** where the second query depends on the result of the first. 'Which papers cited the same theorem as paper X?' is the canonical example. The system cannot formulate the second query ('papers citing theorem T') without first knowing what T is, which means it cannot be answered at turn start. Eager retrieval responds by paraphrasing the user's question and hoping the right chunks are in the top-k. They usually are not.
Lazy retrieval exposes search as a tool the model calls during its reasoning loop. The model reads the question, issues a query, inspects results, formulates a follow-up query, and continues until it has enough to answer. The context grows only with what the model actually needed.
The tradeoff is **round trips and tokens**. Each search tool call is one inference round trip and one tool-response payload in context. For a single-hop question this is pure overhead, eager would have been cheaper and faster. For a multi-hop research question it is the only way the system can succeed.
The 2026 production pattern is hybrid: a fast eager pass for cheap recall, plus the search tool exposed for the model to refine. OpenAI Deep Research, Claude's research mode, Perplexity Pro, and coding agents (Cursor, Windsurf, Cline) all follow this shape.
Quick reference
TL;DR
Eager retrieval fires one query at turn start and guesses what the question needs; lazy retrieval lets the model issue queries during reasoning so context grows on demand, which is what multi-hop questions actually
Imagine asking a research assistant to answer a complicated question. The eager approach is to hand them one folder of articles at the start and say go. The lazy approach is to let them walk to the library, grab a book, read it, decide what to look up next, and walk back for more. For a simple fact-lookup the folder is fine. For a question like which papers cited the same theorem as this one, the assistant needs to walk back to the library several times because each visit tells them what to look for next. Lazy retrieval lets the model do that walking. The cost is a few extra trips; the benefit is finding things one trip could never have found.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.
Single-hop factoid questions with tight latency budgets Eager retrieval is cheaper and faster; lazy adds round trips for no benefit on questions one retrieval can answer.
Workloads with strict cost ceilings per query Each lazy search call is one extra inference; multi-call loops can balloon cost unpredictably without per-call caps.
Sub-second response requirements (autocomplete, live chat) Tool round trips add hundreds of milliseconds per call; lazy retrieval cannot fit the SLO.
Quick scan · 2–4 min
Everything important, quickly.
4 minutes: define eager vs lazy retrieval, name the multi-hop problem that breaks eager, walk through the search as tool loop, describe the hybrid 2026 default, mention max-iterations as a safety cap.
Code example
python
search_tool = {
"name": "search_kb",
"description": "Search the knowledge base. Returns top-5 chunks with [S<n>] tags.",
"input_schema": {
"type": "object",
"properties": {"query": {"type": "string"}},
"required": ["query"],
},
}
# Lazy retrieval loop (Anthropic SDK shape)
def run_lazy(user_question: str, max_iterations: int = 8):
messages = [{"role": "user", "content": user_question}]
for _ in range(max_iterations):
resp = client.messages.create(
model="claude-opus-4-7",
tools=[search_tool],
messages=messages,
)
if resp.stop_reason != "tool_use":
return resp.content # final answer
for block in resp.content:
if block.type == "tool_use":
result = kb.search(block.input["query"])
messages.append({"role": "assistant", "content": resp.content})
messages.append({"role": "user", "content": [
{"type": "tool_result", "tool_use_id": block.id, "content": result}
]})
Real-world examples
Real products, models, and research that use this idea.
1OpenAI's Deep Research (released 2025, default in ChatGPT Pro 2026) runs an iterative search and read loop with the model calling web search as a tool, sometimes for dozens of rounds.
2Anthropic's Claude 4.7 research mode and Projects feature expose file_search and web_search as tools the model invokes during reasoning.
3Perplexity Pro 2026 follows up the first retrieval with model-driven follow-on searches when the model judges the initial result set incomplete.
4Coding agents (Cursor, Windsurf, Cline, Anthropic Claude Code) treat code search, file read, and grep as canonical lazy-retrieval tools with no eager pass.
5Google Gemini Deep Research uses the same iterative search tool pattern with Gemini 3.1 Pro driving the loop.
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QHow do you bound the cost of lazy retrieval in production?
Sign in or go Pro to see the approach for this follow-up.
QWhat is the failure mode where the agent loops without converging?
Sign in or go Pro to see the approach for this follow-up.
QWhere does the hybrid (eager + lazy) pattern make the most sense?
Sign in or go Pro to see the approach for this follow-up.
Don't say this
Red flags and common mistakes that signal junior thinking. Click to expand.
Most common mistake
Treating eager and lazy retrieval as either-or rather than per-workload. Single-hop fact lookups want eager; multi-hop research wants lazy. Many production systems do both.