Multi-Agent Orchestration Patterns
When to split work across agents, four coordination topologies, and why most tasks should stay single-agent.
Start single-agent, split only when forced
Multi-agent systems are compelling and frequently premature. Every split adds: serialization cost, a coordination protocol, failure modes at the seams, and debugging difficulty.
Split when one of these is true:
- Context genuinely overflows. A subtask needs to explore thousands of lines, and only its conclusion matters.
- Parallelism has real payoff. Independent subtasks where wall-clock time matters.
- Specialization is required. Different tools, permissions, or system prompts that conflict in one thread.
- Verification must be independent. A separate checker that cannot see the worker’s reasoning.
If none apply, stay single-agent. “It feels cleaner” is not a reason.
Four topologies and their tradeoffs
| Pattern | Shape | Best for | Main risk |
|---|---|---|---|
| Supervisor | Hub delegates to workers, aggregates | Well-decomposable tasks | Hub becomes bottleneck & context chokepoint |
| Pipeline | Sequential stages, each transforms output | Extraction → transform → review | Errors compound downstream |
| Debate | Two agents argue, third judges | Decisions with real stakes | Cost triples; can converge to confident nonsense |
| Swarm | Peers hand off to each other | Open exploration | Hard to debug, hard to terminate |
Supervisor is the default choice. It is the easiest to reason about and to instrument.
The hub must pass conclusions, not transcripts
The most common orchestration bug: the supervisor concatenates every worker’s full history. Context explodes, and attention gets spread across irrelevant detail.
Specify a return contract per worker:
returns: { task_id, status, findings[], artifacts[], unresolved[] }
The hub sees conclusions and pointers. If it needs more detail later, it asks — that is cheaper than always carrying everything.
Give every agent a termination condition
Agents loop. Before launching, define:
- Max iterations or tool calls per agent
- What counts as done (not “when it seems finished”)
- Which conditions escalate to a human rather than retrying
An unbounded worker is an unbounded bill.
Failure handling across the seam
Workers fail in ways single-agent systems do not: partial results, timeout mid-task, contradictory outputs from siblings.
- Timeouts: return partial progress + explicit incompleteness marker; never silently drop the task
- Contradictions: escalate to judge/human; do not have the hub pick arbitrarily
- Repeated failures: fail the task loudly rather than retrying a fourth time
Debugging distributed reasoning
Multi-agent systems fail silently and expensively. Minimum instrumentation:
- A trace id propagated to every worker and tool call
- Per-agent input/output logged separately
- Token cost attributed per agent
Replay ability is worth building early: the ability to re-run one worker with identical inputs turns finger-pointing into diagnosis.
A note on cost
Parallel agents multiply token spend fast. Before scaling out, check whether a single agent with better context management gets 90% of the benefit at a fraction of the cost. Often it does.