Why a multi-agent workflow beats one long prompt

Most teams meet coding agents the same way: open a chat, paste the ticket, type "implement this", and nudge for two hours. It works until the fortieth turn, when the model has forgotten the constraint from turn three. I stopped doing that. What replaced it is a small multi-agent workflow: a few specialised agents, each with a fresh context, passing files to each other, with a human at the gates. Here is why that shape wins, with the numbers I trust and the ones I don't.

A long chat degrades, and the research says so

A model's attention is a budget, not a bucket. The more you pour in, the less lands on any one thing.

The measurements agree. Lost in the Middle (Liu et al., TACL 2024) showed accuracy is highest when the relevant information sits at the start or end of the input, drops when it is buried in the middle, and falls as the input simply gets longer. Chroma's Context Rot report (July 2025) ran 18 models through deliberately easy tasks and found that "performance grows increasingly unreliable as input length grows"; a single related distractor already lowers accuracy, and the drop starts long before the window is full. Anthropic's context engineering guide (September 2025) names this context rot and says to treat context "as a finite resource with diminishing marginal returns".

A two-hour implementation chat is all three findings at once. The ticket is in the middle, forty tool outputs sit between it and the current turn, and by the time you reach QA the context is at its longest and the model at its dullest, exactly when you need it sharp.

The shape: specialised agents, hand-off files, human gates

The fix is not a longer window. It is to stop needing one. The workflow I run looks like this, with Claude Code as the runtime and a slash command as the entry point. The names are examples; every project adapts the roles, commands and gates to what it ships.

A fresh context per role. Each agent starts empty, with its own system prompt and only the file it needs. Claude Code's subagents are built for this: each one "runs in its own context window" and returns only a summary. The architect's dead ends cannot become the coder's distractors, and the reviewer never watched the code being written, so it does not share the coder's blind spots.

Files instead of memory. ticket.md, plan.md, diff.patch, review-2.md. A hand-off file forces a decision to be written down, so it can be read later, diffed and argued with, and it makes an agent's output testable in the dullest way: did the file appear, does it say APPROVED. Anthropic calls this structured note-taking. I call it what makes a bad run cheap to throw away.

Gates where a wrong turn is still cheap. The plan gate costs the human five minutes and saves the project half a day: a wrong rendering strategy is a paragraph to reject, not a branch. The verification gate is mechanical (typecheck, lint, build, all exit 0) and no agent can talk its way past it. Review rounds are delta-scoped, so a one-line fix does not pay for a full re-verification, and one checkpoint commit per attempt means the worst case is git reset.

The failure research agrees. The MAST taxonomy (NeurIPS 2025) annotated over 200 multi-agent runs and found most failures come from poor specification and misalignment between agents, not from a weak model. Written hand-offs and gates are the boring answer to both.

The number: 33% more throughput on one team

Here is the measurement I keep getting asked about, caveats attached. On a large transport-sector project, one team of about a dozen developers and testers adopted a workflow of this shape. I compared throughput per sprint, in tickets and story points, a few sprints before and after. It went up by roughly 33%.

What that is: my own measurement, one team, a few sprints, one codebase. What it is not: a benchmark, a controlled experiment, or a promise. Velocity moves for a dozen reasons and I did not isolate them. For contrast, METR's early-2025 trial found 16 experienced open-source developers got 19% slower with AI tools while believing they were faster (METR now marks that result as out of date). The gap between felt and measured speed is the point: measure your own. Still: a third more shipped work, for a folder of Markdown files. That is a hell of a difference.

Read Anthropic's multi-agent research post (June 2025) next to this. Their lead-plus-subagents setup beat a single agent by 90.2% on an internal research eval, with the caveat that coding has fewer parallelisable tasks than research and multi-agent systems burn about fifteen times the tokens of a chat. This pipeline is mostly sequential; the win is context isolation and gates, not parallelism, and the token bill is the price of not redoing the ticket.

What I'd actually do

• Start with two agents, not six: one writes the plan, one writes the code. Add the reviewer when the plan gate stops being enough.
• Put every hand-off in a file in a gitignored state folder. If an agent needs something that is not in a file, that is a workflow bug, not a prompt to improve.
• Make gates mechanical where you can (exit codes) and human where you must (the plan, the PR). Never let an agent approve its own work.
• Turn every lesson into a rule file every agent loads. A budget like the JavaScript one I set on each project belongs there, so the reviewer checks it before I do.
• Measure throughput before you start, or you will end up like the developers in that trial, feeling faster.

The one-shot chat is not wrong because the model is weak. It is wrong because it asks one context to be the architect, the coder, the reviewer and the memory, and it is bad at being the memory. Give each job its own head and a piece of paper to pass along. Setting one up for a team is a thing I do.