Ask a single agent to build a small feature and it will plan, write, and check its own code in one uninterrupted run, judging its own work by whatever standard it set for itself a few minutes earlier. Split the same task three ways instead: a planning agent breaks the request into steps and hands over a spec, a coding agent writes to that spec and hands over a diff, a reviewing agent reads the diff against the spec and either approves it or sends it back. Nothing about the underlying model changed between the two setups. What changed is that the work now passes through three sets of hands instead of one, and the result depends as much on what happens between those agents as on what any single one of them can do.

Three stations, one dish

Splitting a job across agents this way mirrors how a busy professional kitchen runs service. A head chef plans the ticket, a line cook fires the proteins and vegetables, a pastry chef handles dessert, and each of them is better at their own station than any one person could be at all three. The line cook doesn’t need to know how to temper chocolate, and the pastry chef doesn’t need to time a sear. When the handoffs are clean, that specialization pays off twice: each station produces better work than a generalist would, and stations that don’t depend on each other can run at the same time instead of waiting in a queue. In an agent pipeline this looks like a planner producing a task list, a coder consuming that list item by item, and several coding agents sometimes working on independent pieces of it in parallel, each one’s output becoming the next agent’s input.

The reviewing step matters just as much as the parallelism. A dedicated review agent reads the coding agent’s output with a fresh perspective, the way a head chef checks a plate before it leaves the pass, and can catch a mismatch between what was asked for and what was produced before it reaches the customer. That catch is only possible because the reviewer is a separate process from the one that did the work, with no stake in defending its own first draft. One agent grading its own homework tends to wave through its own blind spots; a second agent looking at the actual requirement, not the intention behind it, is positioned to notice what the first one couldn’t see in itself.

Why teams bother splitting the work

The appeal is straightforward. A model instructed to “plan carefully, then write clean code, then check it thoroughly” in one pass is juggling three jobs with one attention span, and tends to shortchange whichever one comes last. Giving each job its own agent, sometimes its own model or its own prompt tuned for that specific task, tends to produce a better plan, cleaner code, and a review that actually happens instead of being skipped under time pressure. It also opens the door to running independent pieces at once rather than in sequence, the way a kitchen plates an appetizer and a dessert component together instead of one after the other. A ten-step task that would run start to finish through one agent can finish in a third of the time when three of those steps don’t depend on each other and three agents take them on at once.

The handoff is the new risk

None of this makes the underlying job simpler. It relocates the difficulty. A single agent working alone never had to worry about whether its planning self correctly told its coding self what “done” meant, because they were the same continuous process. A multi-agent pipeline does have to worry about exactly that: the planner leaves out a constraint it assumed was obvious, the coding agent proceeds without it, and the review agent, checking the diff against a spec that was already incomplete, waves it through. Nobody made an error inside their own station. The line cook fired the dish correctly, the pastry chef built the right dessert, but neither one knew the other’s course was running twenty minutes behind, and the plate that reaches the table is wrong anyway. Adding more agents doesn’t remove the coordination problem that a lone agent never had; it creates a whole new job, managing what each agent believes the others already did, and that job comes with its own way of failing that has nothing to do with any individual agent’s competence.

For the single-agent loop this whole approach is splitting apart, see Agents: When AI Stops Answering and Starts Doing, which covers what one agent does end to end before any of this division of labor enters the picture.