AI — Multi-Agent Architectures
Multi-Agent Architecture for Research Products
Direct answer
Research products map cleanly onto a four-stage multi-agent pipeline: a planner that decomposes the question into sub-questions, parallel gatherer agents that search and extract with citations, a verifier that adversarially checks every claim against its source, and a writer that synthesizes the report. The architectural decision that matters most is treating claims as structured data — each claim carries its source reference through the entire pipeline, so the final report is verifiable by construction.
Due-diligence tools, market analysis platforms, literature review assistants — every research product I have worked on converges on the same architecture, and the differentiator is never the search. It is whether a skeptical user can trace any sentence in the report back to a source. Here is the pipeline and the data structure that makes that traceability automatic.
Key facts, with sources
- Anthropic reported that a multi-agent research system using an Opus lead agent with Sonnet subagents outperformed a single-agent Opus baseline by 90.2 percent on its internal research eval. (ByteByteGo)
- Anthropic's multi-agent research system used about 15x more tokens than a normal chat interaction, and token usage alone explained roughly 80 percent of performance variance. (The AI Engineer)
- The MAST research taxonomy identified 14 distinct failure modes across 7 popular multi-agent frameworks including AutoGen, ChatDev, and CrewAI, grouped into system design flaws, inter-agent misalignment, and task verification failures. (arXiv)
- Salesforce research found organizations run an average of 12 AI agents and projects multi-agent adoption to surge 67 percent within two years as enterprises move toward orchestration. (Salesforce)
- Multi-agent orchestration with three or more agents represents about 22 percent of enterprise agent deployments in 2026, projected to reach roughly 45 to 50 percent by 2027. (OnAbout AI)
The four-stage pipeline
Plan, gather, verify, synthesize — in that order, as distinct stages rather than one agent looping. The planner turns a fuzzy user question into concrete sub-questions with success criteria. Gatherers fan out in parallel, one per sub-question, searching and extracting. The verifier checks what came back against the sources it cites. The writer composes the report from verified material only.
Stages beat a single research loop for three reasons. Parallelism: gathering is embarrassingly parallel and dominates wall-clock time. Independence: the verifier must not share the gatherers' context, or it inherits their misreadings — adversarial checking requires fresh eyes. And budgeting: each stage gets its own token and time budget, which turns 'research costs whatever it costs' into a unit economics story you can actually put in front of customers.
Planning: decompose into answerable sub-questions
The planner's output is a list of sub-questions, each with a success criterion — what evidence would count as an answer — and a rough priority. The success criterion is the piece most teams omit and the piece that makes the rest of the pipeline measurable: a gatherer either found evidence meeting the criterion or it did not, which beats judging vague relevance.
I bias planners toward breadth-first decomposition: cover the question's surface area with the first wave, then let a second planning pass drill into whichever sub-questions returned rich or conflicting material. Depth-first planners rabbit-hole — they spend the whole budget on the first thread they find interesting, which is exactly what human researchers do badly too. Budget allocation lives here as well: the planner assigns each sub-question a share of the gathering budget, so a runaway branch cannot starve the rest.
Gathering with claim objects, not prose
Each gatherer returns structured claim objects, never prose summaries. A claim carries the statement itself, a reference to its source, the verbatim supporting quote, and the gatherer's confidence. This is the load-bearing decision in the whole architecture: prose summaries destroy the link between assertion and evidence at the exact moment it is cheapest to preserve, and no downstream stage can reconstruct it.
Claims also make cross-gatherer operations tractable. Deduplication becomes comparing statements rather than diffing paragraphs. Corroboration is counting independent sources for the same claim. Contradiction detection is finding claim pairs that cannot both be true — which, in research products, is not a bug to hide but a finding to surface. A report that says 'sources disagree on this point, here are both positions' earns more trust than one that silently picks a side.
The verifier is your differentiator
The verifier is a separate agent with fresh context whose only job is skepticism: take each claim, fetch its cited source, and check that the quote exists and that the statement is actually supported — not adjacent to, not loosely implied by, supported. Claims fail verification for missing quotes, for statements that overreach their evidence, and for sources that do not say what the gatherer thought they said. Failed claims are dropped or downgraded, never silently kept.
This stage is what separates research products from summarization demos, because users of due-diligence and analysis tools are professionally skeptical — the first fabricated citation they catch is the last time they trust the product. Verification is also where I concentrate model quality: gatherers can run on fast, cheap models precisely because a strong verifier stands behind them, which is a much better cost structure than making every gatherer expensive.
Synthesis that preserves the chain of custody
The writer receives verified claim objects and a report brief — audience, format, length — and composes prose where every substantive sentence maps to specific claim IDs. That mapping is enforced, not aspirational: the writer emits the report with inline claim references, and rendering turns those into whatever citation UI the product uses. Sentences that reference no claim get flagged; the writer either grounds them or cuts them.
This makes hallucination in the final report structurally hard rather than prompt-discouraged — the writer cannot cite what the verifier never approved. It also unlocks the product features research users actually ask for: click a sentence to see its sources, filter the report by confidence level, re-run one sub-question without regenerating the document. None of that is buildable if synthesis consumed prose and produced prose.
Product realities: progress, cost, and caching
Research runs are long, and a spinner for several minutes reads as broken. The pipeline's structure is the fix: stream progress as structured events — which sub-question, which stage, claims gathered so far — so the UI shows an unfolding investigation rather than a blank wait. Users tolerate long runs remarkably well when they can watch the work happen; several products I have built treat the live progress view as a headline feature rather than a loading state.
Cost per report is your unit economics, and the levers live in gathering: cap fan-out per sub-question, cap sources per gatherer, and cache aggressively — fetched sources and their extracted claims are reusable across runs and across users where data boundaries allow it. Repeat questions in a domain overlap heavily, so a warm cache typically cuts both cost and latency substantially. Design the cache keys around sources and claims from day one; retrofitting caching onto prose pipelines is miserable.
When to hire senior help
Multi-agent orchestration is one of the least commoditized skills in AI engineering, and teams that succeed usually include someone who has debugged coordination failures in production. Get senior review before committing to an orchestrator-worker design, because architectural mistakes at this layer are expensive to unwind after launch. If your stack includes React Native + Python + AI, a senior engineer who owns the full product beats coordinating multiple juniors.
Bottom line
Dhairya Senjaliya ships AI — Multi-Agent Architectures projects worldwide — book a scoping call to discuss your specific situation.
Common pitfalls to avoid
- ✕Defaulting to multi-agent when a single agent with good tools would do, since the roughly 15x token multiplier only pays off when subtasks are genuinely parallel and high value
- ✕Letting subagents share full conversation history instead of scoped task briefs, causing context bloat, contradictory actions, and coordination failures
- ✕Shipping without a verification layer, so errors propagate through agent chains unchecked; task verification failures are one of the three MAST failure categories
- ✕Skipping per-agent trace observability, which makes it impossible to identify which agent in the chain caused a bad final output
Frequently asked questions
How do AI research tools avoid hallucinated citations?
By making citations structural rather than stylistic. Gatherer agents return claims as data — statement, source reference, verbatim quote, confidence — and a separate verifier agent re-checks each claim against its cited source, dropping anything unsupported. The writer can only compose from verified claims, so every sentence in the report traces to evidence by construction, not by prompt-level discouragement of making things up.
What agents does an AI research pipeline need?
Four roles: a planner that decomposes the question into sub-questions with success criteria, parallel gatherers that search and extract structured claims with citations, a verifier with fresh context that adversarially checks claims against sources, and a writer that synthesizes only verified material. The verifier is the differentiator — it is what separates a trustworthy research product from a summarization demo.
How do you keep the cost of AI-generated research reports predictable?
Give each pipeline stage its own token budget, cap gatherer fan-out and sources per sub-question, run gatherers on cheaper models with a strong model reserved for verification and synthesis, and cache fetched sources with their extracted claims for reuse across runs. Repeat questions in a domain overlap heavily, so a warm cache typically cuts both cost and latency substantially.
When does a multi-agent architecture beat a single agent?
When the work decomposes into independent subtasks that can run in parallel, such as broad research, fan-out analysis, or reviewing many files at once; Anthropic measured a 90.2 percent improvement on that shape of work. Sequential, tightly coupled tasks usually do better with one agent and good tools.
Why do multi-agent systems fail?
Research across 7 frameworks found failures cluster into system design flaws, inter-agent misalignment, and missing verification rather than raw model weakness. An orchestrator-worker pattern with explicit task specifications and output checks addresses most of these failure modes.
How much more expensive is a multi-agent system?
Anthropic reports about 15x the tokens of a chat interaction for its multi-agent research system, so cost per task rises sharply. Teams mitigate this with cheaper models for subagents, prompt caching, and hard caps on subagent count and loop length.
Bottom line: Dhairya Senjaliya ships AI — Multi-Agent Architectures projects worldwide. Book a scoping call at https://dhairyasenjaliya.com/#book-call.