Iterative Query Planning in Research Agents

Iterative query planning is the practice of dynamically generating, refining, and decomposing queries across multiple retrieval steps rather than issuing one fixed query and consuming whatever comes back. Some of the literature frames this as "question developing," which captures something the term "query planning" misses: it is an active, evolving process, not a static lookup.

The structural difference from standard RAG is precise. Standard RAG is a one-pass pipeline: query, retrieve, generate. Iterative planning is a loop: query, retrieve, evaluate, replan, retrieve again, synthesize. The loop continues until some termination condition is satisfied.

What that loop introduces, which RAG lacks entirely, is threefold. First, task decomposition: a complex question contains latent sub-questions that single-shot RAG never surfaces, because the user's natural-language query is issued directly and the retrieval system does what it can. Second, intermediate evaluation: after retrieval, the agent asks whether what came back is relevant, sufficient, or contradictory, and whether it opened new sub-questions the original decomposition missed. This is the step RAG has no equivalent for. RAG skips evaluation; it delivers. Third, query adaptation: based on what prior retrievals revealed or failed to reveal, the agent reformulates its next query. The plan is mutable. Evidence changes it.

This is what turns a retrieval system into a reasoning system. The agent isn't just fetching; it's deciding what to fetch next and why. That logic holds whether you're building a single tool-calling LLM in a loop or a multi-agent architecture with a lead researcher spawning subagents. The pattern scales; the underlying structure is the same.

Two earlier planning patterns that still fail and why

Before the current generation of iterative agents, two planning patterns were formally characterized and widely implemented. Both improve on naive single-shot RAG. Neither is sufficient, and recognizing why requires understanding what they share, not just where they differ.

The first is outline-guided search. The agent uses the LLM's internal knowledge to generate a structural outline of the answer first, then retrieves documents to fill in the gaps. The problem is that the outline is bounded by what the model already knows. Retrieval becomes confirmatory rather than exploratory; it is gap-filling for a structure the model has already decided on. When the model's training data is outdated or sparse on the topic, the outline is built on an inaccurate prior, and retrieval is directed by that inaccuracy.

The second is search-then-outlining. Broad initial searches come first; the agent builds an outline from those results, then retrieves within that structure. This inverts the ordering but preserves the core problem. The outline is fixed after the first retrieval pass. Evidence the first search missed stays missed. Early retrieval errors become permanent structural constraints.

What both patterns share, despite their different orderings, is a one-way workflow. Evidence informs the plan once, and the plan never reforms in response to what retrieval subsequently reveals. There is no feedback loop.

This failure is architectural, not incidental. Better prompting doesn't rescue a one-way pipeline from the cases where the first pass is wrong or incomplete. A stronger model generates a more convincing wrong outline, and produces more fluent hallucinations when it retrieves on top of it. I've watched this play out in production systems that were described to me as "agentic" because they called a search tool before generating: structurally, they were still outline-guided under the hood. Recognizing the failure mode requires knowing what to look for in your own system, which is harder than it sounds when the outputs are fluent.

The core loop: how an iterative planning agent generates, evaluates, and reformulates queries

The loop has five functional stages, and each stage's fidelity determines whether the overall system works. None of them is as simple as it looks from the outside.

The first stage is initial decomposition. The agent receives the task, identifies the sub-questions it implies, and generates an initial set of targeted queries rather than one broad one, which is the functional definition of multi-hop reasoning applied at the retrieval layer. The quality of this decomposition shapes everything downstream; a badly decomposed task produces misdirected retrieval from the first step, and the agent may loop many times before discovering it asked the wrong sub-questions to begin with.

Retrieval follows: queries go to search or retrieval tools, and evidence chunks or documents come back. This stage is mechanical, but its outputs depend entirely on retrieval infrastructure quality, which I'll address separately.

Evidence evaluation is where iterative planning earns its value. The agent assesses whether the returned content is relevant and sufficient, whether it surfaces new sub-questions the initial decomposition missed, and whether there are contradictions between sources requiring resolution, applying something closer to chain-of-thought reasoning than retrieval indexing. Without structured evaluation, the agent has no principled basis for deciding what to do next. It's guessing, which is what single-shot RAG was already doing.

Replanning follows evaluation. The agent decides whether the evidence is sufficient to proceed to synthesis or whether it needs to reformulate and retrieve again. Reformulation comes in recognizable variants: narrowing adds constraints from prior results to focus the next query; expansion broadens when initial results were too thin; pivoting switches to a different framing when results proved irrelevant; follow-on generates a new sub-question that prior retrieval revealed as necessary. In practice, agents cycle through these variants in ways that can be hard to instrument cleanly.

Synthesis closes the loop. Once termination conditions are met, the agent compiles and reconciles evidence into a final answer. Synthesis is not trivial when evidence arrives across multiple retrieval steps from different sources, some of which contradict each other.

The stopping condition is often the most underspecified piece. An agent needs explicit criteria for when the loop ends: a step count ceiling, a cost threshold, a confidence signal, or a task-completion criterion. Without a well-designed stopping condition, agents either terminate too early on complex tasks or run indefinitely on tasks with no clear completion state. In production, runaway loops are expensive; early termination produces the same confabulation problem iterative planning was meant to solve. Anthropic's engineering work on multi-agent research describes a LeadResearcher architecture in which the lead agent spawns subagents functioning as intelligent filters, each iteratively using search tools and returning results upward for synthesis. The loop is distributed across agents, but the structural logic is identical to the single-agent case. (Anthropic Engineering, 2025.)

How RL-trained agents internalize query planning without explicit rules

There is a parallel line of development in which agents are not given explicit loop structures. Instead, they are trained via reinforcement learning on final-answer quality, and they discover iterative query planning as a consequence.

The training signal is what matters here. These systems are rewarded for producing correct final answers, not for taking any particular retrieval step, unlike supervised RAG pipelines where the retrieval call itself is part of the fixed procedure. What the agent learns, implicitly, is that decomposing the task and refining queries leads to better answers. Query planning emerges as a learned strategy rather than an engineered rule, and there is something genuinely interesting about that: the same loop structure that practitioners engineer explicitly gets rediscovered by optimization pressure alone.

Several notable 2025 systems operate in this paradigm: ReSearch, R1-Searcher, Search-R1, WebRL, WebThinker, WebAgent-RL, DeepResearcher, and EvolveSearch are all training agents to plan retrieval as a consequence of answer-quality feedback. The advantage of the approach is adaptability. The agent calibrates its planning behavior to the distribution of tasks it encounters rather than following a fixed procedural script.

The benchmark results temper any enthusiasm considerably. AutoResearchBench, built over three million arXiv papers with controlled full-text extraction, reports top-system accuracy of 9.39% on Deep Research tasks and 9.31% intersection over union on Wide Research tasks as of April 2026. These are the strongest systems evaluated under rigorous conditions. Complex, multi-hop research tasks remain far from solved.

For most engineering teams, the practical implication is direct: RL-trained query planning is a research frontier, not a deployment option. Most implementations will use iterative planning explicitly through tool-calling and prompting. What both approaches consistently demonstrate is that for complex problems, task decomposition improves accuracy and interpretability. Whether the decomposition emerges from engineering or learning is, in that sense, a secondary question.

Query planning across multi-agent architectures: decomposition by delegation

In multi-agent configurations, iterative query planning distributes across a hierarchy, a pattern the industry has settled on calling agentic RAG when the planning logic is explicit rather than learned. A lead agent decomposes the task and delegates sub-questions to specialized subagents; each subagent runs its own retrieval loop; results return up the hierarchy for synthesis. The planning logic is preserved at every level, applied at different scopes.

The structural advantages are real. Sub-questions can be pursued in parallel rather than sequentially, compressing total wall-clock time on complex tasks. Subagents can be configured for specific retrieval contexts: one for live web search, another for structured financial data, another for internal document stores. The lead agent maintains the research plan while subagents handle execution details, which separates scope management from retrieval execution.

Multi-agent architectures also introduce coordination failures that single-agent loops don't face. Subagent results may contradict each other, requiring a reconciliation step that adds complexity to synthesis. Redundant searches across subagents waste retrieval budget and inflate token cost; without coordination, two subagents may independently retrieve the same evidence. If subagent outputs are unstructured, the lead agent faces a parsing and normalization problem layered on top of its planning and synthesis responsibilities. These are not theoretical failure modes. They show up in practice, often in ways that are difficult to attribute cleanly.

Research published in JMIR in March 2026 notes that current deep research agents have shifted from text-only, single-model bots to multimodal, tool-integrated, multi-model systems. The architecture has grown more complex as the problems it is expected to handle have become more complex. What remains constant is the planning question at every level of the hierarchy: what do I need to know next, and how do I retrieve it?

What the retrieval layer must provide for iterative planning to work

Iterative planning multiplies retrieval calls. A single user question fans out into many search calls as the agent loops and replans. At AI-agent startups, search costs constitute a significant share of monthly variable cost of goods sold, making retrieval infrastructure a first-order economic concern, not just a technical one.

Freshness is the first requirement, and it's more consequential in a planning loop than it appears. Each retrieval call must return current information. Stale results that look correct are particularly dangerous in an iterative loop because the agent treats retrieved content as ground truth when planning its next query. A plausible but outdated document doesn't just produce a wrong answer; it directs subsequent retrieval steps in the wrong direction. The knowledge-cutoff problem in LLMs is well-documented, but a stale retrieval index compounds it: the compensation that fresh retrieval provides for static training fails entirely if the index is itself out of date.

The second requirement is LLM-optimized output. Raw HTML returned from a web crawl contains navigation menus, cookie banners, advertisement scripts, and boilerplate that has nothing to do with the query. A meaningful fraction of apparent model hallucinations in retrieval-grounded pipelines are not the model confabulating from nothing; they are the model faithfully summarizing noise. Clean, structured, citation-attributed output from the retrieval layer is not a cosmetic preference. It materially affects grounding quality and what the model does with the content it receives.

Low latency at scale is the third. Multi-step retrieval loops with high per-call latency compound quickly. A retrieval call that takes several seconds, repeated across a dozen planning steps, produces wall-clock times that are unusable in interactive contexts and expensive in batch contexts. Prompting cannot solve this problem.

There is also a structural challenge in the open-web retrieval landscape that practitioners cannot directly control. As of July 2025, Cloudflare began blocking AI crawlers by default across a substantial fraction of the web. Agents relying on open-web crawling face access constraints that search API providers must absorb on their behalf. This makes the choice of retrieval infrastructure provider consequential in ways that extend beyond latency and cost.

Citation traceability across planning loops also deserves attention. When an agent reconciles evidence across multiple retrieval steps, every claim needs a traceable source. An unattributed result from one retrieval step cannot be reconciled against an attributed result from another without introducing an untraceable gap in the evidentiary chain. Structured, cited output from the retrieval layer is what makes post-hoc verification of a synthesized answer possible at all.

How to measure whether iterative planning is actually working

The benchmark landscape for research agents is young, contested, and still being developed. This is worth sitting with: we are deploying systems into production for which rigorous evaluation frameworks are still being figured out.

AutoResearchBench, built over three million arXiv papers, tests both Deep Research and Wide Research capabilities with controlled full-text extraction that eliminates web-access variability as a confound. The 9.39% and 9.31% scores for top systems in April 2026 establish a rigorous evaluation target, and a humbling baseline. DeepResearch Bench evaluates report fidelity and citation accuracy directly, which maps well onto multi-step synthesis tasks. The GAIA benchmark, tracked on the HAL leaderboard, reports Claude Opus 4.5 leading at 77.5% overall accuracy with an 84.5% web search subscore; this reflects general agentic web task performance, which is meaningfully easier than dedicated deep research benchmarks, and the gap between the two is itself informative.

Citation accuracy functions as a useful proxy for planning quality, and for knowledge-cutoff exposure. An agent that planned its retrieval well will have traceable evidence for each claim in its final answer. An agent that planned poorly will either hallucinate claims or, more insidiously, cite the wrong source for a factually correct claim that it arrived at through a different path. Systematic citation errors reveal planning failures that accuracy metrics alone can miss. I've found this to be one of the more reliable diagnostic signals in practice, precisely because it's hard to fake.

The reliability gap in enterprise deployment is the operational context around these benchmark numbers. A 2025 survey of 306 AI agent practitioners found that reliability issues constitute the largest barrier to enterprise adoption; practitioners are actively limiting agents to shorter, fewer-step workflows specifically to contain failure surfaces. This is a rational response to unpredictable loop behavior, but it also constrains the task envelope to the simplest cases, which somewhat defeats the purpose of building iterative planning in the first place.

Gartner's 2025 assessment is pointed: more than 40% of agentic AI projects are predicted to be cancelled by 2027, partly due to an inability to systematically evaluate deployed agents. Building iterative planning without building evaluation for it is building a system you cannot improve.

For teams without the resources to implement formal benchmarks, three instrumentation signals are informative. Step count per task reveals whether loops are terminating reasonably or running long on tasks where they should be converging. Citation coverage, the fraction of final-answer claims backed by retrieved sources, reveals how much of the output is actually grounded. Retrieval hit rate per step, tracking whether each query returns usable results or whether reformulation steps are mostly recovering from empty retrieval, reveals whether the query decomposition logic is doing its job. None of these is a substitute for formal evaluation, but together they tell you whether the loop is behaving.

Iterative planning in financial research agents, where hallucination has concrete costs

Financial research puts iterative query planning under conditions where the failure modes are legible in terms of real decisions. Questions are characteristically multi-hop: establishing a revenue trend requires a quarter-by-quarter breakdown, which requires segment-level detail, each of which may live in a different document. Sources conflict. Numbers change when accounting treatments change. The cost of a confident wrong answer isn't an abstract quality metric; it shapes what someone recommends, approves, or trades.

The baseline hallucination problem without iterative grounding is quantifiable in this domain in a way it often isn't elsewhere. A 2025 arXiv study evaluated LLMs on more than 197,000 financial questions and found that models answer revenue questions correctly for roughly 54% of companies when asked about 2017 data, but only 6% of companies when asked about 1995 data. The authors characterize this as "retrograde knowledge bias": older, less-indexed financial facts are markedly less reliable from static training. The confidence with which the model delivers the answer does not track the accuracy; it answers 1995 revenue questions with the same fluency it brings to 2017 questions.

Iterative grounding doesn't eliminate this problem, but it changes the failure mode in a consequential way. An agent that retrieves, evaluates, and reformulates its queries can discover that it lacks sufficient grounding for a claim and flag or abstain rather than confabulate. A single-shot pipeline has no mechanism for this. The agent with a planning loop may fail to find the relevant evidence; the agent without one doesn't know it's looking.

The multi-hop structure of financial questions also tests task decomposition in ways that expose weak planning. A question about whether a company's margin decline was driven by a specific business segment can't be answered by a single retrieval call. It requires decomposing into sub-questions about overall margin, segment contribution, and the timeline of changes, then reconciling what those retrievals reveal against each other. An agent that skips decomposition issues a broad query, receives a chunk that discusses margin in passing, and generates an answer that sounds informed. Anyone who has reviewed these outputs at volume knows what they look like: structurally correct, directionally plausible, and occasionally wrong in ways that take specific domain knowledge to catch. The wrongness isn't random; it's patterned, which makes it harder to screen for systematically.

The architecture isn't sufficient on its own. Good iterative planning in financial contexts requires a retrieval layer that can return structured financial data with clear provenance, not HTML scraped from a webpage that may be reporting on a different filing period than the one the question concerns. The planning loop and the retrieval infrastructure are not separable design problems; they interact at every step.

What the financial domain makes visible is the asymmetry between the cost of a hallucination and the cost of iterative retrieval. Running five retrieval steps instead of one takes time and costs more per query. Getting the answer wrong in a financial research context costs something that is harder to measure and considerably harder to reverse.