At some point I stopped writing code and started writing coworkers. A fleet of AI agents, each pointed at a different project, all supposedly working while I did other things.
It did not go the way the demos promised. One agent is a genius. A pile of agents left unsupervised is a very expensive way to generate merge conflicts.
The thing nobody tells you: the hard part isn’t the agents. It’s the middle management. And I’m not just reporting a hunch — over the last year a handful of research groups quantified exactly the potholes I kept hitting, and the numbers below are theirs, not mine.
The Problem, With Receipts
A single agent is great until it isn’t. It forgets what it did an hour ago, wanders off the task you gave it, and confidently reports “done” on something that doesn’t build. Now imagine ten of them, touching the same repos, on their own schedules. That’s not automation — that’s a group project.
None of those failure modes are personal. They’re measured. A team out of UC Berkeley (Cemri et al.) hand-annotated more than 1,600 execution traces across seven popular multi-agent frameworks and built a taxonomy of why these systems fail. The striking part is that only a minority of failures are the model being “dumb.” Most are organizational — the kind of thing a decent manager exists to prevent.
That third bar — nobody checking the result — is the one that used to bite me at 2 a.m. But the first two are where the volume is, and they’re pure management failures: fuzzy instructions and agents that can’t see what their peers are doing.
The “forgets what it did an hour ago” problem has its own literature, too. Language models get measurably worse at using information as it drifts toward the middle of a long context — the now-famous “lost in the middle” curve. Stuff at the start and end stays sharp; the muddled middle quietly falls out of attention.
So the first thing I had to accept: I wasn’t going to prompt my way out of this. The failures are structural, so the fix had to be structural too.
The Idea: Give Them a Boss
So I built a hierarchy. One orchestrator — the manager — and a rotating cast of workers it delegates to. The orchestrator doesn’t write much code itself. Its whole job is deciding what needs doing, spawning a worker for exactly that, and verifying the result before anything counts as finished.
This isn’t a personal quirk; it’s roughly the shape Anthropic landed on for their own multi-agent research system: a lead agent that plans and delegates, and subagents that each work a slice with their own context window. Giving each worker a fresh window is half the point — it’s a direct dodge of the “lost in the middle” decay from Figure 2, because no single agent has to hold the entire project in its head.
In Anthropic’s internal evals, that arrangement (an Opus lead with Sonnet subagents) beat a single Opus agent by a wide margin — but at a real cost.
That right-hand card is the discipline the hype skips. You spin up a manager and a crew because the task is worth roughly fifteen chats’ worth of tokens — not because more agents is automatically better. Think less “swarm of autonomous geniuses” and more “one slightly paranoid tech lead running standups,” and only for work that earns it.
The Honest Counterargument
I should flag the other camp, because it’s persuasive and it kept me honest. The team behind Devin published a piece with the blunt title “Don’t Build Multi-Agents.” Their argument: the moment you fan work out to parallel subagents that can’t see each other’s context, they start making conflicting implicit decisions. Their example is a “build a Flappy Bird clone” task where one subagent renders a Super Mario–style background while another draws a bird that doesn’t match — nobody was wrong locally, but nobody shared context, so the pieces don’t fit. Their rule of thumb: prefer a single-threaded agent with continuous context, and only get fancy when you truly have to.
Both things are true at once, and that tension is the design problem. Look back at Figure 1: the two biggest bars are bad specification and inter-agent misalignment — which is precisely the failure Cognition is warning about. Multi-agent wins when the work genuinely splits into independent pieces and every worker gets a crisp brief. It loses when you shatter one coherent task across agents who are quietly guessing about each other.
So my job as “manager” isn’t to spawn more agents. It’s to make the handoffs unambiguous and to guarantee no two workers are ever secretly editing the same thing — one worker per repo at a time, full stop. That single rule deletes the Flappy Bird failure before it can happen.
Structured Handoffs
The trick that made it actually work: treat agents like contractors, not oracles.
Every task goes out as a structured brief — the goal, the context, which files are fair game, the acceptance criteria, and the exact commands that prove it’s done. Every worker reports back in the same fixed shape — status, what it changed, what it ran, and where it got stuck. It’s boring paperwork, and it’s the most important code in the system. A brief that says “improve the checkout flow” is how you get a Flappy Bird; a brief that says “modify only these three files, make pnpm test:checkout pass, don’t touch the schema” is how you get something you can actually merge.
This is almost verbatim the lesson from both sides of the debate. Anthropic found that vague delegation (“go research the semiconductor shortage”) produced duplicated, overlapping work, and that the fix was giving every subagent “an objective, an output format, guidance on tools, and clear task boundaries.” MetaGPT — an academic framework that has agents role-play a whole software company — makes the same bet its central thesis, literally writing it as Code = SOP(Team): encode the standard operating procedures a good org already uses, and quality falls out of the process rather than out of any one agent’s brilliance.
No vibes. No “looks good to me.” If a worker can’t show the verification command passing, the task isn’t done. The single biggest quality upgrade in the whole system wasn’t a smarter model — it was refusing to accept work that couldn’t prove itself.
A State Machine, Not a To-Do List
Each project moves through explicit phases — build, test, review, and so on. The rule is boring and load-bearing: you can go backward, but you can never skip forward. If review finds a problem, the project drops back a phase; it doesn’t get to sprint ahead because an agent felt optimistic.
This targets a specific, measured weakness. That ~21% task-verification slice from Figure 1 splits into three nasty little modes: premature termination (declaring done too early), no or incomplete verification (a rubber-stamp check), and incorrect verification (checking the wrong thing). And here’s the part that changed my design: the Berkeley team found that bolting a verifier onto the end isn’t enough on its own — one framework with a dedicated reviewer role still shipped correct code only about a third of the time. Verification has to be woven through the phases, not sprinkled on at the finish line. A state machine you can’t fast-forward is how you force that.
When Workers Fail (They Will)
The last piece is knowing when to stop. Every failure has a retry budget. Miss it, and the item gets escalated to a human — me — instead of looping forever.
This is the direct antidote to the single most common failure mode in the entire dataset:
Step repetition — agents grinding the same ground because nothing told them to quit — tops the chart. Infinite retries are how you wake up to a thousand commits that all say “fix tests” and a repo that’s somehow worse than when you went to bed. Bounded retries plus escalation is the difference between an autonomous system and a runaway one — and it’s the cheapest insurance in the whole design.
What I Actually Learned
Most of the engineering here had nothing to do with prompting. It was the stuff you’d put around any unreliable-but-capable worker: clear specs, verification you can’t fake, states you can’t skip, and a hard limit on how long anything’s allowed to be stuck. When I finally went looking for the research, it was almost eerie how neatly the failure taxonomies lined up with the guardrails I’d been forced to build — specification, coordination, verification, and knowing when to stop. The same walls, in the same order.
The models keep getting smarter. The scaffolding is what makes a pile of them behave like a team instead of a very polite riot.
Further reading
- Cemri et al., Why Do Multi-Agent LLM Systems Fail? (UC Berkeley) — the failure taxonomy behind Figures 1 and 5.
- Anthropic, How we built our multi-agent research system — the orchestrator/worker pattern and the numbers in Figure 4.
- Cognition, Don’t Build Multi-Agents — the case for single-threaded agents and shared context.
- Hong et al., MetaGPT: Meta Programming for a Multi-Agent Collaborative Framework — encoding standard operating procedures as agent workflows.
- Liu et al., Lost in the Middle: How Language Models Use Long Contexts — the effect sketched in Figure 2.