As soon as there is more than one agent, the temptation appears to launch them as a swarm on a single task and wait for a multiplied speedup. Sometimes it works out that way, but more often you get chaos: agents edit the same thing, duplicate research, and untangling their work eats all the time it won and adds more on top. The problem is not the number of agents in itself but the absence of boundaries between them.

The naive model is "more agents means faster", as if the work could be split linearly into any number of hands, each new hand adding exactly its share. Hence launching several implementers on a shared feature in the hope that each will take its own piece and part ways with the others. It will - but no one set the boundary of the piece for it, and an overlap is almost inevitable.

It breaks on shared mutable state. Two agents writing one file without separate worktrees is not parallelism but a race for one resource: their diffs conflict, and someone silently overwrites another's work, and you learn of it last of all. The subagents documentation notes directly: handing out distinct profiles with a restricted tool set is exactly what keeps several agents from changing the same files at once. In other words, parallelism is safe precisely to the degree that the artifacts are separated, and not an inch more.

The professional move is to divide the work not by volume but by artifacts and ownership. Each unit of work must have one owner of the result and its own separate output. One agent owns the API change, another the independent tests for it, a third the review of those changes. As long as each writes strictly into its own, they truly go in parallel and do not get in each other's way; the moment two aim at one file, you need either a separate worktree or a merge owner assigned in advance, not upon the fact of a conflict.

It helps to fix the roles explicitly, so that each agent has its own surface and its own kind of output, known before the start. Below is a minimal topology that holds without chaos even across several sessions: a researcher, an implementer, a verifier and an integrator. You return to this table as a checklist before splitting work into parallel sessions, and check against it afterward who was responsible for what.

Why the roles are separated exactly this way rather than merged. The researcher works read-only - like subagent_explore on a cheaper model: its output is a map of the code and the risks, without a single edit, so it can be launched freely and early without fear of spoiling the state. The implementer changes code and therefore sits in a separate worktree or in the Cloud, handing back exactly one coherent diff. The verifier looks at the result with someone else's eyes - Quick Review or another agent - and gives independent checks rather than the author's self-assessment. The integrator is always a human: the merge decision is not delegated, because it is exactly what binds the scattered outputs into one whole and carries responsibility for the outcome.