Small-agent teams gain unevenly from extra calls, preprint reports

A preprint posted to arXiv on 28 September 2026 finds that giving a team of small language-model agents more calls helps a lot on some tasks and barely at all on others. The authors, Blaz Bertalanic and Carolina Fortuna, describe a sweep of eight agent orchestration architectures, five instruction-tuned models of 7 to 9 billion parameters, five short-answer benchmarks and one executable-code benchmark, with budgets of up to 30 calls.

The headline result is a split by task. According to the authors, moving from three to thirty calls raised accuracy by up to 17 points on the two arithmetic word-problem benchmarks, GSM8K and GSMHard, but by at most four points on ARC, GPQA and MMLU, for every architecture tested. They argue that the usual task-averaged number conceals this difference.

No single design won everywhere. The paper says the Proposer-Critic architecture captured the arithmetic gains, scaled most steeply and, in aggregate, surpassed every other architecture at the largest budget, with item-clustered intervals excluding zero. It also ranks among the weakest architectures on other tasks.

To explain the pattern, the authors split any workflow into the candidates it proposes (coverage) and a downstream step that turns candidates into an answer (the transform). They say any accuracy change then divides exactly into a coverage dividend and a change in transformation. In their reading, arithmetic leaves room for more coverage that a critic-guided transform can convert, while the multiple-choice benchmarks either saturate in coverage or fail to convert it. On open-ended code, they report that generative recovery nearly vanishes, so accuracy tracks coverage.

Cost is a further variable. At equal call budgets, the authors report that token cost still varies by a factor of 2.1.

What is new is the framing rather than the idea that teams can help: the paper tries to say where extra calls pay off and why. The authors conclude that team scaling is a task- and architecture-specific bet, not a uniform lever.

The caveats are significant. This account rests on one source, the arXiv abstract page. We did not read the full paper or its tables, the page shows a first version with no sign of peer review, and we found no independent coverage or replication. The figures are the authors' own.

For teams building agent systems, the practical point is modest: a larger call budget should be tested per task and per design, since the gain may be large, small or costly.

Revised 16 October 2026: Guth re-read the original sources and rewrote this article. The earlier version remains available as revision 1.