Parallel work is addictive: since several agents gave a speedup, it seems another pair will give even more, and the hand itself reaches to launch one more session. But a fan-out has a point past which each new branch adds no speed but takes it away - and knowing when to stop turns out to matter more than knowing how to launch. It is that skill which takes the longest to learn.
The naive stance is "parallelism is always good, and stopping is a step back". Hence the habit of spawning a new session for any refinement of the task and one more agent for any fork in the discussion. It seems you thereby explore the task wider and miss nothing; in fact you smear one and the same task across boundaries that do not exist, and lose the common thread.
It breaks precisely when the branches stop being independent of each other. There is a set of signals, each of which on its own says "enough": the tasks have begun to share one mutable contract; the acceptance criteria have drifted and change on the fly; the review queue grows faster than you clear it; the agents repeat the same research; the cost of the independent variants has already exceeded their value. Any single one of these signals is enough to stop the fan-out - beyond it parallelism works against you, not for you.
Why these signals exactly and not others. They are all, in essence, about one thing - the disappearance of the independence that parallelism alone rests on. A shared mutable contract means the branches actually edit the same thing, just from different sides. Drifting criteria mean there is no common target, and each agent aims at its own understanding of the task. Duplicated research means the work was not divided but simply multiplied. Once independence is gone, each extra branch only multiplies what you will then have to converge by hand.
The professional move after a stop is not to abandon what was produced but to gather it in one place. What several sessions gathered is put into one Space - a container where sessions, pull requests, files and the accumulated shared context are brought together under one task, so a new agent gets up to speed without a retelling from scratch. On this shared material a human makes the architectural decision, updates the plan and launches a single integration branch instead of a dozen diverging ones. A Space turns scattered outputs into a shared context rather than a pile of conflicts.
It is worth saying separately about duplicating sessions. A duplicate session fits a genuinely alternative hypothesis: two fundamentally different approaches to a solution that are more honestly checked apart and then compared by result. But spawning a duplicate for every small refinement of the wording turns a tool for comparing hypotheses into a way to defocus one task for no reason. This is an engineering boundary of use, not a product ban: a duplicate is justified by a fork in the design itself, not in the words the task was described with.
The cost of a stop not noticed in time is quite concrete. Diverging branches on a shared contract give conflicting diffs that someone later converges by hand, losing hours. A growing review queue moves the bottleneck from the machine to the human, and there it stays. Repeated research burns tokens on the already known, adding nothing to the result. In sum, parallelism that long ago stopped saving begins to cost time, attention and money - and the more, the later it was finally stopped.
The other side of the rule is just as honest: while none of the signals is present, parallelism is justified, and there is no need to brake it out of caution alone. Independent artifacts, stable acceptance criteria, a manageable review queue and non-overlapping research are signs that the branches still work for you and genuinely share the task. A stop is an answer to a concrete signal that fired, not a general fear of fan-out as such.
You should check whether parallel work still holds by a short and strict control. Each session has exactly one owner of the result. Files or worktrees do not conflict between branches. There is a shared acceptance contract, one for all. A human is assigned to take the final merge. As long as all four points hold, the branches are independent and parallelism is legitimate; the moment even one of them drifts, that is the signal to converge the work into a Space and return the decision to a human, not to launch one more session.
The typical failures here are always about a missed stop. "The diffs do not converge" - the branches had long shared one contract, while the fan-out was continued anyway. "Review cannot keep up" - the queue grew steadily, but new sessions kept being launched on inertia. "The agents go in circles" - they repeated one research, because it was not converged into a Space in time. The sign is the same in every case: parallelism was held as an end in itself rather than as a means with a clear condition of applicability. Know the stop signals and converge the work into a Space at the very first of them, and a swarm of agents does not turn into a swamp.