The word deep tells us very little about how much research actually happened. An agent can search several sources and still produce a confident answer from incomplete or inconsistent evidence.
A deep search agent is meant to do more: break the problem into smaller tasks, choose the right sources, check what it finds and return for another pass when the evidence does not hold up.
We’ll use finance as the worked example because it makes these moving parts easy to see, but the same architecture applies wherever an agent must research before it responds.
The core loop
The fundamental pattern of a deep search agent can be expressed as a four-phase loop:
The agent plans subtasks, executes them using tools, validates the results and either replans when it finds gaps or synthesizes a final report.
Phase 1: Plan
The agent receives a research question and decomposes it into subtasks with explicit dependencies.
For a comparison of NVIDIA, AMD and Intel, for example, a planner might assign separate tasks for gathering each company’s financial data, reviewing market news and analysing filings. Those tasks can run in parallel, while calculating growth rates and writing the final comparison must wait for their results.
Good plans have measurable outcomes such as “fetch revenue data” rather than vague goals such as “understand the company.”
Phase 2: Search and execute
The agent executes each subtask using the appropriate tools. In our financial example, those might include data APIs, SEC EDGAR, web search and earnings-transcript databases. In another domain, the sources could be internal documentation, research papers, case law or product data.
This is where the “deep” in deep search comes from. The agent does not fire one search query and return the first plausible answer. It selects the right tool for each subtask, handles errors and retries, and accumulates its findings in a scratchpad.
Phase 3: Validate
This is the phase that separates deep search from naive automation. The agent checks its findings for:
Internal consistency: Does a figure from a regulatory filing match the company’s earnings transcript?
Completeness: Did we successfully gather information for every company?
Reasonableness: Is 500% year-over-year growth plausible, or did the agent parse a table incorrectly?
Missing evidence: If one API call failed, does the task need to be retried through another source?
Validation matters beyond finance. Any research agent can produce a polished answer from incomplete, contradictory or incorrectly parsed evidence. The validator’s job is to notice before that answer reaches the user.
Phase 4: Synthesize or replan
If validation passes, the agent combines its findings into a structured report. If validation exposes gaps or errors, it returns to the planning phase with an updated understanding of what is missing.
The loop continues until the agent has enough validated evidence to produce its final response.
The components behind the loop
Making each phase work requires several supporting components operating together:
The orchestrator manages the research loop, delegating work to the planner, tool executor, validator and synthesizer. A context manager and scratchpad prevent token overflow, preserve intermediate findings, and maintain an audit trail.
Every implementation combines these components in some form. What changes is how much responsibility each component carries.
Three architectural approaches
Real implementations reveal three broad approaches to building deep search agents. Each makes a different trade-off between complexity, cost and capability.
Approach 1: Single agent with ReAct loop
The simplest approach uses one LLM agent with access to tools, running in a ReAct—or Reason and Act—loop.
Given a task, the agent reasons about what to do next, takes an action, observes the result and repeats until the task is complete. One model handles planning, execution, validation and synthesis within a single conversation context.
Step-DeepResearch, an open-source 32B model fine-tuned for deep research, is one example of this architecture.
This approach is the easiest to implement and debug. However, it can struggle with context overflow on complex assignments, offers limited parallelism and provides no role specialization.
It is best suited to focused research tasks with limited scope.
Approach 2: Multi-agent with specialized roles
The second approach assigns each phase of the research loop to a separate agent. Each agent receives its own prompt, tools and context window, then passes structured output to the next stage.
Dexter is one example. It uses four agents—planning, action, validation and answer generation—alongside routing that directs requests to the appropriate data source.
The advantage is a clean separation of responsibilities. Context remains isolated, and failures are easier to trace to a particular stage. The trade-off is higher token usage and additional coordination overhead.
This approach suits comprehensive analysis where quality matters more than minimizing cost.
Approach 3: Deep orchestrator with MCP
The third approach uses a central orchestrator to manage a dependency graph and execute tasks through standardized Model Context Protocol servers.
The orchestrator plans upfront, verifies the output of each step and replans only when something fails.
The AI Alliance Deep Research Agent for Finance, built with mcp-agent, follows this pattern. It combines upfront planning, a task dependency graph and deterministic code-based checks.
One of the project’s key findings was that deterministic validation performed more reliably than asking an LLM to verify factual claims. If a number must match, a schema must validate or a required field must exist, code can often check it more consistently than another model call.
The MCP approach allows compatible tools to be added through a standardized interface and has proved suitable for production use. Its main cost is the additional infrastructure required to configure and operate it.
It is best suited to systems where reliability, traceability and standardized tool access matter.
Which approach should you choose?
For learning and prototyping, begin with a single-agent ReAct loop. It exposes the mechanics without requiring a large supporting system.
When the research becomes broader, the context grows or the cost of a wrong answer increases, specialized agents provide clearer boundaries and stronger validation.
For production systems that depend on several tools, require traceable execution or need deterministic checks, an orchestrator and task graph offer the strongest foundation.
The architectures differ, but the underlying discipline does not: plan the work, retrieve the evidence, validate what came back and synthesize only what survives those checks.
This issue grew out of a chapter in Building AI Agents for Finance by Hanane Dupouy and Fayssal El Mofatiche. I adapted the authors’ explanation for a broader Agentic Engineering audience, but the four-phase loop and architectural thinking you’ve just read began with their work.
I’m linking to the book because useful ideas deserve a clear path back to the people who developed them, and because some of you may want to continue into the detailed financial examples and Python implementations that could not fit here.
That’s it for this one. We’ll pick up the conversation next week.
Until then, keep building.
