Microsoft's Agensh runs 1,024 leaderless coding agents — and one agent on a newer model beat the whole fleet

Microsoft Research open-sourced Agensh on October 24 under an MIT license: a multi-agent harness that runs up to 1,024 coding agents in one shared repository, with no lead agent and no central scheduler (README). The README carries a comparison the paper's abstract omits: one agent on the newer GPT-6.1-sol scored 56.19% on the pandoc task, while the full 1,024-agent fleet on GPT-5.6-sol managed 55.06% — under the same six-hour budget (README).

What shipped

Agensh is coordination infrastructure, not a new agent. Each worker is a containerized Copilot CLI session — the Dockerfile pins @github/copilot at 1.0.70 and disables auto-update (agent Dockerfile) — running the same five-step cooperation loop: gather context, claim a sub-task, take action, verify results, merge progress (paper §2.1). Three services connect the workers. Gitea is the shared workspace (branches, pull requests, visible merge conflicts); Mattermost is the message interface (a team channel plus direct messages); and a shared context board, adapted from the earlier DeLM project, holds typed notes so workers do not repeat each other's dead ends (README, board-service README).

The reproduction defaults are concrete: 8 workers, six hours per task, gpt-5.6-sol at high reasoning effort, the Responses API, and a 272,000-token prompt window per worker (REPRODUCE.md). Microsoft evaluated on the five hardest ProgramBench tasks — FFmpeg, gromacs, pandoc, PHP-src, ctags (project page) — where agents rebuild reference programs from observed behavior and bundled documentation, with no internet access (README). Mean final test-pass rate across those five tasks, from the paper:

Agents	Mean pass rate (5 tasks)
1	19.31%
8	20.68%
32	26.52%
128	28.78%

The 19.31% → 28.78% jump is about a 49% relative improvement (paper abstract); the intermediate 8- and 32-agent rows match in the two independent teardowns (dev.to, stacksweep). On pandoc alone the scale went further: 33.89% with one agent, 50.94% with 128, and 55.06% with 1,024 (README).

Bigger teams also hit thresholds sooner: 128 agents passed 30% on pandoc at the 30-minute checkpoint, 32 agents needed 60 minutes, and 8 needed 90 (project page); the single-agent run never crossed it in the first two hours (dev.to, stacksweep). The marginal gains: 1 to 8 agents added 1.37 points, 8 to 32 added 5.84 (dev.to), and on pandoc the last 128 → 1,024 agents bought just 4.12 points (README).

The result the abstract omits. A second experiment lives in the README: with the newer 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, a 41.64% relative gain (README). Against the first experiment: one GPT-6.1-sol agent (56.19%) beat 1,024 GPT-5.6-sol agents (55.06%) on the same task and budget. Microsoft's own numbers show the model lever outperforming the headcount lever — which matters because GPT-6.1 Sol is already becoming the default: OpenAI's Codex 0.161 release notes (October 7) make it the default in the bundled and Bedrock catalogs.

Why it matters

Headcount buys latency, not quality. The quality gains on the five-task mean are real but small and saturate; the clear, monotonic win from more agents is time-to-threshold — reaching a given pass rate faster. A four- or eight-agent fan-out matching the numbers here buys roughly a point of final score. If you are scaling agents for throughput under a deadline, this is the argument for it. If you are scaling them for correctness, the data is much thinner.

Coordination emerges, and the mechanism is portable. The paper shows self-organized cooperation emerging and standardizing as the organization grows (paper abstract) — expanding, per its Figure 1 caption, from peer coordination to multi-worker integration, standardized workflows, and specialized roles (project page). The two independent teardowns give the concrete anecdotes. At 128 agents on pandoc, a pair of workers invented an integration protocol — author updates and tests a branch, sends the commit hash, peer validates and merges — which others adopted. At 1,024 agents, several workers specialized as integrators; a worker needing a merge pinged candidates, took the first valid responder, and cancelled the rest (stacksweep, dev.to).

The shared context board's five typed notes — OBSERVED, FACT, FAIL, CLAIM, and PATCH_SUMMARY (board-service README) — are the load-bearing piece, especially FAIL: the dev.to teardown describes it as a ledger of dead ends, so the 200th worker does not retry what the 12th already burned hours on (dev.to). Claim-before-work, a shared FAIL ledger, per-sub-task acceptance criteria, and an explicit merge protocol all port to a four-agent setup at almost no cost.

The trust model is the most copyable part. The merge policy is deliberately permissive: pull requests merge with zero required approvals, and direct pushes to main are restricted to an administrator (bootstrap README). Workers run as UID 10000 under a root supervisor (agent README). The reference binary is root-owned with mode 0111, so workers can execute it but cannot read its bytes — in the dev.to teardown's framing, cheating means passing the tests, not copying source (pbench_run.sh, dev.to). An egress proxy holds the real API credential; workers receive only a local proxy credential (REPRODUCE.md).

With the CI merge gate disabled (dev.to), what makes the permissiveness survivable is that every sub-task carries acceptance criteria checked inside the loop before the merge step (paper §2.1). Verification inside the loop, least privilege on the box, credentials outside the agents — that boundary design is worth stealing even if the zero-approvals merge policy is not.

Caveats

Everything quantitative here is vendor-reported from Microsoft's own runs, and the honest limits matter more than usual:

• No orchestrator baseline. The paper's whole case is against orchestrator-worker systems, but it never runs one — the question "does 128 peers beat one lead plus 127 workers?" is unanswered (stacksweep).
• 1,024 agents were tested on one task. The thousand-agent run is pandoc only — the smallest of the five repos (104K lines vs 2.8M for PHP-src) and the task with the strongest single-agent baseline (stacksweep).
• No costs anywhere. Neither the paper nor the README reports token counts or dollar amounts for any run (dev.to, stacksweep). A thousand workers with 272,000-token prompt windows for six hours is a real but unquantified bill — which makes the GPT-6.1-sol one-agent result look even better as a budget move.
• Apparently one run per configuration, with no variance or error bars. The single-agent baseline also needed a stop-hook to survive the full six hours, the multi-agent runs got an idle nudge after 10 minutes, and the final 45/5 minutes were scripted for every agent (stacksweep).
• Emergent behaviors are qualitative. The integration-protocol and integrator anecdotes come from trajectory logs; the paper does not report how often they occurred or what they contributed to the score (stacksweep).
• GPT-6.1-sol numbers are README-only. The 56.19%/79.59% figures appear in the README but not in the paper's abstract (README).

Sources

• Agensh: Scaling Organizational Intelligence to 1,024 Agents — arXiv:2609.26781
• Microsoft Research publication page
• microsoft/Agensh repository and README
• Agensh reproduction guide (REPRODUCE.md)
• Agensh project page with 1,024-agent replay
• board-service README (note types)
• bootstrap README (merge/approval policy)
• agent README (UID 10000)
• scripts/pbench_run.sh (mode-0111 reference binary)
• agent/Dockerfile (Copilot 1.0.70 pin)
• ProgramBench: Can Language Models Rebuild Programs From Scratch? — arXiv:2605.03546
• DEV Community teardown
• StackSweep teardown
• OpenAI Codex 0.161 release notes (GPT-6.1 Sol default)