Microsoft's Agensh Runs 1,024 Coding Agents Without a Central Controller
Microsoft Research shows removing the central orchestrator lets thousands of coding agents self-organize, lifting test-pass rates by up to 21 points.
- Microsoft Research's Agensh scales a single multi-agent organization to 1,024 concurrent coders without a central orchestrator.
- Workers coordinate through a shared Git workspace, a Mattermost message bus, and a typed shared context board.
- On pandoc, scaling from 1 to 1,024 agents lifts test-pass rate from 33.89% to 55.06%.
- Across the five hardest ProgramBench tasks, 128 agents deliver a 49% relative gain over a single agent.
- Roles like integrator and reviewer emerge on their own from identical worker prompts as scale grows.
- Code released at github.com/microsoft/Agensh, pluggable onto existing single-agent harnesses via adapters.
Microsoft Research’s new Agensh system coordinated as many as 1,024 coding agents working asynchronously on a shared codebase. Most multi-agent coding systems rely on a central agent to divide work, supervise workers, and combine their output. Agensh distributes those duties across shared services and a common worker protocol, removing the coordinator’s context window as the main scaling constraint.
One context window, one ceiling
Codex subagents, Claude Code subagents and agent teams, Copilot fleet, and Kimi Agent Swarm use an orchestrator-worker structure. A central agent plans the job, assigns subtasks, tracks progress, handles conflicts, and integrates contributions. As the worker pool grows, that agent must fit more workstreams, messages, and dependencies into one context window.
Agensh moves coordination into three shared components that every worker can access:
- Workspace: A shared repository contains the organization’s current and integrated work.
- Messages: Organization-wide announcements and direct messages carry updates that require attention.
- Shared context: A structured board records reusable findings, failed approaches, active claims, and work intentions.
Workers consult those components independently, choose work, communicate with peers, and merge completed changes. They run concurrently and asynchronously, so progress does not depend on a central queue or a global synchronization step.
Five steps per worker
Each worker repeatedly executes the same five-step loop:
- Gather context from the repository, messages, and shared context board to identify unfinished work.
- Claim a subtask by adding a
CLAIMrecord, then resolve overlaps through direct messages. - Take action with local tools and publish useful intermediate findings.
This story is for Pro members
You've reached the end of the free preview. Upgrade to AlphaSignal Pro to read the full article - and everything else behind the paywall.