Orchestrating the Swarm (Without Crashing)
I thought one agent was hard to control.
Then I spawned five.
Now they’re fighting over the same file like seagulls over a French fry.
The Multi-Agent Promise
“Why use one agent when you can use five specialized ones?”
Browser. Coder. UI. Planner. Reviewer.
The pitch was beautiful.
The reality is three agents writing to the same file while a fourth reads yesterday’s version and the fifth confidently reviews a hallucination.
The File Lock War
10:23 AM: Browser Agent reads users.ts.
10:23 AM: Coder Agent edits users.ts.
10:23 AM: UI Agent deletes a function from users.ts.
10:24 AM: I get three conflicting diffs.
10:25 AM: The file is a Frankenstein of all three edits.
10:26 AM: Nothing compiles.
Single agent? Easy. It waits for the file system to be ready.
Multiple agents? They don’t know each other exists.
They’re all acting on stale state, racing to the finish line, and crashing into each other at the merge.
The Context Explosion
Each agent gets context.
But they don’t share context.
Planner Agent decides: “We need a new API endpoint.”
Coder Agent builds: POST /api/users.
UI Agent assumes: POST /users.
They’re both confident. They’re both correct in their own context.
And they’re both completely incompatible.
I’m the translator. The middleman. The diplomatic envoy shuttling between agents like I’m negotiating a peace treaty.
“Coder, the endpoint is /api/users.”
“Frontend, use /api/users.”
“Browser, test /api/users.”
I’m copy-pasting the same information to five different agents because there’s no shared memory.
The Coordination Tax
Multi-agent systems promise parallelism.
In theory: All five agents work simultaneously. 5x speedup.
In reality: I spend most of my time doing traffic control.
Stop writing.
Pull latest.
Don’t touch that file.
Wait.
By the time I’ve orchestrated all five, I could have written it myself.
The coordination cost eats the parallelism gain.
The Hallucination Echo Chamber
One agent hallucinates a function: utils.magicSort().
It doesn’t exist.
But Agent B sees Agent A’s code. Assumes it’s real. Uses it.
Agent C sees Agent B’s code. Assumes it’s real. Documents it.
Agent D sees Agent C’s docs. Assumes it’s real. Writes tests for it.
Now I have four agents confidently building on top of a foundation that doesn’t exist.
And when I try to run the code, it all collapses.
The State Problem
The hardest part isn’t the agents.
It’s the state between them.
How do I make them agree on what time it is?
I’m managing a distributed system.
Except the “nodes” are non-deterministic language models with no concept of locks, queues, or transactions.
I’m building Kafka for hallucinations.
The Single Agent Wins
I tried the swarm.
I went back to one.
Not because it’s faster.
Because it’s manageable.
One agent makes mistakes? I catch them.
Five agents make mistakes? I’m in triage mode, picking through the wreckage, trying to figure out which agent broke what and why.
The lesson:
Parallelism only helps if coordination is cheap.
With AI agents, coordination is expensive.
So expensive that one smart agent beats five dumb ones.