Once a parallel agent workflow is already running, adding one more worker can look almost free.
The spawn itself is cheap. The expensive parts sit on both sides of it: context before the branch can work, then verification, reconciliation, and reduction after it returns.
So the question I care about is not how many agents should this system have? I do not think the evidence gives us a useful universal number anyway.
It is narrower:
What will the next worker add that the current system cannot already get cheaply enough?
That is a marginal-utility question, not an agent-count question.
There are two adjacent decisions that are easy to blur into it. Before fan-out, the issue is whether a task should be delegated at all. After branches finish, there is the separate problem of reducing parallel results into one trusted answer. This sits between them: fan-out already exists, and I need a reason to make it wider.
Parallelism only helps when the work can separate
The most useful research result here is also the least dramatic one: task structure matters.
The September 2026 paper Rethinking Multi-Agent Collaboration: When More Is Less models long-horizon work as a dependency graph. In its tested setup, collaboration is more useful when the task contains relatively independent regions that can be separated without dragging the whole task history into every branch.
Tightly coupled sequential work creates the opposite pressure. If later steps depend heavily on earlier ones, decomposition adds coordination overhead and can damage the dependency chain the system has to preserve. The paper also reports that simply increasing the agent pool or recursion depth does not consistently improve outcomes in its experiments.
That does not establish an optimal worker count. It establishes something more useful for an operator: another worker is valuable only when there is another piece of work worth isolating.
A broader study, Towards a Science of Scaling Agent Systems, reaches a compatible conclusion across different benchmarks, architectures, and model families. It reports that task structure, coordination efficiency, redundancy, topology, and overhead all affect whether multi-agent execution helps. Parallelizable work can benefit; sequential or tool-heavy work can lose enough to coordination overhead that adding agents becomes counterproductive in the tested conditions.
I would not turn either paper into a fixed rule about two agents, three agents, or ten. The stronger reading is conditional.
Fan-out is an allocation decision.
Every new branch needs a context package
This is the part that makes “one more worker” look cheaper from the orchestration layer than it really is.
The current Hermes delegation documentation provides a concrete implementation example. A delegated subagent starts with a fresh conversation rather than inheriting the parent's full conversation history. The parent has to pass the goal, constraints, files, findings, or other context the child needs, and the child returns a final summary rather than its whole working context.
That isolation is useful. It protects the parent context and lets the subtask stay focused.
It also means the branch has an admission price.
If a worker can solve an independent problem from a compact brief, that price may be low. If the parent has to serialize most of its own state, exceptions, unresolved questions, and prior reasoning just to make the branch safe, the apparent parallelism is already spending attention before useful work begins.
The same thing happens at the other end. If the parent has to reopen every source, repeat the analysis, reconcile ambiguous output, or rebuild the child's reasoning before acting on it, some of the parallel gain has only moved into verification and fan-in.
The worker was busy in parallel. The system was not necessarily making net parallel progress.
Coordination cost is not one thing
Calling all of this “overhead” hides the parts I actually want to inspect.
Before widening a parallel workflow, I would separate at least five costs:
- Context reconstruction. What has to be copied, summarized, or rediscovered before the new worker can act safely?
- Duplicate work. How likely is it to search the same sources, inspect the same files, or repeat checks another branch already owns?
- Coordination and contention. Will it depend on shared state another worker is also changing, creating locks, merge conflicts, racing assumptions, or extra messaging?
- Verification. What evidence is required before its output can affect the main task, and who has to perform that check?
- Reduction. What new synthesis or reconciliation work appears when the branch returns?
Those costs can move independently. A branch can be cheap to brief and expensive to verify. It can produce genuinely different work but collide with shared state. It can finish quickly and still leave the parent with a large reduction problem.
That is why “the worker completed its task” is not enough as a success metric.
Give the next worker one job it can uniquely own
The benefit side needs the same specificity.
There are good reasons to add another worker. A branch may be able to proceed independently while the critical path continues. A specialist may bring a capability the current workers do not have. A deliberately independent review may be valuable precisely because disagreement is useful. A large search space may need more coverage than one branch can provide in the available time. Several genuinely different approaches may need to be explored in parallel.
The common property is not “more capacity.” It is a distinct contribution.
Before I add the branch, I want to be able to name that contribution in one sentence.
Then I want to name what the branch will cost: what context it needs, what work it might duplicate, what state it could contend over, what acceptance evidence I will require, and what has to happen when its result comes back.
If I cannot describe the incremental benefit before spawning the worker, I have no good basis for assuming the branch is additive.
A spawn call is cheap. The coordination surface around it is not.
Stop on evidence, not unused capacity
The stopping rule gets much better once it is allowed to be local.
A workflow can record what actually happened when another branch was added:
- Did wall-clock time fall?
- Did coverage increase?
- Did the branch find material the others missed?
- How much duplicate work appeared?
- Did verification effort rise?
- Did shared-state conflicts increase?
- How much work did the parent have to do to reduce the result back into the main line?
Those measurements do not need to become one universal score. Their job is to make the scaling decision falsifiable.
If a fourth worker repeatedly finds nothing new, duplicates checks, and increases merge effort without shortening the critical path, that is evidence to stop at three for that class of task in that setup. If another research branch repeatedly surfaces distinct evidence with little coordination burden, that is evidence to keep the wider fan-out.
The number is local. The method is portable.
I like that distinction because it keeps architecture from turning into ideology. A multi-agent system should be able to shrink as easily as it expands. Unused agent capacity is not unfinished work.
The 2026 collaboration paper makes a similar move in its own proposed design: it grows the collaboration graph on demand when the task structure exposes a boundary that can be delegated. I would not generalize its specific method beyond the tested setup, but the operating idea survives the qualification.
Spawn from evidence of separability, not from the assumption that empty capacity should be filled.
A small stopping contract
For an existing parallel workflow, I would make the next worker answer a compact contract:
- Unique contribution — What result or coverage should this worker add that is not already owned?
- Separability — Can it progress with bounded dependencies, or will it keep waiting on and reconciling with other branches?
- Context cost — What must the parent reconstruct for it to operate correctly?
- State cost — What shared resources or assumptions can conflict while it runs?
- Acceptance cost — What evidence is required before its output can affect the main task?
- Reduction cost — What synthesis or reconciliation work appears when it returns?
- Observed gain — What concrete outcome would show that adding the branch was worthwhile?
None of those fields decides the answer by itself. Together they stop fan-out from being treated as a free default.
More workers can still be exactly the right answer. Some tasks contain abundant independent work, some benefit from genuinely independent review, and some are constrained enough by time that parallel execution matters more than token efficiency.
The stopping point moves with the task, model, tools, state topology, acceptance process, and cost of delay.
That is why I would standardize the question, not the count.
The next agent should be added when its distinct contribution is expected to exceed the context, contention, verification, and reduction it creates. When the evidence says that margin has disappeared, stop there.
// End of transmission. Make the margin visible — ZYANE