Deep Research Agent Architecture Overview

Every mature deep research agent, regardless of laboratory origin or whether it runs as a single model or a multi-agent ensemble, organizes its behavior around a recognizable loop. Consistent enough to treat as definitional.

The sequence runs roughly as follows: the agent plans, decomposing the user's query into addressable sub-questions; searches, issuing targeted retrieval queries against web sources, vector stores, or external tool endpoints; reads, parsing retrieved documents for relevant content; reflects, evaluating what was found against what the plan required; iterates, re-entering the loop with refined queries; and finally synthesizes, assembling accumulated evidence into a cited report. What makes this architectural rather than merely procedural is that each phase feeds forward into the next. The agent's behavior at any step depends on what it found at the prior one.

The loop runs under sparse feedback, with no human checkpoint between steps. This alignment with reinforcement learning, rather than with the static retrieval-augmented generation pipelines that preceded it, is not incidental. A human demonstrator annotates individual steps; RL optimizes the whole chain from a single outcome signal. Supervised fine-tuning on human demonstrations struggles to capture what actually matters here, which is the quality of decisions across the full sequence, not any single step in isolation.

Source attribution is frequently misunderstood as a formatting concern. In mature implementations, provenance tracking is built into the loop itself: the agent maintains, as it runs, a mapping between sources and the findings they support. This is not decoration applied at synthesis. It is precisely why the loop is harder to implement stably than it is to describe, because provenance can degrade quietly, two or three retrieval rounds in, long before synthesis arrives to make the failure visible. That kind of silent corruption is what makes external auditing of these systems so difficult. The failures visible in the final report are the easy ones.

How the planning component works and where it can break

Planning in mature implementations is not a one-time step executed at session start and then frozen. Most systems generate an initial plan and revise it continuously as retrieval surfaces new information. The plan is a living artifact, which is also what makes it vulnerable.

Two production design choices illustrate a real tension. OpenAI's system initiates a brief clarification step before committing to a research strategy. Gemini Deep Research makes the initial plan explicit and user-editable before execution begins, trading some autonomy for transparency. Both choices acknowledge the same structural problem: the agent cannot know, at plan time, what retrieval will surface. Where they differ is in who bears the corrective burden before the session begins.

A plan, in practice, typically contains subtopic decomposition, query decomposition into addressable retrieval units, targeting, and sequencing logic. That last element matters more than it tends to get credit for. Which subtopic gets researched first is not arbitrary. Findings from early subtopics constrain what later steps should ask, and sequencing errors propagate.

Propagation is planning's most serious structural vulnerability. A hallucinated subtopic early in the plan, one the agent generates confidently but without factual grounding, redirects the entire research thread. Each subsequent retrieval and reasoning step builds on what came before. But what if the root cause of a bad final report is not a retrieval failure at all, but a flawed subtopic generated in the first thirty seconds of planning? By the time the final report is assembled, the root cause may be invisible, and the benchmark numbers will look cleaner than the underlying planning reliability actually is.

Evaluation compounds the problem. Planning quality is typically assessed only through end-task accuracy: how good is the final report? Without direct examination of the plan as a distinct artifact, a poor output could reflect a bad plan, adequate planning followed by bad retrieval, or something further downstream. These are different failure modes with different remedies, and current evaluation frameworks cannot distinguish between them.

There is also a transfer gap that rarely surfaces in formal evaluation. Most current systems treat each research task in isolation. There is no mechanism for accumulating generalizable research strategies across prior sessions, no analog to the experienced researcher who has learned, across hundreds of projects, which sequence of sub-questions tends to be productive for a given problem type. For broad-use deployments, this matters considerably.

Multi-hop retrieval and why single-pass search is insufficient

Multi-hop retrieval means that each search query is informed not only by the original question but by what prior searches returned. The answer to sub-question A determines which sub-question B to ask. This is the operational core of what distinguishes deep research agents from basic retrieval-augmented generation, where retrieval happens once and answers happen once.

The necessity becomes clear when you consider what genuinely complex research questions look like structurally. A question about competitive market dynamics, or the causal chain behind a policy outcome, is not a point you can retrieve; it is a knowledge graph you have to traverse. Edges only become visible after earlier nodes have been explored. Single-pass systems cannot traverse graphs they cannot see in advance.

Dead-end detection is underappreciated here. Gemini Deep Research is specifically optimized to recognize when a retrieval thread is yielding diminishing returns and to redirect resources rather than continue on unproductive searches. Without it, agents consume substantial compute on retrieval paths that will never contribute to synthesis, and the cost model for these systems makes that a serious problem. The flip side is worth sitting with: redirecting away from a low-yield thread is a judgment call about what the research does not need to pursue, and that judgment can be wrong. Efficiency and coverage are in genuine tension.

What "retrieval" means in mature implementations has expanded considerably beyond web search. OpenAI's system integrates web search, remote Model Context Protocol servers, and internal vector stores. Gemini uses large-scale context window RAG ensembles capable of handling multimodal data. MCP servers, as an architectural pattern, allow agents to extend retrieval reach without requiring custom function-calling logic for each new data source, which matters because information relevant to a complex research question rarely lives in a single place or format.

The high-entropy problem is the fundamental challenge retrieval must contend with. Web data is noisy, contradictory, and highly variable in quality. The agent cannot simply accumulate everything it finds; it must filter, and filtering is a reasoning task. Why exactly does this matter? Because judging relevance and credibility under uncertainty is not a narrow retrieval capability — it is a reasoning capability that retrieval depends on, and training for it is a different problem than training for retrieval coverage. Most benchmark designs do not account for this distinction, which is part of why benchmark performance and production reliability diverge as much as they do.

Memory and context management across a long research session

The naive framing of memory as a capacity problem misses what actually goes wrong in practice. The challenge is not that agents run out of context. As a session grows, the working context fills with content that is irrelevant, outdated, or redundant, and accumulated noise degrades reasoning quality in ways that are subtle and difficult to detect from outside the system. I have seen systems produce confident, well-structured reports that were built, in large part, on a corrupted working context. Nothing in the output signaled the problem.

Attention dilution occurs when long contexts spread a model's attention mechanism across too much material, degrading comprehension of the current task. Noise accumulation is distinct: weakly relevant content does not merely fail to help; it introduces false associations that actively mislead reasoning. Storage cost and retrieval latency compound these problems at infrastructure scale. Together, they create a meta-task running alongside the research task itself. The agent must manage its own working memory, selecting what to retain, integrating new findings with prior ones, pruning what no longer serves the current direction.

Three main approaches are in active use, and none dominates convincingly. Long-context models process everything in context directly; Gemini 2.5 Pro's one-million-token window is the frontier example. The approach has genuine virtues: simplicity, coherence, no retrieval latency. It is also bounded by physical limits and becomes expensive at scale. RAG-based externalization stores information outside the model and fetches it on demand by semantic similarity, decoupling memory size from context size at the cost of retrieval latency and relevance errors on fetch. Hierarchical memory systems, inspired by how operating systems manage memory across registers, RAM, and disk, organize information into working memory for the active task, main memory for recent session history, and archived storage for longer-term material.

Frontier proprietary systems tend to combine long contexts with selective curation strategies. Open-source implementations more often rely on RAG given tighter context constraints. The diversity of approaches reflects genuine uncertainty about the right tradeoff, and the tradeoff itself shifts as model context windows expand and retrieval costs change. There is no settled answer here, and the right choice for a given deployment depends on factors, including latency tolerance, budget, and task structure, that vary considerably across use cases.

Single-agent versus multi-agent orchestration and what each trades away

In a single-agent architecture, one model manages planning, retrieval, reflection, and synthesis sequentially. OpenAI's Deep Research product follows this pattern, centered on a fine-tuned o3 reasoning model. The architecture is simpler to reason about, failures are easier to attribute, and coordination overhead is essentially zero. Its vulnerability is cognitive saturation at scale: one model managing a large, high-entropy context across an extended session encounters reliability bottlenecks as the task grows.

Multi-agent architectures distribute semantically distinct roles across specialized agents. Anthropic's advanced research configuration uses a lead orchestrator coordinating several sub-agents running in parallel. OpenAI's Deep Research API introduces specialized agents for triage, clarification, and research proper, improving both transparency and scalability. Google's Gemini 2.5 Deep Think, unveiled at Google I/O 2025, represents the first publicly available multi-agent model from Google, spawning multiple agents to tackle sub-questions simultaneously.

The parallelism dividend is real. When a research question fans out across several independent subtopics, multi-agent systems can research them concurrently, compressing wall-clock time considerably against a sequential single-agent approach.

The coordination cost gets underweighted in comparative assessments. Handoff overhead between agents, communication protocol design, and higher aggregate compute consumption are genuine engineering concerns. Gemini 2.5 Deep Think's parallel spawning uses substantially more compute than a single-agent approach to equivalent tasks. The diagnostic problem is also harder: when a multi-agent pipeline produces a wrong answer, tracing which agent introduced the error requires understanding the full graph of agent interactions, not just a linear execution trace.

Neither paradigm is strictly superior. The choice reflects a tradeoff between reliability under scale, where multi-agent architectures have a theoretical edge, and coordination cost and diagnostic clarity, where single-agent systems are simpler to operate. Task structure is probably the most important variable: a research question with many genuinely independent sub-questions benefits more from parallelism than one with a linear dependency chain where each step constrains the next. One might argue that the right architecture is not a fixed property of a system at all, but a function of the query, and that future systems will need to select between paradigms dynamically rather than committing to one at design time.

How end-to-end reinforcement learning replaced rigid pipeline training

The earlier paradigm organized deep research as a fixed pipeline: a planner component, then a tool-use component, then a writing component, each trained or prompted separately. Composable in theory; brittle at the seams in practice. Optimizing one stage in isolation did not reliably improve end-to-end performance, because the stages had not been trained to cooperate with each other.

The shift around 2025 was substantive. Almost every mature deep research agent abandoned rigid pipelines in favor of an integrated model-as-agent design trained end-to-end. End-to-end training allows the model to learn task decomposition, browsing behavior, tool invocation, and citation assembly as a unified skill rather than as a stack of separate competencies that must coordinate without having been trained to do so.

OpenAI's approach involves end-to-end reinforcement learning on complex browsing and reasoning tasks, placing the model in simulated research environments with access to tools and genuine multi-step tasks. The reward signal is derived from task outcomes rather than from human ratings of individual steps, which means the model learns to manage the full loop rather than to optimize each step locally.

DeepResearcher, published by Zheng et al. in 2025, represents the first system trained via end-to-end RL in a real, dynamic web environment rather than a simulation, specifically for deep information retrieval and integration. Real web environments introduce noise, link rot, inconsistent formatting, and adversarial content that simulations cannot fully replicate. Whether training in simulation generalizes adequately to live environments remains an open empirical question, and one with real stakes for systems deployed against the actual web.

Tongyi DeepResearch, from Alibaba, offers a different architectural approach to the same training paradigm: a sparse mixture-of-experts (MoE) design with approximately 30.5 billion total parameters but only 3.3 billion activated per token, trained through continual pretraining, supervised fine-tuning, and reinforcement learning across the full agentic pipeline.

Agentic RL instability is a problem the field has not yet resolved. RL on clean reasoning tasks, where the environment is well-defined and the reward signal is clear, is challenging but tractable. Agentic RL, where reasoning must integrate with live tool use in noisy real-world environments, is substantially harder to stabilize. The environment introduces variance that disrupts the training signal in ways that are difficult to anticipate.

One clearer empirical benefit: RL training reduces hallucinated steps in multi-turn interactions more effectively than supervised fine-tuning alone. If hallucinated intermediate steps lead to poor final outputs, the reward signal penalizes the policies that generated them. The model learns to be more conservative about asserting things it cannot ground in retrieved evidence. This helps, but it does not close the gap entirely. The reward signal operates on final outputs, and a hallucination that gets corrected later in the session leaves no trace in the signal. The model is never penalized for the error it quietly recovered from. That raises an important question: is training an agent to recover gracefully from errors actually the same thing as training it not to err in the first place? The answer, by the logic of the reward signal, is no.

The cost and latency profile that shapes how these systems are deployed

Token consumption in agent workloads is categorically different from chat. Because deep research agents iterate through search, reading, reflection, and synthesis across many cycles, they consume roughly fifteen times the tokens of a comparable chat interaction. At frontier reasoning model pricing, currently in the range of tens of dollars per million tokens, a single complex research session can cost the provider several dollars to tens of dollars in API fees. That number directly shapes every architectural decision about context budget, tool call frequency, and how aggressively the agent should prune accumulated content.

Wall-clock time follows from the depth of the task. Typical sessions run from ten minutes to two hours depending on query complexity, a latency profile incompatible with synchronous user-facing requests. The architecture must be asynchronous by design, and systems that have tried to compress this for UX reasons have generally paid for it in output quality.

Production systems have responded with concrete engineering choices. Gemini Deep Research features asynchronous task management, working in the background while the user continues other work. Streaming output and intermediate thinking summaries surface progressively, so users are waiting with visibility rather than blind. OpenAI introduced mid-session interruption, allowing users to inject new context or redirect focus without restarting the session entirely.

The budget management problem is simultaneously a research challenge and an economic constraint. Avoiding several hundred thousand tokens of crawled content in a single context window is not merely good practice from a reasoning quality standpoint. At frontier pricing, it is a financial necessity that determines which architectural patterns are viable at scale. Systems that do this well have a structural advantage independent of their benchmark scores, and this is a dimension of performance almost no published evaluation captures.

Hallucination and planning failures as structural risks, not edge cases

Hallucination in deep research systems has a specific character that distinguishes it from the factual errors familiar from chat models. It is not primarily a matter of the model stating false facts or failing citation grounding at the sentence level. It is the failure to distinguish authoritative information from rumor or weak sourcing, combined with poor confidence calibration that does not signal uncertainty to the reader. The output reads as authoritative because the model was trained to produce fluent, authoritative-sounding text, but the evidence base underlying a given claim may be thin or contaminated, and confidence calibration provides no corrective signal to the reader. The fluency is the problem.

OpenAI has acknowledged in its own internal evaluations that its deep research systems struggle to accurately convey uncertainty, and that minor citation and formatting errors persist in reports. This admission matters because it comes from the developer most invested in the product's success, which suggests the problem is more pervasive than vendor communications typically indicate.

The multi-hop amplification mechanism is what makes hallucination particularly dangerous in these systems. Each retrieval and reasoning step is an opportunity to introduce an error. Because later steps build on earlier ones, a hallucination introduced in the second round of retrieval can propagate forward into a systematically wrong analytical frame, not just a wrong sentence. The final report may be internally consistent, fluently cited, and still misleading because a bad assumption entered the pipeline early and never got corrected.

Planning failures are harder to detect than retrieval hallucinations. A hallucinated subtopic in the initial plan sends retrieval in entirely the wrong direction. Because end-task evaluation measures the quality of the final report rather than the quality of the plan, a planning failure looks indistinguishable from a retrieval failure from the outside. Diagnosing these failures requires unpacking the agent's execution trace, which is not always available and not always interpretable when it is.

Context curation failure creates a third pathway. When noise accumulates in working memory without adequate pruning, the agent reasons against a corrupted evidence base. The model does not know its context is contaminated; it produces confident, fluent outputs because it is doing exactly what it was trained to do, which is to synthesize the information available to it. The problem is that the available information is bad, and nothing in the standard inference loop flags this.

Reinforcement learning training mitigates these risks without eliminating them. The empirical evidence that RL reduces hallucinated steps in multi-turn sequences is reasonably clear. But end-to-end evaluation still struggles to catch intermediate-step hallucinations that do not surface in the final output because the agent corrects for them later in the session. Those errors are gone from the report. They consumed compute, time, and retrieval budget on the way to being corrected, and they represent a failure mode that current benchmarks are not designed to surface. For users relying on these reports to make consequential decisions, a report that looks clean may have passed through a contaminated intermediate state that left no visible trace, and no current evaluation framework will tell them that.

How the field currently measures deep research agent performance

Evaluating a system that produces a multi-page research report with dozens of citations, synthesized from hundreds of sources across an hour-long session, is not analogous to evaluating a model on a multiple-choice benchmark. The output is heterogeneous, the ground truth is often contested, and the evaluation process itself requires substantial expertise. The measurement problem is real, and it currently understates how difficult these systems are to assess.

GAIA, the General AI Assistants benchmark, is among the most widely used evaluation frameworks for this class of system. It comprises 450 questions across three difficulty levels, requiring reasoning, multi-modality, and factual grounding across a range of task types. Its structure is designed to resist the pattern-matching on training data that makes simpler benchmarks unreliable indicators of real-world performance.

The field also relies on domain-specific evaluation suites for scientific literature synthesis, competitive intelligence, and legal research, where expert assessors can judge output quality against a known evidence base. These evaluations tend to be more ecologically valid but are expensive to run and difficult to standardize across systems, which limits how often they get used and shapes which signals actually drive development.

Several structural gaps in current evaluation are consequential. Plan quality is almost never evaluated directly. Intermediate-step reasoning, including which retrieval decisions led to which conclusions, is rarely surfaced in a form that allows external audit. Confidence calibration, whether the agent appropriately signals uncertainty about claims it is less certain of, is measured inconsistently across evaluation suites.

It is also worth considering what the field does not yet have: a standard evaluation protocol that captures the full loop — planning quality, retrieval efficiency, context curation, hallucination rate at intermediate steps, and final output accuracy, all measured in a single coherent framework. The benchmarks that exist measure subsets of this, and none yet treats intermediate-step reasoning as a first-class evaluation target. The gap between subset measurement and full-loop evaluation is where the most important performance questions currently live, and where the most consequential improvements are likely to emerge, once the field reaches some consensus about what it is actually trying to measure.