Multi-Agent Is Not a Feature. It Is an Org Chart.
The moment an agent project stalls, someone proposes the same cure: split it into multiple agents — a planner, a researcher, a critic, a writer — and let them collaborate. Sometimes this is exactly right. Often it multiplies cost and failure modes while making the system impossible to debug. The difference is not fashion. It is information flow.
The First Question: Does New Information Enter the System?
The single most useful test before splitting a workload across agents: would the second agent see data the first one cannot?
- No — same context, different roles. If all participants would read the same documents anyway, a debate between agents adds little over one agent thinking longer. Several public benchmarks now support this: at equal compute, multi-agent debate on a shared context roughly matches a single chain-of-thought run. You pay coordination overhead for the appearance of teamwork.
- Yes — genuinely separate workspaces. Two codebases, two data sources, two long-running tasks whose intermediate noise would bury each other. Now splitting has a real benefit: context isolation. Each agent keeps a small, clean window; only the distilled result crosses the boundary. This is the same principle as sub-agent isolation for bulky research — taken to an architecture level.
Three Topologies, Three Trade-offs
When the split is justified, the shape of collaboration matters more than the number of agents:
- Peer-to-peer. Agents negotiate as equals. Maximum flexibility, minimum predictability — conversations can loop, and termination needs explicit design.
- Orchestrator and workers. A lead agent decomposes the task, dispatches, merges. The workhorse pattern: it maps cleanly onto context isolation, retries per worker, and a single place to enforce budgets and guardrails.
- Decentralized. No coordinator; agents react to shared events. Fits event-driven infrastructures, but requires the same discipline as distributed systems: idempotent actions, message contracts, dead-letter handling.
For most business workloads the orchestrator pattern is the sane default. It keeps a single audit trail, one budget meter, and one component that can say "stop".
What Multi-Agent Systems Teach You About Single Ones
Even if you never ship more than one agent, designing the split pays off:
- Contracts force clarity. The moment worker A must hand output to worker B, you are forced to define schemas. Single-agent systems benefit from the same rigor — structured tool outputs beat prose.
- Failure isolation. A crashed worker is a retryable unit. A crashed step inside a monolithic context is a lost session.
- Cost attribution. Per-agent accounting shows where tokens actually go. In our builds the bulk of spend concentrates in one or two stages — invisible until you meter them separately.
A Practical Decision Path
- Exhaust single-agent improvements first: context layout, tool quality, compression, better retrieval. Most "the agent is confused" bugs die here.
- If bulky intermediate work floods the context, add sub-agent isolation for that work — keep the orchestrator's window clean.
- Only when workstreams are genuinely parallel, separated by data source or side-effect boundary, promote them to full multi-agent with an orchestrator.
- Instrument from day one: per-agent tokens, per-agent success rate, end-to-end reliability. An unmetered multi-agent system is a cost generator with a demo mode.
Key Takeaways
- Split agents for information isolation, not for the illusion of teamwork on shared context.
- At equal compute, debate over one shared context rarely beats a single longer reasoning run.
- Orchestrator-with-workers is the default topology: one audit trail, one budget, one kill switch.
- Contracts, failure isolation, and cost attribution are bonuses even for single-agent systems.
- Multi-agent is an org chart: it amplifies whatever discipline (or chaos) the single agent already had.
