Multi-Step Query Refinement in Agentic Research Workflows

Single-pass research agents fail because errors compound silently: a wrong retrieval at step one feeds every dependent step that follows, with nothing in the pipeline positioned to catch it. The failure is structural, a consequence of how sequential pipelines are built. The hardest tier of the ALE benchmark, built by Berkeley RDI, reported a full-pass rate of 2.6% among mainstream agent configurations, not stripped-down toy setups built to fail. That number says something specific: sequential pipelines with no internal correction step do not hold up against the kind of multi-step, multi-source work that real professional research actually demands.

What does a 2.6% full-pass rate actually reveal, beyond the obvious fact that the task is hard? It points to where the failure happens. The weak link in these pipelines is rarely the final generation step, the point where the agent writes up its answer in prose. The agent reports the task as complete because, structurally, it has no way to know otherwise. That is the gap the rest of this piece addresses: not how to make a single pass smarter, but how to build a second process whose entire job is to check the first one before anyone trusts its output.

What the dual-loop architecture actually does, step by step

The dual-loop architecture answers that gap by splitting the work into two distinct processes that run in sequence rather than one process trying to do both jobs at once. One loop gathers evidence and drafts an answer. A second loop audits that draft, checks it constraint by constraint, and sends the agent back out to search only where something is actually missing. Picture it as two separate passes over the same problem, each with a narrow job, rather than one long pipeline hoping nothing goes wrong along the way.

The first pass, the gathering loop, works roughly the way standard retrieval-augmented generation already works. The agent takes the query, retrieves relevant evidence from available sources, and assembles a first-draft answer grounded in whatever it found. Most agentic research tools stop here, treat the draft as final, and hand it to the user, which is the exact point at which single-pass systems fail silently, since the draft reflects whatever the first retrieval surfaced, errors included.

The second pass is where the architecture earns its name. The output of this pass is a structured list of gaps: this claim lacks a citation, this date range was never covered, this figure conflicts with another figure pulled earlier. That gap list then drives a new, narrow round of searching, aimed only at the specific holes identified. The principle carries over cleanly to research agents. Accuracy compounds when only the unresolved parts of the problem get more attention, instead of throwing broader search at the whole thing and hoping the answer improves.

What Counts as a Gap Worth Pursuing

An audit loop is only as good as its definition of a gap, and this is where the architecture either delivers on its promise or quietly falls apart. An audit loop built around vague notions of quality, things like "does this answer feel complete," will trigger follow-up searches that do not actually narrow anything, because there is no precise failure for the new search to target. An audit loop built around explicit, enumerable constraints does something different: it checks each claim in the draft against a defined list of requirements, source coverage, date range, whether conflicting data points have been reconciled, whether the granularity matches what the query asked for, and flags only the claims that fail a specific, nameable test.

Multi-Turn Agentic Scientific Literature Search via Workflow Induction, built around a system called PaperPilot, illustrates what a structured target for this kind of audit can look like. Rather than relying on a general-purpose critic to review a draft, PaperPilot constructs an executable DAG, a directed graph of paper-search operators, directly from the original query and an anchor paper. Because the search process itself is already broken into explicit operators, an audit built on top of that structure has concrete things to check against: did the citation-expansion step actually run, did the filtering step apply the right criteria, is each paper in the final set traceable back to one of these defined operations. That is a fundamentally different proposition than asking a general critic model to read a paragraph and decide if it sounds thorough.

Evidence arbitration is the clearest example of how granular this gets in practice. It has to treat the conflict as a reconciliation task: flag the discrepancy explicitly, and send a targeted re-retrieval to resolve which source is current, which is superseded, or whether the two figures are measuring genuinely different things. That is a structured decision process, not a judgment call about which source "feels" more credible.

Can a model reliably catch its own errors when the same model generated them in the first place? If the biases and blind spots that produced a flawed claim are still active during the review of that claim, self-critique risks rubber-stamping its own mistakes. The answer that holds up in practice is to ground the audit not in the model's own reasoning but in external, retrieved evidence. The question the audit loop asks is not "does this sound right," but "is this specific claim supported by a document that was actually retrieved." Grounding the check in cited sources rather than in the model's parametric memory substantially reduces the same-model blind spot, though it does not eliminate every case, particularly when every source available to the retrieval layer happens to share the same systematic gap.

Why Real-Time, Cited Retrieval Is the Audit Loop's Precondition

None of this works without a retrieval layer built to support it, because the audit loop can only close a gap it can verify against something. That dependency runs in one direction: the quality of the iterative refinement is bounded by how fresh, how citable, and how reconcilable the underlying search infrastructure actually is.

Static training data cannot serve as the evidence base for this kind of check. The audit loop needs something it can send a follow-up query to and get back a dated, sourced answer, not a confident paraphrase from memory.

Speed matters here in a very concrete way. Every follow-up search the audit loop triggers adds latency, and that latency stacks across iterations: a system that takes ten seconds per search might be tolerable for one round of refinement but becomes painfully slow and expensive once a query needs five or six rounds of targeted follow-up. Zep's 2026 work on temporal knowledge graphs points at the scale of what is possible here, reporting a 90% reduction in latency compared to standard retrieval baselines. A retrieval layer that cannot move fast enough makes multi-step iteration uneconomical, no matter how well-designed the audit logic sitting on top of it happens to be.

Every result that comes back from a follow-up search also needs to be source-attributed, because the entire audit mechanism depends on tracing a claim back to a document. A retrieval layer that returns fluent, unattributed summaries breaks the chain exactly where it matters most, since there is nothing left for the audit loop to check the claim against. You.com's API suite, including a Research API and a Finance Research API, is built around this exact requirement: results come back cited and source-attributed by design, so every pass through the loop produces evidence the audit stage can actually check.

How Multi-Agent Debate Extends the Dual-Loop Pattern

The same principle that separates gathering from auditing at the evidence level also applies one level up, at the level of deciding what question to pursue. A single audit loop, however well-built, can catch a missing citation or an unresolved conflict, but it has no good way to catch a research direction that was wrong from the start. If the initial framing of a query sends the agent looking in the wrong place entirely, auditing the evidence gathered under that framing will not fix the framing itself: the audit loop will happily confirm that every claim is well-sourced, even though the whole direction is off.

Multi-agent debate addresses that blind spot by putting more than one reasoning path in competition rather than trusting a single agent's initial framing. AutoResearchClaw builds this pattern directly into its pipeline, using structured multi-agent debate during both hypothesis generation and result analysis so that no single reasoning path dominates the process unchecked. It pairs that debate with a Pivot/Refine decision loop: when an experiment fails, the system treats the failure itself as information, and either repairs the existing execution path or pivots to a different hypothesis.

A Vocabulary for Multi-Agent Automated Research Systems offers something builders need once debate enters the picture: a shared structural vocabulary for describing who the agents are, what operations each one can perform, how they communicate, what each agent can see, how actions get chosen, and how the eventual output gets evaluated. That vocabulary matters because debate without clear structural roles turns into noise. It gives builders a concrete way to say which agent proposes a direction, which agent generates the counterargument, and how the audit mechanism from the earlier sections plugs into that exchange, rather than treating "multi-agent" as a vague label for several models talking to each other.

Embedding Loops in a Directed Graph

Once gathering, auditing, and debate are all in play, the practical question becomes how to wire them together so the whole system behaves predictably rather than looping forever or escalating at the wrong moment. Embedding these loops inside a directed graph gives builders explicit control over when auditing triggers, when a pivot happens, and when the workflow hands off to a human. That level of control is what separates an agent that survives contact with messy, ambiguous production queries from a demo that only works on clean inputs.

In a graph-based workflow, each node represents either a gathering step or an audit step, and the edges between nodes carry conditions. One especially important edge handles the case where no amount of targeted follow-up search is closing the gaps: after a fixed number of iterations without progress, the workflow routes to a human reviewer rather than looping indefinitely on a query that may simply be unanswerable with the available evidence. That escalation path matters as much as the audit mechanism itself, since it gives a dual-loop agent a way to recognize its own limits before spinning on an edge case.

Post-task review feeds back into this design continuously over time. Reviewing completed runs this way lets builders see which nodes in the graph tend to produce unresolved gaps across many queries, and adjust the workflow structure accordingly, rather than relitigating the same mistake inside every individual run.

Cost is the other constraint shaping how these graphs get built in practice. Because the workflow is expressed as an explicit graph, that routing decision is visible and auditable in its own right, not buried inside a single model's undocumented behavior.

How to evaluate whether a dual-loop agent is actually improving across iterations

None of the architecture described above means much if a team cannot tell whether it is actually working once it is running in production. Without some form of loop-level observability, an agent that appears to be refining its answer over several passes might simply be searching more without ever converging on anything more accurate, which looks identical to progress from the outside until someone checks the actual output.

The right unit to measure is gap reduction per loop pass, not the quality of the final answer taken on its own. If each audit pass produces fewer unresolved gaps than the pass before it, the architecture is doing its job. FrontierChallenge offers a useful template for this kind of thinking, since it evaluates scientific workflow completion through verifiable, end-to-end delivery of a finished artifact. A team building its own evaluation harness for a dual-loop agent can borrow that same instinct: check whether the full workflow actually completed and produced something verifiable, not just whether the last paragraph reads well.

Multi-Turn Agentic Scientific Literature Search via Workflow Induction supplies a second kind of signal, this time at the level of the search process itself. The FACTS Grounding leaderboard adds an external benchmark for the related question of factual accuracy: it evaluates how well a model's outputs are grounded in a provided context document, with the leading model reaching 82.0% on 2026 leaderboard data. Tracking where a system sits on a benchmark like that over time gives a team an outside, comparable signal for whether the audit loop is actually getting better at keeping claims tied to evidence, rather than relying only on internal, self-reported metrics.

Citation completeness is the simplest practical proxy available, and it costs nothing extra to check: if every claim in a final output traces back to a retrieved, dated source, the audit loop did its job on that run. The mental model running through this entire piece, two separate loops, a constraint-based audit, and targeted rather than brute-force follow-up search, only earns its keep once a team can watch it operate and confirm, pass by pass, that the gaps are actually shrinking.