You hand one agent a big task: build a whole feature, backend to UI to tests. It starts strong, does the backend well. By the UI it's forgetting a few backend decisions. By the tests it "fixes" a backend spot to match a test — undoing what it got right half an hour ago. One agent, carrying too much, on a desk that isn't big enough.
The next reflex sounds reasonable: if one is overloaded, open three. But three agents dropped into the same task with no rules of play aren't three times faster — they manufacture a new kind of chaos.
01Numbers aren't speed
Three agents running, each with its own desk — and here's the sting: they can't see each other's desks. The one on the UI doesn't know the one on the backend just renamed a field. Two edit the same file, the second overwrites the first. The third is waiting on the other two, but their two results contradict each other.
This chaos isn't because the agents are bad. It's a direct consequence of what we already know: each agent only sees what's on its own desk. Multiply the agents without multiplying the discipline of coordination, and you've only multiplied disconnected desks — and the places they collide.
02The three jobs of an orchestrator
Good orchestration isn't opening more chat windows. It's doing three jobs, and you — not the agents — are the one doing them:
Cut the work into NON-overlapping parts. Each agent one tight role, one private area — so two never touch the same spot.
What does each role need from another? Pass exactly that — a summary of decisions, the shared contract — not the whole desk of one agent into the next.
One single place to assemble the pieces and resolve where they conflict. Without it, you have three individually-right answers that are wrong together.
Notice: all three are human jobs, or jobs for an orchestrator-agent given exactly that role. The executing agents can't coordinate themselves — for the same old reason, they can't see each other's desks.
03When it's actually worth splitting
Just as important: most work doesn't need many agents. Splitting roles has a cost — you have to draw boundaries, write contracts, merge. That cost only pays off when the work is genuinely large and separable into independent parts.
Work where each step depends tightly on the last only springs more context leaks when split — better to let one agent run it in sequence. The sign a task is worth splitting: you can draw clear boundaries between the parts, and picture two of them running in parallel without constantly asking each other questions.
The three pieces ahead go deeper into each job: cutting roles so they don't overlap, passing the right slice of context instead of the whole desk, and gathering in one place that knows how to reconcile. The thread is the thread of this whole craft: agents don't see each other — coordination is something you build, not something you hope for.