More Agents Is Not More Progress
The first thing to internalize is that parallelism has a cost, and the cost is coordination. Two agents editing the same area of a codebase do not double throughput; they create a merge problem and a chance of silently clobbering each other's assumptions. Ten agents attacking one vague goal do not converge on a great answer; they produce ten confident, divergent answers that someone now has to reconcile. The overhead is real, and past a small number it dominates.
This is the multi-agent version of Brooks's old observation that adding people to a late project makes it later. The communication paths grow faster than the work gets divided. Agents are cheaper to spin up than engineers, which makes the temptation stronger and the resulting mess larger. The useful question is never "how many agents can I run?" It is "how many independent pieces of work does this actually decompose into?"—and the honest answer is usually smaller than you hoped.
Role Separation Is Where the Wins Are
Where multi-agent designs pay off is not replication but specialization. The pattern that works, over and over, is separating an agent that plans from an agent that builds from an agent that verifies—and letting them be different models, so that a blind spot in one is not shared by the next. This is not "more agents doing the same thing." It is a small assembly line where each station has a different job and a different incentive.
The verifier being independent is the load-bearing element. A builder that checks its own work will confirm its own mistakes; a separate verifier, ideally on a different provider, has no stake in the builder's story. Vendor documentation from Anthropic and OpenAI describes meaningfully different model behaviors and strengths; that heterogeneity is an asset when you use it deliberately—route reasoning-heavy planning to one, fast building to another, skeptical verification to a third. Homogeneous swarms throw that advantage away.
Coordination Is the Real Product
If role separation is the value, coordination is what unlocks it. Someone—or something—has to own the seams: assign work, prevent two agents from colliding on the same files, decide when a task is genuinely done, and integrate the pieces. In our practice this coordinator role is where a human stays firmly in the loop, especially for anything unattended. Agents are good at bounded execution; they are not good at deciding, without a stake in the outcome, that the whole thing is coherent and safe to ship.
This is also where evidence discipline becomes non-negotiable. With one agent you can sometimes get away with reading the transcript. With several agents operating in parallel, transcripts are useless—you cannot hold five conversations in your head. The only thing that scales is receipts: tested commits, acceptance results, verifier verdicts. The instinct behind structured agent evaluations is exactly what multi-agent coordination needs—an objective standard each unit of work is measured against, so the coordinator integrates on proof rather than on which agent sounded most confident.
Isolation Makes Parallelism Safe
The mechanical enabler for running several builders at once is isolation. Each parallel line of work gets its own branch and its own worktree, so that agents are not editing a shared, dirty tree and cannot silently overwrite one another. This generalizes the same rule that keeps human parallel work sane—one workspace, one branch—into the multi-agent case, where the collision risk is higher because the actors move faster and never pause to notice they are stepping on someone.
Without isolation, "parallel agents" quietly becomes "one shared workspace and a race condition." With it, you can genuinely run independent pieces of work at the same time and integrate them through the coordinator on evidence. The isolation is boring infrastructure, and it is precisely what separates a productive multi-agent setup from an expensive one. Structured tool access via the Model Context Protocol plays a similar role for shared resources—auditable, structured access instead of several agents improvising against the same systems.
What This Looks Like in Practice
A team asked us to help them "run agents in parallel" to clear a backlog faster. Their first attempt had been exactly the failure mode above: several agent sessions pointed at the same repository and the same loosely defined goals, producing conflicting changes that a senior engineer spent more time reconciling than the changes had saved.
We restructured it around roles and isolation rather than replication. We split the backlog into pieces that were actually independent—which turned out to be fewer than the team assumed—and gave each its own worktree. Within each piece we ran the planner-builder-verifier separation, using a stronger model to plan, a fast model to build, and a different model to verify against acceptance checks. A human coordinator owned assignment and integration, advancing work only on receipts. We added a stop rule: any task that failed the same way twice went to the human instead of looping.
The result was not ten-times faster. It was roughly two independent streams running cleanly in parallel with far less reconciliation, and a senior engineer who was coordinating and reviewing instead of untangling. Modest, honest, and durable—which is the shape most real multi-agent wins take.
Common Mistakes
- Confusing replication with parallelism. More copies of the same loop is not more progress; it is more merge conflicts.
- Decomposing work that is not actually independent. Coupled tasks run in parallel just relocate the coupling into integration.
- Homogeneous swarms. Running the same model in every role discards the blind-spot diversity that makes separation valuable.
- No coordinator. Someone must own seams, integration, and the go/no-go call—usually a human for unattended or risky work.
- Reading transcripts instead of receipts. With several agents, only evidence scales; transcripts do not.
- Skipping isolation. Parallel agents on a shared tree is a race condition wearing a productivity costume.
- No stop condition. Without a rule to halt repeated identical failures, parallel agents multiply wasted spend.
This closes our series on AI-optimized engineering teams: we started with how to design the team around roles and evidence, walked the idea-to-production workflow, kept Cursor and coding agents inside real engineering discipline, and finished with the honest realities of running several agents at once. The through-line is simple and slightly unfashionable—AI multiplies the quality of your engineering system, so the durable advantage is building a good one.
