Most multi-agent coding demos make the same mistake. They show twelve agents spinning up in a grid, point at the parallelism, and call it a day. The hard part isn't spawning them. The hard part is the next forty minutes — three are stuck waiting on plan approval, two are about to collide in src/api/auth.ts, and one has been quietly looping for six minutes on a problem you'd have caught in ten seconds if you'd seen the screen.
Spawning is one shell loop. Orchestration is unsolved. And the reason it's unsolved is that most engineers don't have a manager-of-twenty mental model — that wasn't part of the training data.
But it isn't actually a new skill. It's a skill most of us already had, hiding in a genre we stopped playing. A StarCraft player at gold tier manages 200 supply across three bases on a single screen with ten fingers and a hotkey grid. The skill stack — visibility, reaction speed, autonomy delegation, shared-map awareness — is exactly the stack a multi-agent IDE needs. Most multi-agent tools just haven't noticed.
Here's what shifts when you take the genre seriously.
1. Spawning was never the bottleneck
A loop in tmux can launch ten Claude Code sessions in twenty seconds. That has been true for a year. What still doesn't exist in most setups is a way to know, at a glance, which one needs you right now.
The default UX is a list of terminal tabs with a small dot next to each one. To find the agent waiting on input you tab through them, read the last line of each, and decide. That works for three agents. At eight, you spend more time triaging the list than acting on it. At twenty, you stop trying.
This isn't a model problem. The model is fine. It's a UX problem, and IDE vendors keep solving it with prettier lists when the genre that solved it twenty years ago doesn't use lists at all.
2. The map is your file system
The first move RTS games made was to drop the list and draw a map. Units sit on terrain. You see them in spatial relation to each other and to the resources they care about.
The equivalent for coding agents is the file tree, but rendered as terrain. Picture the literal version: directories become zones, files become runes on the ground, and each live agent stands on whatever file it's currently editing. You see "two agents both standing on auth.ts" before either commits. A heat map over recently-touched files surfaces the collision zones the same way a minimap surfaces enemy unit clumps in StarCraft — proactively, not after the fact.
The point isn't the specific aesthetic. It's that any spatial projection of your repo gives you O(1) collision detection. A list gives you O(n).
When not to use it: a 50k-file monorepo doesn't render legibly as a map. Scope the projection to changed-files-this-session and the heat map stays useful. Project the whole tree and you'll be staring at fog.
3. Muscle-memory cycling beats dashboards
A dashboard with green/yellow/red status badges still requires reading each row. RTS games solved this with a different primitive: hotkeys that jump you to the next unit needing input. F1 cycles to the next idle worker; Ctrl-G selects every unit of a type at once.
Translate that to agents and the move is: one keystroke jumps you to the next agent waiting on plan approval. You don't read the dashboard — the dashboard pushes itself at you. The orchestrator becomes a queue you process in order, not a wall you scan.
The pull-vs-push distinction is the thing. Pull (you scan the dashboard) scales linearly with your reading speed. Push (the next attention-requiring unit appears in front of you) scales with the orchestrator's ability to rank by urgency.
When not to use it: if you're running three agents, a dashboard is fine and a hotkey cycle is overkill. The cycle pattern starts winning around eight concurrent agents and is mandatory above fifteen.
4. Autonomy is a ladder, not a switch
"Autonomous agent" gets used as a binary, but the useful distinctions are between rungs.
| Rung | You do | The agent does |
|---|---|---|
| 0 | Prompt every task | Single turn, exits |
| 1 | Approve plans | Plans, executes, reports back |
| 2 | Pick from a queue | Surfaces its own missions (refactors, missing tests, dead code) |
| 3 | Describe a feature broadly | Containerizes, decomposes, spawns sub-agents, presents one PR |
| 4 | Set a cron and a source | Scans Twitter / GitHub / your inbox daily, picks ideas, ships PRs |
| 5 | Review variants | Submits ten implementations of the same task with screenshots; you pick |
Most teams stall at rung 1 because that's the rung shipping IDEs ship out of the box. The reason to climb is that each rung shifts the bottleneck. At rung 1, you're the bottleneck on tasking. At rung 3, you're the bottleneck on planning. At rung 5, you're the bottleneck on reviewing — and reviewing ten variants and picking is faster than planning one and watching it execute.
Honest caveat: rung 5 only beats rung 1 if your review workflow is fast. If "review a PR" still means a 20-minute trip through a UI with no screenshot evidence, the variants pile up and you've built yourself a worse bottleneck. The review tooling has to climb the ladder with you.
5. Shared maps, not just shared repos
The interesting collaboration unit in multi-agent work isn't human-to-human, and it isn't human-to-agent. It's everyone-on-the-same-map.
In a 2v2 RTS match you don't merge replays after the fact — you share vision live, see each other's units moving, and adjust without coordination overhead. The codebase equivalent is a workspace where I can see my teammate's agents working on the prototype in one corner while my refactor agents work in another, with soft messaging between humans and agents both. The agent announces "starting on checkout.ts." I announce "also touching that file." The collision gets caught at intent time, not at git merge time.
Hand-off becomes a primitive. The designer's agent gets the prototype to 80%. I take over the same agent — same context, same workspace state — and ship the rest. No "send me your branch" dance.
When not to use it: solo work or pairs don't need it; the absence of shared-map UX is exactly what makes a team of five-plus humans with their own agents feel chaotic. The chaos isn't the agents. It's the missing minimap.
6. What this means when you pick a multi-agent tool
The thesis isn't to chase any specific orchestrator. It's that the evaluation criteria for multi-agent tooling are not the criteria most vendors are competing on.
Vendors compete on: model quality, plan quality, integration count. Useful, but those are rung-0 features. The criteria that actually matter past three concurrent agents:
- Does it project the repo as a map, not a list?
- Is there a hotkey that jumps me to the next agent needing input?
- Does autonomy go beyond "approve this plan"?
- Can two humans see each other's agents in the same workspace, or do we trade branches?
If a tool ships a great model behind a tab list with no spatial view, no cycle key, and no shared workspace, it's a chat client wearing an IDE costume. Fine for one agent. Hostile at twenty.
If your multi-agent tool's UX is a list of tabs, you've built a build server, not a battle map. The model is the unit. The orchestrator is the game.