Running Parallel Claude Code Sessions Turns You Into a Switchboard Operator

I ran three Claude Code sessions in parallel last night. Agent 1 fixed a race condition. Agent 2 refactored the billing module. Agent 3 wrote the tests. And me? I spent the evening copy-pasting context between terminals like a 1950s switchboard operator.

"Agent 2, here's what Agent 1 changed."

"Agent 3, the tests you wrote are for the old schema. Agent 2 moved it."

The agents did the engineering. I did the project management. Badly. At 11pm.

The promise vs the evening

The promise of parallel agents is obvious. Three sessions means three workstreams. Ship the sprint in a night. Every solo developer who has tasted this wants more of it.

The reality is that each session is a sealed box. Agent 1 does not know Agent 2 exists. Agent 2 has no idea the schema it refactored is being tested by Agent 3 right now. The only channel between them is you, reading one terminal, summarising, and pasting into another.

That job has a name. It is called project management. And when you do it live, between terminals, under time pressure, it has an older name: switchboard operator.

Why this gets worse, not better

Two sessions are manageable. Three are tiring. At four or five, the relay work grows faster than the engineering output. Every new agent adds a line to your switchboard, and every pair of agents that should coordinate adds a call you have to connect by hand.

The cruel part is that the agents keep getting better. They fix harder bugs, refactor bigger modules, write more thorough tests. Which means each relay message you carry is heavier, and getting it wrong costs more.

Somewhere along the way, "10x developer with AI" turned into "unpaid secretary for AI."

Nobody signed up for that. The whole point of the fleet was leverage. Instead the human becomes the lowest-bandwidth link in the system, and the fleet idles while the switchboard catches up.

The missing layer

The fix is not a smarter agent. The agents are already smart. The fix is shared state that all of them can read and write without going through you.

When agent 2 moves a schema, that fact should land somewhere agent 3 checks before writing tests. When agent 1 fixes a race condition, the bug should be marked fixed somewhere all of them trust. When a regression appears, it should be filed once, assigned once, and visible to everyone.

That is what a tracker is for. The catch is that the trackers we have were built for humans: browser logins, boards to click around, notifications sent to an inbox no agent reads. This is the problem we built Buggazi around. Agents file bugs, plan sprints, and message each other directly over a CLI, so the human reads the record in the morning instead of operating the switchboard at night.

And "hands off" does not mean "out of the loop." When agents raise features or bugs to fix, you accept or reject them from the dashboard. The fleet proposes, you decide. That is the difference between delegating and abdicating.

However you solve it, solve it before you add the fourth session. The engineering scales. The copy-pasting does not.