Microsoft's Agensh runs 1,024 coding agents with no manager: one agent on the newer model beat the whole fleet

Microsoft Research open-sourced Agensh on October 24, MIT-licensed, with the harness, the experiment launch scripts, and a reproduction guide. The paper behind it, Agensh: Scaling Organizational Intelligence to 1,024 Agents, has been on arXiv since September 22. The headline claim: 1,024 coding agents working in one shared repository, with no lead agent and no central scheduler assigning tasks.

I read the paper, the README, and the reproduction guide before writing this, because the most useful numbers in the release are not the ones in the headlines.

What Agensh actually is

Each worker is a containerized Copilot CLI session (the repo pins Copilot 1.0.70) running the same five-step cooperation loop. Three services connect the workers:

• Gitea is the shared workspace: branches, pull requests, visible merge conflicts
• Mattermost is the message interface, one team channel plus direct messages
• a shared context board, adapted from an earlier project called DeLM, holds typed notes so workers do not repeat each other's dead ends

The reproduction defaults are concrete: 8 workers, a six-hour budget per task, gpt-5.6-sol at high reasoning effort, the Responses API, and a 272,000-token prompt window per worker. Agensh is not a new agent. It is coordination infrastructure around agents you already have.

The scaling numbers, straight

On the five hardest ProgramBench tasks (FFmpeg, gromacs, pandoc, PHP-src, ctags), agents rebuild a reference program from its observed behavior and bundled documentation, with no internet access. The mean final test-pass rate, from the paper:

On pandoc alone, scaling continued past 128: 33.89% with one agent, 50.94% with 128, and 55.06% with 1,024, all inside the same six-hour budget.

Bigger teams also hit thresholds sooner. On pandoc, 128 agents passed the 30% mark at the 30-minute checkpoint, 32 agents needed 60 minutes, 8 agents needed 90, and the single-agent run never crossed it in the first two hours.

The number the headlines skip

The README carries a second experiment that got far less attention. With GPT-6.1-sol at high reasoning effort, the six-hour pandoc pass rate rises from 56.19% with one agent to 79.59% with 32 agents.

Read those two results together:

• one GPT-6.1-sol agent: 56.19%
• 1,024 GPT-5.6-sol agents: 55.06%

One worker on the newer model beat the entire thousand-agent fleet on the same task, under the same time budget. Before you add agents to a workflow, check which model line they run on. Codex 0.161 already flipped its default to GPT-6.1-sol, and model aliases stopped meaning one thing across providers, so pin the exact model id in your config if the model is what moved your numbers.

The scaling curve is not linear

Look at the gaps in the table above. Going from 1 agent to 8 added 1.37 points. Going from 8 to 32 added 5.84. On pandoc, going from 128 agents to 1,024 added 4.12 points. All three gaps come straight from the paper.

Small fan-outs mostly buy you time-to-threshold, not final quality. If you went from two parallel agents to four and saw no improvement in the finished work, that is consistent with Microsoft's own data. The quality gains in this paper show up at team sizes most of us will never run.

How workers coordinate without a boss

Every worker runs the same loop, asynchronously, with nobody assigning work:

while goal not achieved:
    context = read(goal, peer progress, messages, findings board)
    task    = claim_subtask(context)   # post a CLAIM, settle overlaps by DM
    result  = work(task)               # share useful findings early
    verify(task.acceptance_criteria)   # failures go to the board as FAIL notes
    merge(result)                      # PR plus a PATCH_SUMMARY note

The interesting part is what emerges. At 128 agents, two workers established an integration protocol on their own: the author updates and tests a branch, sends the commit hash to a peer, and the peer validates and merges it. After some failures, the workers revised the protocol and handed the peer the entire update, test, check, and merge cycle. Other workers then reused it. At 1,024 agents, multiple workers specialize as integrators, and a worker with code to merge contacts several candidates, takes the first valid responder, and cancels the rest.

Nobody configured any of this. The coordination emerges from the loop plus the shared workspace, and it standardized as the organization grew.

The notes board is the part worth stealing

The shared context board uses five note types, per the paper: OBSERVED, FACT, FAIL, CLAIM, and PATCH_SUMMARY. FAIL is the one that matters. It is a ledger of dead ends, so the 200th worker to arrive does not retry something the 12th worker already burned three hours on.

That idea scales down. The shape, the way I would write those notes:

CLAIM: rebuilding the table parser, branch ag-114 (worker 61)
FAIL: hand-rolled option parser, 3h, 214 failing tests. Do not
      retry without a grammar table. (worker 07)
FACT: the reference binary escapes backslashes inside table cells
PATCH_SUMMARY: PR #212 inline math filters, 61 of 63 target tests green

Two state files and a claim convention get you most of this at four agents, which is the parallel setup I run and wrote about before. And if your agents share context through a handoff, the same typed notes tell you what survives compaction.

The trust model is test-gated, not review-gated

From the reproduction guide: pull requests merge with zero required approvals, direct pushes to the main branch are restricted, and the CI merge gate is disabled. What makes that survivable:

• every sub-task carries acceptance criteria that get checked inside the loop, before the merge step
• workers run as UID 10000 and can execute the root-owned, mode-0111 reference binary without being able to read its bytes, so cheating means passing the tests, not copying the source
• an egress proxy holds the real API credential, and workers never receive it

I would not copy the zero-approvals setting into a team repository. But the boundary design is worth copying: verification inside the loop, least privilege on the box, credentials outside the agents. Everything rests on the acceptance criteria being real, which matches what NVIDIA measured with a spec file: 19% without one, 100% with one.

What I would take from this for a four-agent setup

Borrow:

1. claim before work: a worker posts what it is taking, so peers do not collide
2. a FAIL ledger shared across agents, written in the same format every time
3. acceptance criteria attached to each sub-task, not just to the overall goal
4. an explicit merge protocol, even if it is only "author tests, peer merges"

Skip: count scaling. Their own numbers say the first seven extra agents were worth 1.37 points.

And price the fan-out before you run it. Neither the paper nor the README reports token counts or dollar costs for any run. A thousand workers with 272,000-token prompt windows running for six hours is a real bill, and the cheapest lever in the whole dataset was the model swap, not the headcount. If you are cost-matching agent configurations, the prefix cache mechanics matter more at that scale than anything in the cooperation loop.

The repo is microsoft/Agensh, the paper is arXiv:2609.26781, and the project page with a replay of the 1,024-agent run is agens-harness.github.io.