Microsoft scaled to 1,024 coding agents with no orchestrator

Microsoft Research took away the lead agent. In Agensh, every worker gets the same prompt, picks its own sub-task, and merges its own code, coordinating only through a Git server, a chat channel, and a shared log of findings. On the five hardest ProgramBench tasks (rebuild FFmpeg, PHP, pandoc, gromacs, or ctags from a black-box binary, offline, in 6 hours), going from 1 agent to 128 raised the mean test-pass rate by about half. One run pushed pandoc to 1,024 agents.

• Mean pass rate, 5 tasks: 19.31% (1 agent) to 28.78% (128 agents), +9.47 points or ~49% relative
• pandoc: 33.89% (1) to 50.94% (128) to 55.06% (1,024)
• Faster, not just better: 128 agents passed 30% on pandoc at 30 minutes; 32 agents took 60, 8 took 90, and 1 agent never got there in the first 2 hours
• Returns shrink fast: the last 896 agents on pandoc added 4.12 points; the first 127 added 17.05
• Same model everywhere: GPT-5.6-sol (high reasoning) running in the Copilot harness

The setup: no boss, just shared infrastructure

Today’s multi-agent coding tools (Claude Code agent teams, Codex subagents, Copilot /fleet, Kimi Agent Swarm) use an orchestrator-worker pattern: one agent plans, splits the work, hands it out, and merges results. The paper’s argument is that the orchestrator becomes the bottleneck. It can only track and integrate so many workers.

Agensh removes it. Each worker runs the same five-step loop:

Three pieces of off-the-shelf infrastructure hold it together:

• Shared workspace: a Gitea server. Private branches, PRs, and merges into main. Git’s conflict detection does the job an orchestrator’s integration step would.
• Message interface: Mattermost. One team channel, delivered at the start of each turn, plus direct messages that interrupt a peer mid-turn. The prompt tells workers to DM only when two of them are about to edit the same thing.
• Shared context: an append-only log (borrowed from DeLM) of typed notes capped at 100 characters: OBSERVED, FACT, FAIL, CLAIM, and PATCH_SUMMARY. New entries get appended to whatever tool result a worker is waiting on, so findings spread within one tool call. The prompt calls FAIL “the highest-value entry” because it stops 1,023 peers from retrying a dead end. A grep tool searches the full history past the 2,000 most recent entries.

The loop itself lives entirely in the worker prompt, not in the runtime, so the paper says it can sit on top of Claude Code or Copilot with a thin adapter.

The results

The authors call agent count “a new scaling dimension.” The curve says it’s a steep one. Measured per doubling of agents, pandoc gained about 2.4 points per doubling from 1 to 128, and about 1.4 per doubling from 128 to 1,024. On the 5-task mean, the first three doublings (1 to 8) bought only 1.37 points; most of the gain showed up between 8 and 32.

The paper reports no token counts or dollar costs. From the launch schedule (one agent every 30 seconds for the first hour, then one every 3 seconds), we estimate the 128-agent runs used roughly 700 agent-hours against the single agent’s 6, and the 1,024-agent pandoc run close to 5,000. That’s roughly 115x the compute for 1.5x the score at 128 agents, and a further ~7x for the last 4 points on pandoc.

The latency result is the better argument for the approach. If you have a hard deadline, more agents get you to a given score sooner: 128 agents crossed 30% on pandoc at the 30-minute mark, when by the stagger schedule only about 60 of them had even started.

What the agents organized on their own

The paper’s most interesting section reads the worker logs. Every worker got the same prompt, but different coordination patterns showed up at each scale:

• 8 agents: peers agreed on a module interface in gromacs and built commands against it independently. In FFmpeg, one worker changed scope after a DM about an overlapping claim.
• 32 agents: real code review. In PHP-src, several peers approved a PR, another found a counterexample, the approvals were withdrawn, the author fixed it, and a peer merged.
• 128 agents: workers started picking reviewers by prior experience and reusing those pairings. On pandoc, two workers invented an integration protocol (author tests the branch, sends the commit hash, peer validates and merges) that others adopted. After some failures, they renegotiated it so the reviewer owned the full update-test-merge cycle.
• 1,024 agents: several workers became dedicated integrators. A worker would ping multiple candidate integrators, take the first valid responder, and cancel the rest. Workers in the same technical area picked up each other’s failed attempts.

These are qualitative examples picked from the trajectories, not measured rates. The paper doesn’t say how often they happened or how much they contributed to the score.

Caveats

• No orchestrator baseline. The paper’s whole case is against orchestrator-worker systems, but it never runs one. We know 128 peers beat 1 agent; we don’t know if they beat 1 lead plus 127 workers.
• 1,024 was tested on one task. Pandoc is also the smallest of the five repos (104K lines vs. 2.8M for PHP-src) and the one with the highest single-agent score.
• Apparently one run per configuration, with no variance or error bars, and no per-task table for the other four tasks.
• The baseline needed help to stay alive. A single agent “can rarely sustain the full 6-hour runtime,” so it got a stop hook telling it there’s always more work. The multi-agent runs got a similar idle nudge after 10 minutes.
• The end of the run was scripted. At T minus 45 minutes, every agent was told to stop starting features and land open PRs; at T minus 5, to merge and confirm the build. That’s an external coordinator step, even if a small one.
• It’s a best case for parallelism. Rebuilding a CLI tool from a black-box binary splits naturally into flags, formats, and subcommands, each checkable against the reference. Work without a free oracle to verify against will be harder to spread across 1,000 agents.

For engineers building multi-agent systems, the useful part is how little is custom: Git for integration, a chat server for collisions, and an append-only log of short typed findings, where “this didn’t work” is treated as the most valuable message. More agents do buy a better result and a faster one. They just cost a lot more compute than the added score suggests, so it makes sense when time is the constraint, not budget.