Multi-Agent Systems Need Replay Before More Agents

In a controlled study of 180 agent configurations, every multi-agent design tested on a sequential planning benchmark performed worse than the single-agent baseline. The penalty ranged from 39% to 70%.

On a parallel financial-reasoning benchmark, the opposite happened: a centralized multi-agent system improved performance by 80.9%.

Both results come from the same Google Research study. That is the point. Multi-agent is not an upgrade tier. It is a task-dependent architecture with a coordination tax.

Yet teams still reach for more agents when one agent becomes hard to debug. A planner gets a researcher. The researcher gets a critic. The critic gets a verifier. Soon the system has five transcripts, six handoffs, three retry loops, and no defensible answer to the incident question:

Which agent introduced the error, and can you reproduce the run without touching production again?

If the answer is no, stop spawning agents.

First make one agent replayable. Then prove that an additional lane improves a cost-normalized outcome and does not erase causal accountability.

This is not an argument against multi-agent systems. It is an argument against multiplying a system you cannot reproduce.

More agents create a larger causal graph

The optimistic mental model is division of labor:

one difficult task
  -> several focused agents
  -> better final answer

The production reality is a causal graph:

parent decision
  -> task decomposition
  -> child context compilation
  -> tool selection
  -> tool results
  -> child artifact
  -> handoff compression
  -> parent acceptance
  -> final decision
  -> external effect

Every new agent adds at least one context boundary, one output contract, one budget, one evaluator, and one place where uncertainty can be compressed into unjustified confidence.

The MAST failure taxonomy makes this concrete. Its authors analyzed multi-agent traces across seven frameworks and released more than 1,600 annotated traces. They identified 14 failure modes in three broad groups: system-design failures, inter-agent misalignment, and task-verification failures.

These are not just model errors. They are architecture errors:

Adding a critic does not automatically solve these failures. The critic is another agent unless its checks are attached to typed evidence, deterministic policy, and a replayable trace.

The benchmark result that should change architecture reviews

The Google study compared a single-agent system with independent, centralized, decentralized, and hybrid multi-agent designs across financial reasoning, web navigation, planning, and tool-use tasks.

Three results matter for production teams:

1. Task shape dominated the outcome. Centralized coordination improved a parallelizable financial task by 80.9%, while every multi-agent variant degraded sequential planning by 39–70%.
2. Tool density raised the coordination tax. As the number of tools increased, the overhead of coordinating agents increased disproportionately.
3. Architecture changed error propagation. Independent agents amplified errors by up to 17.2×. A centralized orchestrator contained amplification to 4.4×—better, but not zero.

Anthropic’s production experience points in the same direction from the other side. Its multi-agent research system outperformed a single lead model by 90.2% on an internal breadth-first research evaluation. But Anthropic also reports that its multi-agent systems use about 15× as many tokens as chat interactions, and warns that tasks with shared context or many dependencies are a poor fit.

Those numbers are not directly comparable: the benchmarks, models, baselines, and token accounting differ. They should not be collapsed into one universal performance claim. Together they support a disciplined conclusion:

Use multiple agents when independent parallel work creates enough measurable value to pay for coordination, verification, and replay.

A 2026 fixed-budget preprint adds another useful warning. Across three model families, single agents matched or outperformed several multi-agent designs on multi-hop reasoning when reasoning-token budgets were held constant. The authors argue that some reported multi-agent gains can come from spending more compute, not from better architecture.

So the comparison that matters is not multi-agent versus single-agent at unequal effort. It is:

task success + safety + latency
--------------------------------
total model, tool, review, and recovery cost

If the multi-agent design cannot win that comparison on a representative dataset, it has not earned production.

Replay is the prerequisite, not the cleanup step

Replay means more than re-running a prompt and hoping for a similar answer.

For a single-agent run, the contract is:

Given a trace_id, reconstruct the expected DecisionRecord from pinned inputs and recorded tool transcripts without re-executing external effects.

That requires:

Replay runs the decision path against recorded results. It does not send the email again, recreate the quote, issue the refund, or call a changing remote service.

Once one agent satisfies this contract, a multi-agent run becomes a composition of replayable branches:

parent trace
  -> child trace: contract_review
  -> child trace: usage_analysis
  -> child trace: pricing
  -> parent acceptance decisions
  -> one final DecisionRecord

Each child has a declared input artifact and a typed output artifact. The parent records why it accepted, rejected, or retried that output. One trace graph connects the first decomposition decision to the final effect.

Without that structure, a multi-agent trace is just a folder of conversations.

A plausible proposal, caused by one missing clause

Consider an enterprise renewal system with four specialist lanes:

• contract review extracts renewal terms;
• usage analysis calculates adoption and expansion signals;
• pricing produces package and discount options;
• risk review checks legal, finance, and churn exposure.

The parent orchestrator assembles a proposal.

The contract lane misses a non-standard renewal-price cap. It returns a well-formed summary, but the renewal_cap field is absent and there is no evidence reference for the pricing clause. The pricing lane treats the artifact as complete and recommends an increase. The risk lane verifies that the proposal matches the typed schema, not that every material term is grounded. The parent sees agreement across three lanes and approves a polished, wrong proposal.

With ordinary logs, the incident review becomes a blame exercise. The contract reviewer says the clause was not prominent. Pricing says it received valid input. Risk says the schema passed. The parent transcript says three specialists agreed.

With branch replay, the review asks a better question: what is the first artifact that differs from the expected run?

The answer is the contract artifact. Its evidence-coverage evaluator should have returned insufficient_evidence, which should have prevented parent acceptance. The team can replay that child branch against the recorded contract retrieval, correct the evaluator, and verify that the parent now rejects the proposal—all without repeating the external effect.

That is why replay has to exist before the fifth agent. It converts coordination failure from a narrative into a localized, testable diff.

Choose the runtime shape from the task

Do not start an architecture review by deciding how many agents to use. Start with sequential dependency, tool density, shared context, and the cost of a wrong answer.

Centralized orchestration is not automatically safe. It is simply the design with a place to enforce admission, reject weak artifacts, contain authority, and write one final record.

The parent must own:

• task decomposition;
• child budgets and deadlines;
• lane-specific Context Packs and tool permissions;
• acceptance criteria for every child artifact;
• retries and termination;
• the final DecisionRecord;
• every externally visible side effect.

Workers may research, calculate, classify, and propose. They should not silently convert their proposal into final state.

The replay contract before spawn

The following is illustrative application configuration, not a normative ContextOS runtime schema:

parent_run:
  trace_id: trace_renewal_042
  task: renewal.prepare_proposal
  final_decision_owner: renewal_orchestrator
 
replay:
  pinned:
    - run_context
    - context_pack
    - policy_bundle
    - model_profile
    - tool_manifest
  recorded:
    - tool_calls
    - tool_results
    - lane_artifacts
    - parent_acceptance_decisions
  reexecute_external_effects: false
 
lanes:
  - id: contract_review
    approval_mode: read_only
    allowed_tools: [contracts.read]
    output: contract_terms
    requires_evidence_refs: true
    evaluator: contract_term_coverage_v3
 
parent_acceptance:
  reject_when:
    - evidence_refs_missing
    - evaluator_failed
    - output_schema_invalid
    - lane_budget_exceeded

The important field is not lanes. It is parent_acceptance. A worker artifact is a claim until the parent proves that it satisfies the lane contract.

The 24-point multi-agent admission scorecard

Score each control 0, 1, or 2:

• 0 — absent or asserted without evidence;
• 1 — partially implemented or tested only on a happy path;
• 2 — implemented, measured on a representative dataset, and visible in traces.

Interpret the score conservatively:

Five conditions override the total and stop the release:

1. The single-agent baseline cannot be replayed.
2. A worker can mutate final state without parent acceptance.
3. No single runtime owns the final DecisionRecord.
4. Workers share an unrestricted tool pool or ambient credentials.
5. The team has no cost-normalized single-agent comparison.

Download the multi-agent replay-readiness checklist. It turns the scorecard into a reviewable starter for baselines, branch replay, lane boundaries, parent acceptance, release gates, and rollback. The YAML is an implementation aid, not a new ContextOS runtime contract.

Roll out one replayable lane at a time

A credible rollout is deliberately boring:

1. Prove one agent. Pin inputs, record tool envelopes, emit the DecisionRecord, and pass replay drills.
2. Measure the task. Label which cases are parallelizable and which require shared sequential context.
3. Shadow one lane. Give it read-only tools and compare its artifact with the single-agent path.
4. Add a lane evaluator. Reject missing evidence, incomplete coverage, and budget violations before synthesis.
5. Replay the branch. Confirm that a failed child run can be isolated without re-running live effects.
6. Prove net value. Compare task success, safety, latency, and total cost at equal budgets.
7. Expand carefully. Add the next lane only if it has a distinct context, authority, tool surface, or scorecard.

Do not launch five agents and then try to discover which one adds value. That experiment has too many moving parts to produce a causal answer.

The architecture review question

The seductive question is:

Which multi-agent framework should we use?

The production question is:

What property of this task justifies another causal branch, and how will we replay that branch when it fails?

If the task is parallel, the outputs independently verifiable, and the value high enough, a multi-agent system can be the right architecture. The research supports that.

But an agent you cannot replay is already an incident you cannot explain. Multiplying it does not create a team. It creates a larger mystery.

Replay one. Measure one. Then earn the right to spawn the next.

Research base

• Google Research: Towards a science of scaling agent systems
• Anthropic: How we built our multi-agent research system
• Why Do Multi-Agent LLM Systems Fail?
• Single-Agent LLMs Outperform Multi-Agent Systems on Multi-Hop Reasoning Under Equal Thinking Token Budgets

What to read next

• Replay Harness in Code
• The Control Tower Pattern
• Trace Review Is the Agent Debugger
• Run the Agent Harness Audit