When Does Multi-Agent Beat One Strong Agent?

Multi-agent systems are appealing for the same reason human teams are appealing: divide the work, assign specialists, run tasks in parallel and review one another.

But adding agents does not automatically add intelligence. It adds:

more model calls;
more context windows;
more communication;
more places for information to be lost;
more coordination logic;
more cost and latency.

The right question is therefore not:

How do I build a multi-agent system?

It is:

What limitation prevents one capable agent from succeeding, and does another agent solve that limitation better than a cheaper change?

This article derives multi-agent architecture from that question and designs a controlled experiment to test it.

1. Begin with one capable agent

Assume one agent already has:

a strong model;
paper-search and web tools;
repository-search and code-execution tools;
a structured research plan;
persistent task state;
claim-level citations;
verification steps;
enough context for an ordinary research task.

Its loop is:

understand goal
→ make plan
→ use tools
→ update evidence
→ verify claims
→ write answer

This is the baseline. A second prompt persona is not yet justified.

Before adding an agent, try the cheaper fixes:

Improve the tools.
Retrieve less but more relevant context.
Split the workflow into explicit stages.
Store intermediate results as structured artifacts.
Add deterministic validation.
Give the agent a larger but controlled budget.

If one agent succeeds after these changes, multiple agents were not the missing mechanism.

2. What counts as a multi-agent system?

A single agent may plan, reflect, call many tools and execute several workflow stages. It is still a single-agent system if one reasoning process owns the complete loop.

A multi-agent system has multiple model-controlled reasoning processes with separate local contexts that communicate through messages, shared state or an orchestrator.

The important difference is not the number of role names. It is the number of independent decision-making contexts and the boundaries between them.

Single agent:
one reasoning context → many tools and stages

Multi-agent:
separate reasoning contexts → communication boundary → combined result

That boundary can create useful isolation. It can also destroy information.

3. Deriving each reason to add an agent

3.1 Context isolation

Suppose one research task requires reading twenty papers, five repositories and several benchmark reports. Placing everything into one context creates three problems:

important details compete for attention;
unrelated evidence becomes mixed;
early conclusions anchor later searches.

First test retrieval, summarization and artifact-based state. If the agent still cannot preserve enough detail, isolated contexts may help.

A paper researcher can read papers without repository logs consuming its context. A repository researcher can inspect code without carrying every academic argument. Each returns a compact evidence packet.

Expected benefit:

More useful source material can be processed without filling one reasoning context with every raw observation.

Risk:

Compression at the agent boundary may omit the exact fact the final answer needs.

Context isolation helps only when independent workers can return loss-aware summaries containing claims, evidence, uncertainty and source locations.

3.2 Tool isolation

A paper researcher needs scholarly search and PDF-reading tools. A repository researcher needs Git hosting, file search and code execution. Giving every tool to one agent increases tool-selection complexity and the chance of using the wrong source for a claim.

First test clearer tool descriptions and workflow stages. Add tool-specialized agents only if restricted tool surfaces measurably improve selection or reduce errors.

Expected benefit:

Each worker sees a smaller, more relevant action space.

Tool isolation is operational specialization. Merely telling identical agents to “think like experts” is much weaker evidence of specialization.

3.3 Permission isolation

Some roles only need read access. Others may execute untrusted repository code in a sandbox. A synthesizer should not need code-execution or external-write permissions.

This is a security boundary, not a prompting technique:

Role	Minimum permission
Paper researcher	Read papers and public metadata
Repository researcher	Read repository; sandboxed execution
Benchmark analyst	Read evidence; run local calculations
Evidence verifier	Read sources; no source mutation
Synthesizer	Read verified artifacts only

Expected benefit:

A compromised or mistaken worker has a smaller blast radius.

If all “agents” share the same unrestricted runtime and credentials, role prompts do not provide permission isolation.

3.4 Specialization

Specialization is justified when a worker has at least one real difference:

different tools;
different permissions;
different source context;
a different model with a demonstrated strength;
a distinct output contract;
a separately evaluated objective.

Different system prompts alone may help, but a single strong agent can often execute the same prompted roles sequentially. Research across seven benchmarks found that a single agent could match homogeneous multi-agent workflows while benefiting from shared cache reuse; this makes a strong sequential baseline essential (Xu et al., 2026).

3.5 Parallel work

Parallelism is useful when branches are both expensive and substantially independent:

papers ─────┐
repositories ├─→ verification → synthesis
benchmarks ─┘

It reduces wall-clock time only when:

workers can start from the same task specification;
one branch does not need another branch's answer;
tools support concurrent use;
merge and verification time do not erase the gain.

Parallelism does not reduce total work. It usually spends more compute to finish sooner.

Anthropic reports that its multi-agent research architecture worked best on breadth-first queries with independent directions. It also reported a 90.2% improvement over its single-agent configuration on an internal research evaluation, while noting that the system used far more tokens and was a poor fit for highly dependent work (Anthropic, 2025).

This is evidence that parallel context can help a particular research regime. It is not proof that multi-agent systems are universally superior or superior under equal budgets.

4. Coordination patterns

Choose the simplest topology that matches the ownership problem.

Router

A router classifies the request and selects one specialist.

request → router → one specialist → answer

Use it when tasks belong to distinct domains and only one domain is needed. Routing does not combine specialists.

Main failure: wrong classification sends the task to an incapable worker.

Supervisor-worker

A supervisor owns the goal, decomposes work, assigns workers and combines their results.

request → supervisor → workers → supervisor → answer

Use it when several bounded subtasks contribute to one final result. The supervisor must maintain the global plan and remain accountable for completion.

Main failures:

vague assignments;
missing branches;
duplicate work;
accepting worker output without verification;
losing evidence during aggregation.

Handoff

During a handoff, one agent transfers ownership of the next interaction to another.

Use it when a specialist should take over, such as moving from general triage to a security specialist. Do not use it when the original coordinator must merge several parallel results.

OpenAI distinguishes handoffs, where the specialist takes control, from manager-style “agents as tools,” where the manager retains ownership of the final response (OpenAI orchestration guide).

Main failure: no agent retains a complete view of the original goal.

Parallel specialists

Several workers receive non-overlapping assignments and run concurrently. A later stage merges their artifacts.

Use it for broad research, independent codebase modules or source-type partitions.

Main failure: artificial independence. Workers may unknowingly depend on definitions or assumptions chosen by another worker.

Debate and judge

Several agents independently propose or critique answers; a judge selects or synthesizes the result.

Use it when:

plausible alternatives genuinely exist;
errors are detectable through criticism;
diverse models or evidence can produce independent mistakes;
the judge has a better decision signal than simple majority vote.

Do not use debate merely to generate more prose. Agents sharing the same model, prompt and evidence often share the same blind spot.

A heterogeneous orchestration study found that revealing authorship increased self-voting and ties, while visible votes encouraged herding and sometimes premature consensus (Tian et al., 2025). Coordination rules change the result; “let the agents discuss” is not a sufficient protocol.

Blackboard

Agents read and write to shared state rather than exchanging long point-to-point conversations.

                ┌──────────────┐
worker A ──────→│              │←────── worker B
verifier ──────→│  blackboard  │←────── coordinator
                └──────────────┘

Use it when work is asynchronous, evidence must persist and several roles need the same current state.

Benefits:

less repeated context;
visible task ownership;
provenance for every claim;
easier resumption and auditing.

Risks:

stale or conflicting updates;
one incorrect claim contaminating downstream work;
uncontrolled growth;
unclear authority to overwrite state.

The solution is not a shared chat transcript. It is schema-validated state with ownership, versions and provenance.

5. Communication and shared-state contracts

Natural-language messages are flexible but hard to validate. Use structured artifacts for coordination and reserve prose for reasoning that does not fit the schema.

Task ledger

{
  "task_id": "repo-03",
  "objective": "Verify how the repository evaluates retrieval quality",
  "owner": "repository_researcher",
  "status": "in_progress",
  "dependencies": [],
  "deliverable": "evidence_packet",
  "deadline_ms": 120000,
  "version": 2
}

Only the coordinator creates assignments. Only the current owner performs the task. Reassignment increments the version and invalidates late results from the previous owner.

Evidence packet

{
  "task_id": "repo-03",
  "claims": [
    {
      "claim": "The project reports recall at k.",
      "source_type": "repository",
      "source": "https://example.com/repo/path",
      "locator": "src/eval.py:42-58",
      "support": "direct",
      "confidence": 0.94,
      "limitations": ["Metric inputs are generated from a sample dataset."]
    }
  ],
  "unresolved_questions": [],
  "failed_searches": [],
  "token_usage": 3200,
  "tool_calls": 8
}

A useful message says not only what was found, but also:

where it was found;
whether the source directly supports the claim;
what remains uncertain;
what search was attempted and failed.

Claim registry

The blackboard stores each final claim with:

a stable claim ID;
supporting and contradicting evidence;
source independence;
verification status;
the agent that introduced it;
the verifier's decision;
a complete revision history.

This prevents the synthesizer from treating repeated copies of one source as independent confirmation.

6. Ownership and coordination failures

Duplicate work

Cause:

assignments overlap;
agents cannot see active ownership;
the coordinator delegates vague topics instead of testable questions.

Control:

one owner per task;
explicit inclusion and exclusion boundaries;
a searchable task ledger;
content fingerprints for sources and claims;
coordinator approval before expanding scope.

Duplication is not always waste. Two independent investigations are valuable when deliberately requested for replication. Label this as redundancy, give the agents isolated evidence and measure agreement.

Conflicting conclusions

Never ask the synthesizer to “pick the better answer” without evidence.

Use this sequence:

Normalize both conclusions into claim form.
Compare the cited sources and their dates.
Check whether the agents used different definitions or scopes.
Prefer direct evidence over inference.
Run a targeted verification task.
Preserve unresolved disagreement in the final answer.

The verifier resolves evidence conflicts. The coordinator resolves task-scope conflicts. The synthesizer communicates any uncertainty that remains.

Cascading errors

One worker makes an unsupported claim. The coordinator treats it as fact. Other workers build on it. The synthesizer writes a confident conclusion.

Controls:

claims are unverified by default;
downstream agents can use unverified claims only as search leads;
the verifier must inspect the original source;
synthesis reads verified claims and explicitly marked uncertainty;
evidence provenance survives every transformation.

Coordination cost

Coordination cost includes:

task decomposition tokens;
repeated instructions and source context;
worker status messages;
serialization and parsing;
conflict resolution;
merge and verification;
idle time caused by dependencies;
retries after partial failures.

One study identified fourteen recurring failure modes across multi-agent traces, grouped around specification, inter-agent alignment and verification (Cemri et al., 2025). Another communication study reduced tokens by pruning redundant messages while maintaining comparable results in its tested settings, showing that communication itself is a cost surface to optimize (Zhang et al., 2024).

7. Practical project: a technical-research system

The system answers questions such as:

Which open-source agent-evaluation framework gives the strongest support for trajectory-level evaluation, and what evidence supports that conclusion?

Architecture

Use a supervisor-worker system with a structured blackboard.

User
  ↓
Coordinator
  ├─ Paper researcher ───────┐
  ├─ Repository researcher ──┼─→ Evidence verifier → Final synthesizer
  └─ Benchmark analyst ──────┘

Coordinator

Owns:

the user's question;
the acceptance criteria;
task decomposition;
task ledger;
budget allocation;
cancellation and retry decisions;
completeness of the final workflow.

Does not:

perform every search itself;
silently rewrite worker findings;
approve its own evidence.

Paper researcher

Owns:

primary papers;
study design;
reported results;
limitations and threats to validity;
exact source locations.

Boundary:

It may report what a paper claims, but cannot infer that repository code implements the paper faithfully.

Repository researcher

Owns:

code paths;
configuration defaults;
evaluation implementation;
release state;
reproducibility instructions;
sandboxed execution observations.

Boundary:

It may describe what the code does, but cannot treat a README claim as experimental proof.

Benchmark analyst

Owns:

benchmark definitions;
metric comparability;
dataset leakage risks;
aggregation calculations;
uncertainty and statistical tests;
normalization of reported results.

Boundary:

It cannot combine scores that use incompatible datasets, judges, prompts or budgets without labelling the comparison invalid.

Evidence verifier

Owns:

opening original sources;
claim-to-source entailment;
citation correctness;
source independence;
contradiction detection;
verified, rejected and unresolved statuses.

Boundary:

It does not improve the narrative. It decides whether evidence supports each claim.

Final synthesizer

Owns:

a clear answer to the user;
integration of verified evidence;
calibrated uncertainty;
limitations and counter-evidence.

Boundary:

It cannot introduce a factual claim that is absent from the verified claim registry.

Why six roles?

Each role must survive an ablation test:

Candidate role	Keep it only if
Coordinator	Decomposition and budget control improve completion
Paper researcher	Isolated scholarly context improves paper coverage or accuracy
Repository researcher	Code-specific tools and sandboxing improve implementation evidence
Benchmark analyst	Metric normalization prevents invalid comparisons
Evidence verifier	Independent source checking reduces unsupported claims
Final synthesizer	Separating evidence approval from writing improves clarity without adding claims

If a role provides no measurable benefit, merge it into the nearest owner. For example, simple tasks may combine coordinator and synthesizer, or paper research and benchmark analysis.

Execution protocol

Coordinator converts the request into acceptance criteria.
Coordinator creates non-overlapping research tasks.
Three research workers run in parallel.
Each writes an evidence packet, not a narrative report.
Coordinator checks task completion, schema validity and missing branches.
Verifier opens original sources and updates the claim registry.
Coordinator issues targeted follow-ups for rejected or contradictory claims.
Synthesizer receives only verified claims, unresolved conflicts and the user goal.
Deterministic checks reject uncited factual claims.
The run exports answer, trace, costs and failure labels.

Use stopping rules:

maximum tokens and tool calls per worker;
maximum one scope-expansion request per worker;
maximum one retry for a failed task unless the coordinator releases more budget;
cancellation when expected remaining value falls below expected remaining cost.

8. Build the single-agent baseline

The baseline is not a one-shot prompt. It is the strongest reasonable single-agent design.

Give it:

the same model family;
access to all equivalent research tools;
the same acceptance criteria;
the same evidence-packet and claim-registry schemas;
the same verification checklist;
persistent artifact state;
the same maximum budget.

It executes the same logical stages sequentially:

plan
→ paper research
→ repository research
→ benchmark analysis
→ evidence verification
→ synthesis

This isolates the architectural variable:

Does separating reasoning into communicating agents help, or was the useful part simply workflow decomposition?

Without this baseline, a multi-agent experiment compares an engineered system against an intentionally weak prompt.

9. The equal-budget experiment

Result status

This project experiment has not yet been run. The following section is a pre-registered protocol and results template. No numbers should be inserted until they come from saved traces.

Published work already gives mixed evidence:

multi-agent research can improve broad, parallel information gathering when allowed substantially more computation (Anthropic, 2025);
homogeneous multi-agent workflows can sometimes be reproduced more efficiently by one sequential agent (Xu et al., 2026);
on multi-hop reasoning, single agents matched or outperformed several multi-agent designs when reasoning-token budgets were held equal (Tran and Kiela, 2026);
multi-agent failures frequently arise from specification, alignment between agents and weak verification (Cemri et al., 2025).

Our experiment tests which regime this technical-research system occupies.

Task set

Use at least 30 tasks, frozen before running either system:

10 narrow tasks with one dominant source type;
10 breadth-first tasks requiring papers, repositories and benchmarks;
10 dependency-heavy tasks where findings must be integrated sequentially.

For every category, include easy, medium and hard tasks. Write a reference rubric rather than a single reference answer, because technical research may have several valid conclusions.

Two fair comparisons

A. Architecture-controlled comparison

Hold constant:

model and version;
total input, output and reasoning-token allowance;
total tool-call allowance;
accessible sources;
task timeout;
retry budget;
evaluation rubric.

This tests information efficiency under equal compute.

B. Production comparison

Optimize each architecture independently, then hold constant:

maximum dollar cost per task;
source access;
quality rubric;
safety and permission constraints.

This tests which system delivers more value for the same money. It allows the multi-agent system to use cheaper workers if that is part of its real design.

Do not call a comparison “equal budget” if only the final-answer tokens are equal. Count coordinator calls, worker prompts, tool outputs, retries, judge calls and synthesis.

Metrics

Task completion

Fraction of rubric requirements satisfied:

completion = satisfied weighted requirements / all weighted requirements

Use deterministic checks where possible and blinded human or model grading for semantic requirements.

Evidence quality

Measure claims, not writing style:

evidence precision = supported factual claims / checked factual claims
citation validity = citations that support the attached claim / checked citations
primary-source rate = claims backed by primary sources / evidence-bearing claims

Coverage

coverage = required evidence dimensions found / required dimensions

Dimensions may include paper evidence, implementation evidence, benchmark comparability, limitations and counter-evidence.

Contradictions

Count:

contradictions inside the final answer;
final claims contradicted by cited sources;
worker conflicts left unresolved;
conflicts hidden during synthesis.

Tool usage

Record calls by tool, successful calls, repeated calls, unique sources and calls that contributed to a verified final claim.

useful-tool rate = contributing tool calls / total tool calls

Latency

Record end-to-end wall time and stage time. Report median, p90 and p95. Parallel workers may reduce wall time even while increasing total compute.

Token and dollar cost

Count every model invocation:

token cost = Σ(input tokens + cached tokens + reasoning tokens + output tokens)

dollar cost = Σ(tokens by model and price class) + tool or infrastructure cost

Store model pricing with the run because prices change.

Coordination failures

Label trace events:

duplicate assignment;
unowned task;
stale result;
malformed message;
missing dependency;
lost evidence;
premature synthesis;
conflict not escalated;
cascading unsupported claim;
unnecessary agent invocation.

Report failures per task and the percentage that change the final answer.

Success per dollar

First define one quality score:

quality =
  0.30 × completion
+ 0.30 × evidence quality
+ 0.20 × coverage
+ 0.10 × contradiction score
+ 0.10 × citation validity

Normalize every component to [0, 1]. Freeze weights before the experiment.

success per dollar = quality / dollar cost

Also report each component separately. One composite number can hide a serious failure, such as high coverage with fabricated citations.

Experimental procedure

Freeze tasks, rubrics, budgets, prompts and model versions.
Run both systems on every task with matched randomization conditions.
Use multiple runs per task because agent behavior is stochastic.
Save complete traces and artifacts.
Blind evaluators to the architecture.
Apply deterministic citation and schema checks first.
Grade remaining semantic criteria.
Compare paired task results.
Use bootstrap confidence intervals for differences in quality, cost and latency.
Inspect traces before explaining why one architecture won.

Pre-registered decision rule

Example rule:

Retain the multi-agent system for a task category only if:

its mean quality is at least 0.05 higher;
the 95% confidence interval for the quality difference excludes zero;
evidence precision does not decrease;
success per dollar is no worse than 10% below the single-agent baseline;
any accepted cost penalty is justified by a pre-declared latency or quality requirement.

For high-value research, you may accept lower success per dollar in exchange for a meaningful absolute quality gain. Declare that trade-off before seeing the results.

Results table

Fill this table only from collected traces:

Metric	Single agent	Multi-agent	Difference	95% CI	Winner
Task completion	TBD	TBD	TBD	TBD	TBD
Evidence quality	TBD	TBD	TBD	TBD	TBD
Coverage	TBD	TBD	TBD	TBD	TBD
Contradictions	TBD	TBD	TBD	TBD	TBD
Useful-tool rate	TBD	TBD	TBD	TBD	TBD
Median latency	TBD	TBD	TBD	TBD	TBD
Total tokens	TBD	TBD	TBD	TBD	TBD
Dollar cost	TBD	TBD	TBD	TBD	TBD
Coordination failures	N/A	TBD	TBD	TBD	TBD
Success per dollar	TBD	TBD	TBD	TBD	TBD

Failure-analysis table

Failure	Trace evidence	Final-answer impact	Control to test
Duplicate work	Two workers searched the same question and sources	Cost only / changed result	Stronger task boundaries
Lost evidence	Worker supplied support that disappeared during merge	Unsupported or incomplete claim	Claim registry with stable IDs
Cascading error	Unverified claim became another worker's premise	Incorrect conclusion	Verification gate
Conflicting conclusions	Workers used incompatible metric definitions	Invalid comparison	Benchmark normalization
Premature synthesis	Writer started before required tasks completed	Missing coverage	Completion gate
Herding	Later reviewer copied an earlier conclusion	False confidence	Independent first pass

These are observed categories from prior multi-agent research, but their frequency in this project remains to be measured.

10. When should agents be merged back into one?

Merge roles when:

the same model performs every role;
workers use the same tools and permissions;
subtasks are sequential rather than independent;
most messages repeat shared context;
verification cannot be separated from the same evidence and reasoning;
coordination failures offset coverage gains;
one agent with structured stages matches quality at lower cost;
parallelism does not improve end-to-end latency;
an agent exists only because its role name sounds useful.

The number of agents is not a maturity score. A good system may dynamically choose:

narrow task → one agent
broad independent research → parallel specialists
sensitive evidence → add independent verifier
highly coupled task → one agent with structured workflow

The best multi-agent controller may frequently decide not to create another agent.

11. Practical decision framework

Before adding agent N + 1, answer:

Limitation: What measured failure does the current system have?
Cheaper fix: Why are better tools, retrieval, state or workflow insufficient?
Mechanism: What does an isolated reasoning context add?
Boundary: What exactly does the new agent own?
Interface: What structured input and output cross the boundary?
Authority: Which tools and permissions does it receive?
Failure: How can communication make the system worse?
Evaluation: Which metric should improve?
Budget: What extra cost is allowed?
Ablation: What result would cause us to remove the agent?

If these questions do not have concrete answers, do not add the agent.

12. Mastery gate

You understand multi-agent systems when you can do the following without relying on role-name intuition.

Justify each additional agent

Given the technical-research project, explain why paper and repository research may need isolated contexts, but why coordinator and synthesizer may be merged for simple questions.

Choose a coordination pattern

Choose among router, handoff, supervisor-worker, parallel specialists, debate-and-judge and blackboard. State who owns the final result.

Design boundaries

For every role, specify:

context;
tools;
permissions;
task ownership;
input schema;
output schema;
stopping conditions.

Prevent duplication

Design a task ledger that distinguishes accidental duplicate work from intentional independent replication.

Resolve conflict

Given two agents with incompatible benchmark conclusions, trace the disagreement to sources, definitions, versions or calculations before selecting an answer.

Evaluate fairly

Build both:

a same-model, equal-token architecture comparison;
an equal-dollar production comparison.

Count all orchestration calls.

Identify reliability regressions

Recognize cases where multiple agents reduce reliability:

shared blind spots become false consensus;
communication compresses away decisive evidence;
a weak coordinator misroutes work;
one unsupported claim cascades across agents;
majority voting defeats a correct minority;
unclear ownership leaves required work unfinished.

Reconstruct the architecture

From a trace alone, identify:

the topology;
task owners;
shared state;
evidence flow;
verification boundary;
final-answer owner;
the exact coordination failure, if any.

Conclusion

Multiple agents are valuable when a task contains expensive, independent branches; when separate contexts preserve more useful information; when tool or permission boundaries reduce risk; or when genuinely different capabilities make independent errors.

They are harmful when the work is tightly coupled, when role prompts merely imitate specialization, when messages discard information, or when extra compute is mistaken for architectural intelligence.

The default should remain one strong agent with good tools, structured state and verification.

Add the minimum additional agent only after identifying a measurable limitation. Keep it only after an equal-budget experiment shows that the new boundary improves the outcome enough to pay for its coordination cost.

That is the standard:

Multi-agent is not better because it resembles a team. It is better only when the team produces more verified value per constrained unit of compute, time or money.