When Multi-Agent Adds Chaos

The Problem

You read about multi-agent systems. They sound amazing: agents working together, dividing tasks, reviewing each other's work. You implement it. Now your tasks take 3x longer, cost 5x more, and the output quality is worse than single-agent.

What happened? You fell into the multi-agent trap: more agents does not mean better results. Often it means expensive chaos.

Multi-agent has real use cases. But it also has anti-patterns - failure modes that are predictable, common, and expensive. Learn to recognize them before you burn through your API budget.

The Core Insight

Multi-agent architecture should solve a problem that single-agent can't. If single-agent works, don't add complexity.

Think of it like microservices vs monolith:

• Good microservices: Teams can deploy independently, scale different services differently, use best tool for each job.
• Bad microservices: 50 services for a simple app. Network overhead. Distributed debugging hell. Slower than a monolith.

Same with agents. Multi-agent is a tool, not a goal. Use it when it solves a problem. Avoid it when it adds overhead without benefit.

The Seven Anti-Patterns

Anti-Pattern 1: Agent Ping-Pong

What it looks like: Agent A asks Agent B a question. Agent B asks Agent C. Agent C asks Agent A. They loop endlessly, never completing the task.

Example:

Code Agent: "I need to know the database schema"
Data Agent: "I need the requirements to determine the schema"
Requirements Agent: "I need to see the code to understand requirements"
# Infinite loop

Why it happens: Agents have circular dependencies. Each needs the other's output to proceed.

Fix: Either:

• Provide bootstrap context (give the schema to Code Agent upfront)
• Use a single agent that handles all three concerns
• Enforce strict ordering: Requirements → Data → Code (no backwards communication)

Anti-Pattern 2: Context Explosion

What it looks like: Each agent needs context from previous agents. Context grows exponentially. Final agent receives 50KB of chat history and produces garbage.

Example:

Agent 1 output: 2KB
Agent 2 needs Agent 1's output: 2KB input → 3KB output
Agent 3 needs both: 5KB input → 7KB output
Agent 4 needs all three: 12KB input → 15KB output
# By agent 10: 100KB+ of context, model performance degrades

Why it happens: Naive chaining passes all previous context forward.

Fix:

• Summarize between agents (Agent 2 summarizes Agent 1's output to key facts)
• Use structured state (JSON schema) instead of natural language
• Only pass relevant context (Agent 3 doesn't need Agent 1's reasoning, just results)

# Bad
agent_2_input = agent_1_full_output  # 10KB

# Good
agent_2_input = {
    "schema": agent_1_output["schema"],  # 500 bytes
    "tables": agent_1_output["tables"]   # 1KB
}
# Total: 1.5KB instead of 10KB

Anti-Pattern 3: Merge Hell

What it looks like: Multiple agents work on the same output. Merging their results is harder than the original task.

Example:

Agent A writes function foo()
Agent B also writes function foo()  # Different implementation
Merge agent: "Both versions are valid but incompatible. I cannot reconcile them."
# Human has to manually fix

Why it happens: Tasks aren't truly independent. Agents overlap in their outputs.

Fix: Strict task boundaries. If merge is non-trivial, tasks were poorly decomposed. Either:

• One agent per output artifact (Agent A writes file1.py, Agent B writes file2.py - never the same file)
• Sequential instead of parallel (Agent A writes code, then Agent B reviews - no merging)

Anti-Pattern 4: The Infinite Loop

What it looks like: Agents iterate trying to improve output, but never converge. They run until timeout or budget limit.

Example:

Generator: "Here's the code"
Critic: "This could be more efficient"
Generator: "Optimized code"
Critic: "Now it's less readable"
Generator: "More readable version"
Critic: "Now it's less efficient"
# Loop forever

Why it happens: No clear exit condition or conflicting optimization criteria.

Fix:

• Set max iterations (3-5)
• Define "good enough" threshold (score >= 8/10)
• Prioritize criteria (correctness > efficiency > style)
• Detect plateaus (if no improvement in 3 iterations, stop)

Anti-Pattern 5: Cost Spiral

What it looks like: Multi-agent task costs $5 when single-agent would cost $0.50.

Example:

Task: Write a simple function

Single-agent: 1 call × $0.50 = $0.50
Multi-agent:
  - Supervisor decompose: $0.30
  - 3 parallel agents: 3 × $0.50 = $1.50
  - Supervisor merge: $0.40
  - 2 critique iterations: 2 × ($0.50 + $0.30) = $1.60
  - Final review: $0.20
Total: $4.00 (8x more expensive)

Why it happens: Coordination overhead + iteration loops.

Fix:

• Use single-agent for simple tasks
• Use cheaper models for non-critical agents (Haiku for supervisor, Sonnet for workers)
• Limit iterations strictly
• Track cost per task and compare to baseline

Anti-Pattern 6: Latency Cascade

What it looks like: Sequential agents create a waterfall of delays. Total latency is unacceptable.

Example:

Requirements agent: 8s
Design agent: 10s (waits for Requirements)
Code agent: 12s (waits for Design)
Test agent: 9s (waits for Code)
Review agent: 7s (waits for Test)

Total: 46 seconds
Single-agent doing it all: 15 seconds

Why it happens: Sequential dependencies with no parallelization opportunities.

Fix:

• Use parallel patterns where possible (test and docs can run in parallel with code)
• If sequential is required, use single-agent
• Streaming: let downstream agents start before upstream agents fully finish

Anti-Pattern 7: The God Supervisor

What it looks like: The supervisor is doing all the work. Worker agents are just executing trivial subtasks.

Example:

Supervisor:
  - Understands full requirements (20KB context)
  - Designs architecture
  - Decomposes into 10 tiny tasks
  - Merges all outputs
  - Reviews final result

Worker agents:
  - "Write this one function exactly as I specify"
  - "Format this JSON"

# Supervisor is doing 90% of cognitive work

Why it happens: Over-architecting. Tasks are too granular.

Fix: If supervisor is doing most of the thinking, use single-agent. Worker agents should handle non-trivial subtasks, not act as glorified templaters.

When to Use Single-Agent Instead

Use single-agent when:

• Task is small (< 20 second duration)
• Task is sequential (A depends on B depends on C)
• Output is cohesive (one file, one artifact)
• You're prototyping (multi-agent adds complexity)
• Cost is a primary concern

Use multi-agent when:

• Tasks are truly independent (can run in parallel)
• Different agents need different expertise (specialized models or prompts)
• Quality improvement from iteration exceeds cost
• Outputs are separate artifacts (different files, services, formats)

The Decision Tree

Is the task > 20 seconds?
├─ No → Use single-agent
└─ Yes → Can it be parallelized?
    ├─ No → Use single-agent
    └─ Yes → Are subtasks independent (no merge complexity)?
        ├─ No → Use single-agent
        └─ Yes → Will parallel execution save >10s?
            ├─ No → Use single-agent
            └─ Yes → Use multi-agent (parallel pattern)

Quality needs iteration?
├─ No → Use single-agent
└─ Yes → Have clear exit criteria?
    ├─ No → Use single-agent
    └─ Yes → Will iteration cost < 2x single-agent?
        ├─ No → Use single-agent
        └─ Yes → Use multi-agent (critic pattern)

Measuring Multi-Agent Success

Track these metrics. If multi-agent isn't winning, revert to single-agent:

If you hit red flags, your multi-agent architecture is making things worse, not better.

# Use single-agent if ANY are true:
- Task < 20 seconds
- Sequential dependencies
- High merge complexity
- Prototyping phase
- Cost-sensitive

# Use multi-agent only if ALL are true:
- Subtasks are independent
- Parallelization saves > 10 seconds
- Clear exit criteria exist
- Quality gain justifies cost