Agensh: Scaling Organizational Intelligence to 1,024 Agents

Zhan, Song, Dong, Huang, Lian, Xia, Wei — Microsoft Research General AI group, arXiv:2609.26781 (2026-09-22). Code at github.com/microsoft/Agensh, project page aka.ms/Agensh. T1: the design and mechanism are the authors' own artifact (checkable against the paper and the released code); the benchmark numbers are the authors' own run, on their own five hand-picked ProgramBench tasks, with no third-party replication — flagged, not folded into the tier.

What it is

A multi-agent harness with no central orchestrator. Every other instance of fan-out in this wiki keeps a main agent that decomposes the task and assigns work; Agensh removes that role. Workers are concurrent and asynchronous, all running the identical prompt (differing only by worker ID), and each repeats a five-step loop: gather context, claim a sub-task, take action, verify results, merge progress. A worker decides what to do next by reading shared state, not by being told.

Three infrastructure pieces make that possible, each with a stated implementation:

• Shared workspace — a Git repository (hosted on Gitea). Workers commit to private branches and merge to main; Git's own conflict detection and version history do the coordination work a database would otherwise need.
• Message interface — built on Mattermost. A shared task channel carries low-priority, batched announcements; direct messages are high-priority and delivered as soon as a worker's next tool call returns, so an urgent conflict interrupts sooner than a status update.
• Shared context — an append-only, typed log (OBSERVED, FACT, FAIL, CLAIM, PATCH_SUMMARY) that the paper credits to DeLM, plus a grep tool over the full history so a worker can search past what fits in its recent memory.

Agensh sits above a single-agent harness rather than replacing it — the paper's own framing is "organization harness" versus "agentic loop." The cooperation loop lives in the worker's prompt, not hard-coded runtime logic, so the same instructions ran unmodified against both Claude Code and Copilot as the underlying single-agent executor in their tests.

What they measured

ProgramBench, the five hardest of its 200 tasks by state-of-the-art pass rate — rebuild FFmpeg, GROMACS, pandoc, PHP-src, and Universal Ctags from scratch, no internet access, 6-hour budget, reference repos running from 104K to 2.8M lines of code. Model held fixed at GPT-5.6-sol (high), harness held fixed at Copilot as executor.

• 1 → 128 agents: mean final pass rate across the five tasks 19.31% → 20.68% (8) → 26.52% (32) → 28.78% (128) — a 9.47-point, ~49% relative gain, holding model and per-worker harness constant.
• Speed, not just final score: on pandoc, 128 agents cross 30% pass rate at the 30-minute mark; 32 agents need 60 minutes; 8 need 90; the single-agent run never crosses it in the first two hours. More concurrent workers cut latency-to-a-given-quality, separate from raising the ceiling.
• 1 → 1,024 agents, pandoc only: final pass rate 33.89% (1) → 50.94% (128) → 55.06% (1,024) — the 1,024-agent run improves 21.17 points over the single agent and 4.12 points over 128, i.e. returns are diminishing but not flat even past a thousand workers.

Qualitative finding — cooperation forms are scale-dependent, not fixed by the (identical) prompt. Recorded trajectories at 8 agents show peers negotiating a shared interface and independently building to it; at 32, multi-worker review chains and a withdrawn-then-fixed contribution; at 128, workers choosing reviewers by track record and standardizing a merge protocol that later workers reuse unprompted; at 1,024, multiple workers converging on the same specialist role (integrator) with failover when one drops a task. None of this was specified — it emerged from identical workers reading the same shared state at different population sizes.

Its own limits

Everything above is one model, one underlying single-agent harness, five self-selected hardest tasks, one benchmark family. No comparison to an orchestrator-based harness at matched agent count — the paper argues orchestrators don't scale this far but never runs one at 128 or 1,024 to show where it breaks. No cost accounting: 1,024 concurrent agents against a 6-hour budget is a large token spend the paper doesn't report per point of pass-rate gained. And ProgramBench's "rebuild known software from scratch" task shape rewards parallel decomposition of well-understood work in a way an open-ended or ambiguous goal might not.

Where it sits

This is the sharpest counter-example in the corpus to agent-orchestration's framing as orchestrator-worker fan-out — see that page's own note that scalability there "is often constrained by a central orchestrator's capacity to allocate tasks and coordinate workers," which is exactly the limitation Agensh names as its reason for removing the role. jcode's swarm already broke the isolated-worktree default with peer-to-peer cache invalidation inside one shared repo; Agensh generalizes the move to three coordination primitives (workspace, messages, shared context) and puts a number on it at a scale two orders of magnitude past this wiki's next-largest measured instance (orchestrate-100-agents-claude-code, 100+ stateless headless sessions, no benchmark). It also answers a gap virtual-biotech left open — Zou's 37,000-agent system claims differentiated agents debating produces better outcomes with no numbers behind the claim; Agensh is a homogeneous population (same prompt, same role until roles emerge) with a controlled pass-rate curve, so the two are not directly comparable but sit at opposite ends of a "specify roles up front" vs. "let structure emerge from shared state" axis.

Related

agent-orchestration · jcode · orchestrate-100-agents-claude-code · virtual-biotech · agent-environment-design · microsoft · synthesis