How do you decide how many parallel workers an orchestrator should fan out to?

## Width is an economic decision The seductive property of a fan-out is that adding workers looks like adding capability. It is really adding cost linearly and capability sub-linearly. Every extra worker pays a fixed overhead — its instructions, its tool schemas, its own reasoning about a task it has just been told about — before it produces a single useful token. Interviewers ask this question because getting it wrong is one of the most common ways an agent system becomes too expensive to ship. ## Start from the work, not from a number The defensible width is the number of **genuinely independent slices**. Independence has a test: could this worker complete correctly without knowing any other worker's output? If not, it is a sequential dependency wearing a parallel costume, and widening the fan-out just produces workers that guess at each other's results. Slices should also be **comparably sized**. A fan-out's latency is the slowest worker's, so eight even slices finish far sooner than one huge slice and seven trivial ones. Uneven slicing is why a nominally parallel run often shows almost no latency benefit. ## Three ceilings **Token budget.** Cost scales close to linearly in width, and orchestrated research patterns burn substantially more than a single-agent equivalent — on the order of a small multiple for a modest fan-out, and roughly an order of magnitude over ordinary chat use for full research runs. There is a real result to hold in mind here: as of mid-2026, several evaluations found single-agent systems matching or beating multi-agent ones *at equal token budget*, which means the honest comparison is never "one agent versus eight" but "one agent with 8x the budget versus eight workers with 1x each". Width is only justified where the work is parallel and the input genuinely exceeds one window. **Lead capacity.** Every return enters the lead's context. Twenty workers at 1,500 tokens each is 30,000 tokens of briefs before the lead reasons at all, and synthesis quality degrades as that window lengthens. Past that point you need a hierarchical merge — condense batches, then synthesize the condensations — which costs another layer of information loss. That trade, not raw cost, is usually the real ceiling on width. **Concurrency.** Provider rate limits, your own bounded-concurrency controls and downstream tool quotas determine how many workers genuinely run at once. If only six can run concurrently, a width of twenty runs in waves and buys none of the latency benefit that motivated the width. ## Governing the lead Leads over-fan. Told to be thorough, a lead will spawn a worker per question it can think of. Practical governance: give the lead an explicit width cap per task class, give it a rough effort scale (a simple lookup gets one or two workers, a comparative study gets one per source, a deep survey gets ten to fifteen), and require it to state why a wider fan-out is needed. Enforce with a hard cap in the harness rather than relying on the prompt, and track spend per run so regressions show up. ## Prefer depth of contract over width of fan-out When results are poor, the instinct is to add workers. Usually the better lever is a tighter worker contract, better slices, or a verification pass on the existing returns. A second round of three sharp workers, dispatched after reading the first round, routinely beats one round of fifteen vague ones — and costs less. ## Where the ceiling moves Width is justified higher when slices are large and read-heavy (each worker's window is doing real work no single window could do), when latency matters more than cost (user-facing research where wall-clock time is the product), and when returns are small and highly structured so the lead's window stays light. It should be pulled lower when slices are small (the per-worker overhead dominates the useful work), when subtasks are interdependent, when workers perform side effects rather than only reading, and when the answer must be auditable — every hop compresses evidence, and wide fan-outs put more compression between the source and the final claim.