The whiteboard always wins the argument. You draw an orchestrator in the middle, a fan of specialist workers around it — a researcher, a writer, a critic — and it looks like a clean org chart. Decomposition feels obviously right. Then you ship it, and you discover that every line you drew between two agents is a place where information gets dropped, duplicated, or quietly corrupted. The diagram was a lie of omission. It showed the boxes and hid the seams.
I build multi-agent systems. I also tear a lot of them back down into single agents. The deciding question is almost never “would multiple agents be more elegant.” It is “can these agents coordinate cheaply enough to be worth the boundary.”
What a boundary actually costs
When you split one agent into two, you do not just add a second agent. You add a communication channel, and that channel is lossy. The orchestrator has to compress what it knows into a message. The worker has to interpret that message without the full context the orchestrator holds. Whatever the orchestrator didn’t think to include is simply gone from the worker’s world.
This is the part the whiteboard hides. A single agent carries its whole context with it. Two agents carry two partial contexts and a translation layer between them. Every boundary is a context bottleneck, and context, as I keep finding, is where agents actually fail.
A single agent forgets things. A multi-agent system forgets things and lies to itself about what the other agent knows.
The costs stack up concretely:
- Latency multiplies. The orchestrator calls a worker, waits, reads the result, decides, calls another. Each hop is a full model round-trip. A task that’s one agent’s five steps becomes an orchestrator’s five steps each wrapping a worker’s five steps.
- Tokens multiply. Every boundary re-states context. The orchestrator’s prompt, the worker’s prompt, the handoff message — you pay for the same facts several times.
- Errors compound silently. A worker returns a confident, wrong answer. The orchestrator has no way to know it’s wrong; it only sees the summary, not the work. It builds on the bad result.
When splitting genuinely helps
So I’m not anti-multi-agent. I split when the split buys something the costs can’t eat. There are a few real cases.
True parallelism over independent subtasks. If I need to enrich fifty leads in a federal-contractor intelligence platform I built and each enrichment is independent, fanning them out to parallel workers is a clear win. There’s no coordination between them — each one does its job and reports back. The boundary is cheap because nothing crosses it mid-task. This is the strongest case: embarrassingly parallel work with no shared state.
Genuinely distinct tool surfaces. A single agent loaded with sixty tools picks the wrong one constantly, for the same reason a cluttered context window degrades reasoning. Splitting into a finance agent with its tools and a scheduling agent with its tools can make each one sharper, because each sees a clean, small toolset. The split is paying down a context-pollution cost.
Adversarial separation. A generator and a critic genuinely benefit from being different agents with different instructions. The critic isn’t anchored on the generator’s reasoning because it never saw it. That independence is the whole point, and you’d destroy it by merging them.
When splitting hurts
The cases where I rip multi-agent systems back out are just as consistent.
Tightly coupled steps. If step two needs the full nuance of how step one went, not just its summary, you should not have split them. The handoff message can’t carry the nuance, so the second agent works blind. I see this constantly with “research then write” splits — the writer needs the researcher’s judgment about source quality, and a clean summary throws exactly that away.
Sequential chains with no parallelism. If your three agents always run in strict order, A then B then C, you have not built a multi-agent system. You have built one agent and paid three times for the privilege, with two lossy handoffs added for free. That’s just a pipeline wearing a costume.
Shared mutable state. The moment two agents both write to the same record, you’ve imported every hard problem in distributed systems — races, stale reads, conflicting updates — into a system that already has the entropy of language models running it. I avoid this until I have no choice.
A decision table
| Signal | Lean single agent | Lean multi-agent |
|---|---|---|
| Subtasks independent? | no, tightly coupled | yes, parallelizable |
| Handoff loses nuance? | yes | no, summary suffices |
| Tool surface | small enough for one | distinct, large per role |
| Need adversarial check? | no | yes, generator vs critic |
| Shared mutable state? | yes, keep it in one place | no shared writes |
When the column is mixed, I start with one agent. It is far easier to split a working single agent later than to debug a coordination failure across three agents that each work fine in isolation. The single agent is the simplest thing that works, and the simplest thing that works is where I always start.
How I keep boundaries honest
When I do go multi-agent, I treat the boundaries as the dangerous part and engineer them deliberately. Handoff messages are structured, not free-form prose, so I can validate them. I log every message that crosses a boundary, because that log is the first place I’ll look when the system does something inexplicable — the bug is almost always in a handoff, not inside an agent. And I gate irreversible actions at the orchestrator level, never inside a worker, so no single specialist can move money or send mail on its own confident-but-wrong judgment.
The orchestrator-and-workers diagram isn’t wrong. It’s just incomplete in the way that matters. It shows you the agents and hides the seams, and the seams are where production systems break. Draw the boundaries last, not first. Earn each one. Every line between two agents is a promise that the coordination across it is cheaper than the work it saves, and most of the time, for most tasks, it isn’t.