Multi-Step Research Agents That Plan, Search, Read, and Return Cited Reports

A multi-step research agent must do more than search and write. It must preserve the connection between a question, the evidence gathered to answer it, and every claim in the final report. Building that connection requires treating query decomposition, iterative retrieval, content extraction, synthesis, and citation grounding as separate engineering problems, joined by explicit state and feedback.

Why research agents fail to deliver trustworthy reports despite appearing to work

A fluent report can look indistinguishable from an accurate one until a reader follows its citations. The prose may be orderly while its references point to nonexistent URLs, its synthesis conflates sources, or its conclusions outrun the evidence. Successful completion is not the same as trustworthy research. The agent has produced an artifact, but that alone says little about whether its reasoning can be audited.

S1-DeepResearch distinguishes deep research from finding and verifying individual facts. An open-ended task also requires an analysis framework, evidence integration, and a citable deliverable. What happens when all those tasks are hidden inside a single model call? Their failures become hard to locate, because the final prose conceals whether the original problem was a missing question, unread content, or an unsupported inference.

How the five pipeline stages connect and where each one can break

Read from left to right, the pipeline starts with query decomposition, which turns the research goal into executable sub-questions. Iterative retrieval finds evidence for those questions, and content extraction turns the pages it finds into source material the system can use. Synthesis integrates that material into an answer. Citation grounding then connects the answer’s claims to retrievable sources and specific passages. Each handoff can lose information that the next stage needs.

FlowSearch illustrates how this sequence can remain connected without becoming rigid. Its planner initializes a graph-structured knowledge flow, with nodes representing subproblems and edges representing knowledge dependencies, then revises that flow as findings arrive. A Vocabulary for Multi-Agent Automated Research Systems treats agent roles, available operations, communication, and visible state as design choices that can each be changed on their own. These are also independent failure surfaces. Even a strong plan cannot make up for gaps in retrieval, and strong retrieval cannot fix synthesis that ignores disagreement, so each stage needs its own engineering work.

Query decomposition: turning an open-ended research question into an executable plan

A plan determines what the agent will consider evidence for. If decomposition picks the wrong sub-questions, accurate retrieval can still lead to a report that misses the point. Consider a comparative question split into tasks A and B. A linear to-do list treats them as independent, even when the answer to B changes which evidence from A is relevant. The plan needs to show that dependency before either answer is treated as settled.

TodoEvolve addresses this problem through task-adaptive planning. Its PlanFactory distinguishes four choices, namely topology, initialization, adaptation, and navigation. Topology organizes the work, while initialization creates that structure for the task. Adaptation governs its revision, and navigation issues executable directives. These choices need not have the same answer for every research question.

The architecture must therefore reflect the relationships the task requires. TodoEvolve describes DAG-based planning as useful in complex multimodal settings but excessive for linear tasks. FlowSearch shows knowledge dependencies, which offers a way to plan for questions whose branches affect one another. For developers, the lesson is to choose a structure that exposes those dependencies and permits revision when the initial decomposition proves wrong.

Iterative retrieval: why a single search pass is structurally insufficient

A search result can change the meaning of the next search. That makes iteration a correctness requirement. PAPERPILOT illustrates the ambiguity with a request to find follow-up work on a paper. The request might mean direct citations, recent extensions, work in the same application domain, or research that uses one part of the paper’s method. One query cannot reliably tell which of those the request means.

PAPERPILOT constructs an executable DAG of search operators, including keyword search, citation expansion, filtering, scoring, reranking, and evidence extraction. It revises both the query and the workflow through feedback. With multi-turn interaction, Hit@5 rose from 58.0 to 77.0, while errors in running the workflow fell to zero. These results anchor an important distinction between changing search words and changing search behavior, without guaranteeing the same outcome elsewhere.

For an autonomous agent, evaluation of retrieved content supplies the feedback. Does a result answer the sub-question, answer only part of it, or reveal a faulty premise? Those outcomes require different next steps. An editable workflow gives the agent somewhere to express that difference. The infrastructure underneath it must support rapid successive searches with fresh results and low latency, without rate constraints becoming the bottleneck.

Content extraction: reading retrieved pages reliably enough to ground a claim

Finding a relevant URL does not mean reading its contents correctly. Extraction can silently return something that looks usable while omitting the passage needed to support a claim. HTML rendering artifacts can corrupt quotations, and a paywall can leave a partial page that appears complete. Dynamic content may be missing when the page is scraped. Encoding errors can also drop sentences without producing an obvious failure.

These defects change what synthesis has to reason with. A source that appears to make an unqualified claim may simply have lost its qualification during extraction. The appropriate handoff is therefore a typed context packet. That packet includes source metadata, recency, and relevance to the sub-question, so later stages can weigh and attribute the evidence.

For developers, this calls for a structured extraction layer with explicit failure monitoring. A tiered approach begins with fast extraction and falls back to a deeper read for resistant pages. A service-level indicator, or SLI, must catch failures in extraction before they reach synthesis. Extraction quality is a separate engineering responsibility. Delegating it to whatever content the model happens to fetch leaves downstream reasoning exposed to silent loss.

Synthesis: integrating evidence across sources without laundering conflicts

Independent source summaries do not become synthesis when placed next to one another. A research answer must show how the evidence fits together, especially when the sources disagree. S1-DeepResearch identifies evidence integration, knowledge synthesis, planning, file understanding, and structured report generation as underrepresented in existing search-centric training data. Finding the right fact is a narrower task. A model’s fluency on closed-ended questions does not establish its ability to produce a defensible open-ended report.

One source may supersede another through recency or authority, but the disagreement may instead be genuine and belong in the report. An apparent conflict may also dissolve when both passages are read in context. These possibilities require different conclusions. Treating all disagreement as noise to be smoothed away gives the reader confidence at the expense of accuracy.

FlowSearch keeps a global knowledge graph so that reasoning about one part can be checked against dependencies among sub-findings. This helps when sources are processed one at a time and each summary sounds right on its own, but the summaries disagree when put together. The synthesis stage needs explicit conflict-resolution logic. Its correctness remains inspectable only if each resulting claim retains a traceable connection to the extracted content that supports it.

Citation grounding: ensuring every claim in the output traces to a real, retrievable source

A citation has to do more than resemble a reference. It must connect a claim to a specific extracted passage from a specific retrievable source. Asking a model to add references after drafting reverses that relationship. The claim already exists, and the model is being asked to supply its provenance retrospectively. That is where plausible-looking URLs can substitute for evidence.

DRBench’s 2026 analysis found up to 18% of citations were non-resolving overall across models and agents. The vocabulary paper makes the evaluator part of the research system, which places citation checking inside the agent’s run. Grounding is an architectural obligation.

PAPERPILOT places evidence extraction inside its retrieval DAG, illustrating how attribution can precede synthesis. For developers, the corresponding infrastructure requirement is a retrieval or research layer that returns source-attributed evidence and cited results. This reduces reliance on post-hoc reference generation, but it does not remove the need to check whether the final claim accurately represents its source.

How planning architecture must adapt when retrieved evidence contradicts the original plan

Once retrieval can challenge a premise, the plan must become revisable state. Otherwise, the agent continues answering a question that its own evidence has undermined. TodoEvolve treats adaptation as distinct from initialization. Creating a useful starting structure and deciding when to change that structure are separate responsibilities. High-conflict tasks demand more than competent execution of the original sequence.

The practical requirement is explicit status for each sub-question, including whether it has been answered, remains in progress, or has been invalidated by new findings. Without that state, the planner lacks a basis for revision. A contradiction found during synthesis may call for more retrieval, while a retrieval result may show a dependency that the plan missed between tasks. The feedback must reach the planning layer. Leaving it inside a local reasoning step prevents the rest of the run from responding.

This also explains why adding agents is not sufficient. A single agent can overcommit to an early hypothesis, while serial execution across agents can fragment intermediate reasoning. The orchestration layer must keep the global context as work moves from one role to another. Revision then changes the shared research structure and the earlier assumptions that a new instruction alone would leave in place.

What a production-grade research agent architecture looks like end to end

For developers, the blueprint begins with distinct interfaces for planning, retrieval, extraction, synthesis, and verification. A multi-agent design can assign each responsibility to a specialized agent, but the division only helps if the handoffs preserve evidence and state. The planner needs a task structure it can revise mid-run. Retrieval needs a low-latency, high-freshness search API and an editable workflow. A fixed prompt template or search access alone falls short of what that architecture needs.

The extraction layer needs structured output, tiered reading, and SLIs that expose silent failures. Its context packets must give synthesis enough source information to weigh evidence and preserve attribution. Synthesis needs a model suited to open-ended research, with explicit handling of conflicts. Citation grounding needs passages that are pre-grounded and results that are cited. Verification then checks the relationships that these stages were designed to preserve.

Shared state binds these components into a research system. It must remain queryable across what has been retrieved, extracted, synthesized, and left unresolved, because those distinctions inform when to continue searching and when to write. FlowSearch demonstrates the importance of global coherence. Lossy handoffs can undo otherwise capable components. The architecture is only as trustworthy as its weakest stage, including the interfaces between them.

Verifying that the output is actually grounded before it leaves the agent

The vocabulary paper describes a trajectory as the path from an input task to the returned artifact and includes the evaluator as a system component. The final check must examine the report’s evidentiary relationships. Readability and completeness cannot stand in for them.

Three checks address different ways those relationships can fail. URL existence establishes whether the cited address resolves to a real page. Passage grounding asks whether the page has the passage that was extracted and attributed to it. Claim-to-source alignment asks whether the report says what the source actually supports. Passing the first two does not establish the third.

Alignment is the hardest check because synthesis can change meaning without breaking the citation. A real passage at a working URL may support a narrower finding than the report presents. Verification must therefore inspect the claim. The auditability standard is concrete. Given any claim, a reader should be able to follow its citation, find the supporting passage, and confirm that the report represents it accurately.