I expected agents to save time. Orchestration became the bottleneck.

For the last while I've been running a real multi-agent engineering system: a mission-control workspace I built, sitting on top of a multi-agent engine, with specialist agents for coding, writing, review, analysis. Real projects flow through it — tasks get dispatched to agents, work comes back, a reviewer gates it, I approve or push back from my phone.

My expectation going in was simple: each agent that works in parallel is time I get back. Ten agents, ten lanes of progress.

That is not what happened.

What I built

The system does the things you'd expect: it breaks projects into tasks, writes a brief for each one, hands the brief to an agent in its own session, watches the run, sends the result through an independent review agent, and only marks work done when a completion contract — a small structured file the agent must write as its last act — checks out. There's a channel for agents to ask me questions mid-run, with a push notification to my phone and an answer file the agent polls while it keeps working.

Most of that machinery didn't exist on day one. Every piece of it was added because something specific went wrong.

What actually broke

A few failure modes, all real, all recent:

• The fix that fixed the wrong thing. A one-line text correction in a strategy document took four dispatch cycles. The first agent updated the report about the fix instead of the document. The reviewer caught it. The second agent fixed the document — and the third agent, sent to verify, read stale file state through its tooling and reported a failure on work that was already done. Each patch attempt also quietly duplicated a character it had copied from a numbered file listing, so a markdown table row kept growing extra pipes. One line. Four runs. Two reviews.
• Two agents, one task. A race between an automatic release rule and my manual release put two coder agents on the same task at the same time, working in the same repository, twenty seconds apart.
• My phone locked and killed a run. The live chat stream dropped when the screen locked; the system interpreted the disconnect as an interruption and stopped the turn. The label it showed me — "user sent a new message" — was wrong too, which cost me a debugging session of its own.
• The agent that asked and then stopped. An agent that ends its reply right after asking a question ends its own run — before anyone could possibly answer. The question channel only works if the brief teaches the agent to keep working while it waits.

Very few of these were model failures — in almost every case the models did what they were told. The costly failures were primarily coordination and system failures: the part I was responsible for.

Why orchestration is the cost

Every surface two agents share is an interface: the brief, the transcript, the file system, the task state, the review verdict. Each one can be stale, ambiguous, or half-written at the moment the other side reads it. With one agent you barely notice. With several, the probability that some shared surface is lying to someone at any given moment climbs fast.

So the work moved. I write less code now, but I write briefs, review gates, completion contracts, and verification checks. The bottleneck didn't disappear — it relocated from writing software to specifying and verifying it.

What changed

• Verification is byte-level and external. An agent claiming "the file is fixed" means nothing; a count of the exact bytes in the actual file, checked from outside the agent's own tooling, means something.
• Completion is a contract, not a vibe. A run counts as done when the structured completion file says so and the checks pass — never because the process exited.
• History is append-only. Deleting a bad task record once caused an ID to be reused and a new run to silently attach to an old session. Now nothing gets deleted; superseded work gets parked with a note pointing at its replacement.
• Humans are a designed-in channel, not an interrupt. Questions push to my phone; answers land in a file the agent polls; deploys are mine alone, always.

What I believe now — and what I don't know

Agents are real leverage for well-specified, verifiable work — the kind where you can write down what done means and check it mechanically. In my experiments so far, orchestration cost has scaled with ambiguity rather than with agent count. And a small number of agents behind strong gates has beaten a large number behind weak ones every time I've tried both.

What I can't tell you yet: how much of this tax is inherent, and how much is just my system being young. Whether better shared memory dissolves the stale-state problems or merely moves them. Where the break-even is for a real product team. I'm running the experiments; the numbers so far are one system, one person, a few months.

That's the honest state of it. When it changes, I'll write that down too.

Update, September 2026: it happened again on a real product. I spent a weekend rebuilding the mobile app for one I’ve led for four years, with agents, and ran into the same bottleneck — A weekend with agents changed how I think about teams.