Why More Agents Can Make a System Worse

A multi-agent diagram can look sophisticated while making the underlying workflow slower, costlier and harder to control. Add an agent only when the new boundary has a job, contract and measurable advantage.

What can go wrong in a multi-agent system? More agents create more interfaces: work must be divided, context transferred, results reconciled, permissions separated, conflicts resolved and stopping decisions enforced. Each interface can introduce ambiguity, duplicate work, missing evidence, circular delegation, stale state, latency and cost. Start with one controlled workflow. Keep multiple agents only when independent specialization or parallel work improves an end-to-end measure enough to justify that coordination tax.

Agent count is not system capability

A single agent can already use several tools, follow a plan, preserve case context, ask for approval and complete a bounded job. Turning each step or tool into a named agent does not automatically add expertise. It often replaces an inspectable function call with another probabilistic conversation.

The relevant question is not “How many agents can we deploy?” It is “Which boundary improves the business outcome?” A useful boundary may isolate a distinct permission domain, a specialist evaluation set, a separate owner or a genuinely independent branch of work. If the proposed agents share the same objective, instructions, evidence, tools and authority, the split usually creates more coordination than capability.

This is consistent with current platform guidance. OpenAI's Agents SDK distinguishes a manager that retains ownership while calling specialists as tools from handoffs that transfer control to another specialist. It also notes that code-led orchestration is more predictable for speed, cost and performance. Those are architecture choices, not a requirement to build a cast of agents.

Research shows that failures are systemic

A 2025 multi-agent failure study introduced MAST after analyzing more than 1,600 execution traces across seven multi-agent frameworks. It identified 14 failure modes grouped into system-design issues, inter-agent misalignment and task verification. The useful lesson for an SME is not the exact benchmark result; it is that a capable model does not remove coordination, specification and termination failures.

Anthropic's production report reaches a similar operational conclusion from a system that did benefit from multiple agents. Parallel research worked well when branches were independent and the search space exceeded one context window. Yet the report also says tasks with shared context or many dependencies were a poor fit, and its multi-agent research system used about 15 times the tokens of ordinary chat interactions. That figure belongs to Anthropic's measured research setup, not a universal multiplier, but it makes the economic test unavoidable.

Seven ways more agents make a system worse

Ambiguous ownership

Two agents believe they own the same decision—or neither owns the accepted outcome.

First control: One accountable manager and one acceptance test.

Duplicated work

Specialists receive overlapping briefs and repeat searches, analysis or tool calls.

First control: Non-overlapping scopes and structured deliverables.

Context loss

A handoff carries the conclusion but drops evidence, constraints, customer state or rejected options.

First control: A typed handoff contract with source references.

Error amplification

A plausible mistake becomes trusted input and gains authority as agents repeat or summarize it.

First control: Independent verification against the system of record.

Circular delegation

Agents bounce work, critique one another indefinitely or reopen a completed branch.

First control: Turn budgets, terminal states and a deterministic stop rule.

Conflicting action

Parallel agents read stale state, make duplicate writes or attempt incompatible changes.

First control: Single writer, idempotency keys and state re-checks.

Coordination tax

Extra calls, repeated context and reconciliation add latency and cost without improving the result.

First control: Compare cost per accepted outcome with a simpler baseline.

Shuhaib's seven-mode failure map, synthesised from current multi-agent research and production architecture guidance. It is an operational checklist, not a benchmark.

1. Ambiguous ownership

Multi-agent systems often begin with personas—planner, researcher, reviewer, executor—before anyone defines who accepts the final result. A reviewer may identify a problem without authority to stop the executor. A manager may assume a specialist verified a claim when the specialist only gathered it. Activity is distributed; accountability disappears.

Assign one component to own the end-to-end outcome. Name the evidence it must inspect, the state it may change and the acceptance test it must pass. Specialists can advise or produce bounded artifacts, but the system needs one authoritative decision about completeness.

2. Duplicated work

Vague delegation causes agents to cover the same territory. Anthropic describes early research agents duplicating searches or pursuing mismatched time periods when the lead agent provided broad instructions. In a business workflow, duplication can be worse than wasted analysis: two agents may create the same customer record, contact the same lead or schedule the same payment.

Make scopes mutually exclusive where possible. Specify the question, source boundary, time range, required output schema and actions that are prohibited. For writes, use idempotency keys and a single-writer pattern rather than trusting agents to notice one another.

3. Context loss at handoff

A summary is compression, not the original case. It may omit which source supported a claim, which policy exception applied, which action was rejected or what the customer already said. The next agent then acts confidently on a partial representation.

Pass a typed handoff packet: objective, authoritative identifiers, current state, evidence references, decisions already made, unresolved questions, permitted next actions and escalation reason. Keep the system of record outside the model conversation and let the receiving agent re-read critical facts before acting.

4. Error amplification

Agent B may treat Agent A's output as evidence. Agent C then summarizes that result, making the claim sound more settled while moving it farther from its source. Agreement among agents is not independent verification when they share models, prompts, retrieved material or one another's conclusions.

Verify high-consequence facts against the original document or live system. Separate generation from acceptance: one agent may propose, but deterministic validation or an accountable reviewer decides whether the result can change an external state.

5. Circular delegation and weak termination

An agent asks a reviewer; the reviewer asks for more research; the researcher returns uncertainty; the manager reopens the task. Each local step looks reasonable, but the workflow has no terminal definition. Other loops arise when agents repeatedly critique and revise without a measurable acceptance threshold.

Define terminal states before launch: succeeded, rejected, escalated, failed safely and budget exhausted. Put limits on turns, tool calls, elapsed time and spend. When the limit is reached, preserve the case and hand it to a named owner instead of silently retrying.

6. Conflicting actions and stale state

Parallel agents can read the same starting state and both decide to act. One updates a record while another proceeds using the old value. This is a classic concurrency problem made harder by probabilistic planning and variable tool timing.

Use application controls: transactions where available, compare-and-set updates, idempotency keys, version checks and a final state read-back. Model instructions can reduce accidental conflict; they cannot replace concurrency control.

7. Hidden latency, cost and evaluation burden

Every specialist adds model calls, repeated context, tool calls, waiting and reconciliation. Parallelism can reduce wall-clock time for independent research, but it does not make the extra work free. Sequential dependencies may make a multi-agent run slower than one agent with tools.

Measure cost and time per accepted outcome, not per agent call. Include retries, failed branches, human review and correction. Then test the same representative cases against the simpler architecture. If the multi-agent version does not improve quality, speed, risk isolation or throughput materially, remove the agents that do not earn their place.

The architecture-smell checklist

Smell	What to require instead
Role names are clearer than responsibilities	Each agent needs explicit inputs, outputs, tools, prohibitions and a named evaluator.
Two agents can perform the same action	Choose one writer or enforce a deterministic authorization boundary.
The same context is copied everywhere	Keep one owner for shared state; pass only the evidence a specialist needs.
Agents talk to agents without a business-state change	Replace conversation with a structured function, rule or queue transition.
No one can explain why the run stopped	Define success, failure, escalation and budget-exhausted terminal states.
A specialist cannot fail independently	The boundary is probably not a real boundary; merge it into the manager.
Quality is measured per agent only	Evaluate the end-to-end outcome, reconciliation and final external state.
More agents are the proposed fix for weak prompts or tools	Repair tool contracts, context and deterministic controls first.

Three or more smells do not prove the architecture will fail. They do justify a simplification review before more prompts, agents and tools are added.

Simplify in this order

Write the business state machine. Define the start state, permitted transitions, external systems, accepted outcome and safe failure state.
Move stable decisions into code. Use rules for routing, validation, permissions, budgets and stop conditions where the logic is known.
Keep one outcome owner. Let a manager call tools and specialists, then reconcile evidence and own the final response or action.
Replace chat with contracts. Pass structured inputs and outputs instead of long conversational transcripts between components.
Limit writers. Centralize irreversible actions and require fresh-state checks, authorization and idempotency.
Evaluate the whole workflow. Test task success, evidence, policy, tool correctness, termination, latency, cost and final external state.
Remove one agent. Re-run the same evaluation set. If quality holds and operations improve, the removed boundary was not earning its cost.

The adjacent agentic workflow versus multi-agent guide helps choose the initial architecture. Use the observability framework to trace handoffs, tool calls and outcomes, and the agent evaluation playbook to compare a simpler baseline with the proposed multi-agent design.

When specialization is justified

Keep multiple agents when at least one durable boundary exists and the evidence supports it. The work may be highly parallel and information-heavy; specialists may require materially different tools or instructions; permissions or legal duties may need separation; one branch may need to fail without corrupting the case; or independent outputs may increase coverage enough to justify reconciliation.

Even then, prefer an orchestrator-worker design with a manager that owns the result. Give every specialist an objective, input contract, tool boundary, output schema, budget and failure state. Trace the entire run, including handoffs and tool actions. Multi-agent architecture is most defensible when the system can explain why each specialist exists.

Primary sources checked

Checked 11 September 2026. The seven-mode map, simplification order and architecture-smell checklist are Shuhaib's practitioner synthesis; the cited measurements remain specific to their source studies.

Reduce coordination before scaling it

Simplify one agent workflow before adding another agent

I help SMEs map responsibility, state, permissions, handoffs, evidence and failure recovery, then test the smallest architecture that can produce a reliable business outcome.

Request an AI workflow design review