A paper posted to arXiv on 22 September makes a structural argument about multi-agent systems: the central orchestrator — the model that decomposes a task and hands pieces to workers — is what stops these systems scaling. Agensh, from Zhihao Zhan and six co-authors, removes it.
In its place the paper puts an infrastructure of three pieces. A shared workspace holds proposed, ongoing and completed work. A message interface lets workers talk to each other. A shared context retains reusable findings and stated work intentions. Concurrent workers then run a cooperation loop against that infrastructure: gather context, claim and self-assign a sub-task, act, share findings, verify results, and merge progress asynchronously.
The numbers
On challenging programming tasks, the authors report that scaling from 1 to 128 agents raised mean test-pass rates by about 49 per cent. On one task — rebuilding parts of pandoc — scaling from 1 to 1,024 agents took the final test-pass rate from 33.89 per cent to 55.06 per cent.
These are the paper’s own figures on its own evaluation, not an independent reproduction, and they concern software engineering tasks rather than agent work generally.
What the claim actually is
The authors frame agent count as a new scaling dimension for agent organisations, alongside model size and inference compute. That is a stronger claim than “more agents help”, because it asserts the curve keeps going rather than flattening once coordination overhead eats the gains — which is what usually happens, and what the paper includes an ablation on.
The secondary finding is the more interesting one for anyone building these systems: the authors report that self-organised cooperation patterns emerge and standardise as the organisation grows. Workers converge on ways of dividing labour that nobody specified, and the convergence gets stronger with size.
Why it is not obviously good news
A 1,024-agent run that lifts a pass rate from 34 to 55 per cent is a large amount of inference for a result still well short of solved. The practical case the paper makes is narrower than the headline: this helps on complex tasks under strict latency budgets, where you would rather spend a great deal of compute in parallel than a moderate amount in sequence.
There is also a governance question the paper does not address. An orchestrator is a chokepoint, and chokepoints are where monitoring goes. A system whose workers claim their own sub-tasks and merge their own results has removed the place an operator would naturally watch.
What to watch
Whether anyone reproduces the 1,024-agent result on a benchmark the authors did not choose, and what the total inference cost of that run was — a figure the abstract does not give.
