Get Started
Home
Topics
Search
Library
6 min read · Agents · Code Generation · Added Sep 24 · Paper published Sep 22, 2026

Agensh: Scaling Organizational Intelligence to 1,024 Agents

Source: research paper via Hugging Face Daily Papers
Rebuilding pandoc-scale software from a reference binary blows past a single agent’s context, and orchestrator-worker swarms bottleneck at the lead. Agensh deletes the orchestrator: 1,024 peers coordinate via Git, chat, and a typed append-only board, lifting pandoc pass rate from 34% to 55%.
TL;DR
Agensh removes the central orchestrator from multi-agent coding systems: workers self-claim sub-tasks and share state through a Git repo, chat channel, and append-only note board, letting the organization scale to 1,024 concurrent agents on a single software-rebuild task.
Why It Matters
Suppose you point an agentic coding system at a hard task: rebuild something like the pandoc document converter from scratch in six hours, with no internet, using only a compiled reference binary you can run but not read. One agent runs out of context window, memory, and wall-clock time long before the job is done.
The usual scaling move is the orchestrator-worker pattern used by systems like Claude Code sub-agents, Codex agent harness sub-agents, and Kimi Agent Swarm. A lead agent plans, splits the work, hands pieces to parallel workers, and stitches the results back together. That lead agent is the bottleneck: it has to hold the whole plan in one context window and route every integration through itself. Past roughly a few dozen workers, it can no longer keep up.
Agensh, from Microsoft Research, asks whether you can just delete the orchestrator and let workers coordinate peer-to-peer through shared infrastructure. If it works, “number of agents” becomes a new axis you can scale, alongside model size and reasoning budget.
How It Works
Every worker runs the same loop and gets the same prompt (only the worker ID differs). Each worker repeatedly: reads the shared state, picks a piece of work nobody else is doing, announces it, does it, verifies against the reference binary, and merges the result. There is no manager telling anyone what to do.
Three pieces of infrastructure make peer coordination possible:
•
Shared workspace: a Gitea server. Workers develop on branches and open pull requests against main. Merge conflicts are the mechanism that surfaces overlapping work.
•
Message interface: a Mattermost channel for broadcasts, plus direct messages that get delivered mid-turn (interrupting a peer to resolve an imminent collision). Channel messages are lower priority and land at the start of the next loop iteration.
•
Shared context board: an append-only log of short typed notes, adapted from DeLM. Workers post CLAIM (I’m working on X), FACT (I confirmed Y), FAIL (Z doesn’t work, don’t retry), OBSERVED (reference does W), and PATCH_SUMMARY (I merged this change). New entries are pushed into peers’ next tool-call return, so findings propagate without polling.
Critically, the cooperation loop lives in the prompt, not the runtime. Agensh sits above a per-worker single-agent harness (they use Copilot as the underlying harness) and communicates through standard tool calls, so swapping the underlying agent framework is a small adapter change.
Rough shape of one worker’s turn:
while not done: ctx = read_board() + read_messages() + git_pull("main") subtask = pick_unclaimed_area(ctx, reference_binary) board_write(f"CLAIM: {subtask}") resolve_collisions_via_dm(subtask) code = implement_and_test(subtask, reference_binary) open_pr_and_merge(code) # rebase + retry on conflict board_write(f"PATCH_SUMMARY: files=... idea=... evidence=...")
What They Found
Evaluation is on the five hardest tasks in ProgramBench: rebuild FFmpeg, gromacs, pandoc, PHP-src, and ctags from scratch in 6 hours with no internet, given only the compiled reference binary. All runs use the same model (GPT-5.6-sol at high reasoning) and the same underlying single-agent harness.
•
Scaling helps the final score. Averaged across the five tasks, mean final test-pass rate rises from 19.31% (1 agent) to 28.78% (128 agents), a ~49% relative gain. The trend is monotonic through 8, 32, 128.
•
Scaling also helps latency. Larger organizations hit any given pass-rate threshold sooner. On pandoc, 128 agents cross 30% pass at the 30-minute mark; 32 agents take 60 minutes, 8 agents take 90, and a single agent doesn’t cross it in the first two hours.
•
Scaling continues at 1,024. On pandoc, going from 1 to 128 to 1,024 agents lifts final pass rate from 33.89% to 50.94% to 55.06%. Diminishing returns are visible (the 128→1,024 jump is 4.12 points versus 21.17 points from 1→128), but it hasn’t flatlined.
•
New cooperation patterns emerge with size. The authors describe qualitative trajectory observations, not measurements: at 8 agents workers agree on interfaces and split components; at 32 they run multi-worker code review; at 128 they invent and reuse a standardized “author sends commit hash, peer validates and merges” protocol; at 1,024, multiple workers take on integrator roles and hand off failed work to same-specialty peers.
The scaling numbers are real evidence for the scaling claim. The emergence descriptions are illustrative anecdotes from trajectory logs, not a quantitative study.
What’s Useful
•
If you’re building an agent harness for long-horizon coding work, the peer-to-peer pattern is worth trying before you invest in a smarter orchestrator. The core recipe is small: a Git server, a chat server, and an append-only note log with typed entries. The code is released.
•
The typed shared-context entries are the load-bearing idea worth stealing on their own. FAIL in particular saves budget by preventing peers from retrying dead ends, and pushing new entries into peers’ next tool return (rather than making them poll) is what keeps 1,024 workers roughly in sync.
•
Treat this as evidence for a specific task shape: long-horizon, decomposable, with a cheap external verifier (here, run the reference binary and diff outputs). Tasks without an oracle to check against, or where sub-tasks are tightly coupled, may not see the same scaling. The paper does not test those.
•
Cost is not reported. 1,024 agents running high-reasoning GPT-5.6 for 6 hours is a serious bill. Before scaling past a handful of workers, decide whether the latency reduction or the score bump justifies the multiplicative token spend for your use case.
Caveats
•
All results use one model family at one reasoning setting on one benchmark family (software reverse-rebuild with a runnable reference). Generalization to other model tiers, other task types, or tasks without a verifiable oracle is untested.
•
The 1,024-agent extension is shown on pandoc only, the smallest of the five reference repositories. The paper does not scale past 128 on the larger targets (FFmpeg, PHP-src, etc.).
•
The “emergent cooperation” story is qualitative trajectory reading, not a controlled ablation. It’s suggestive of what larger organizations do, not proof that specific patterns caused the score gains.
•
The single-agent baseline needed a special “keep going” stop-hook prompt to fill the 6h budget at all, which is a fair modeling choice but means the 1-vs-N comparison isn’t between identical prompts.
•
Absolute pass rates remain modest (55% on the easiest of the five tasks with 1,024 agents). This scales cooperation, it does not solve the underlying task.
Topics
Agents
Code Generation
Microsoft Research
NLP
Agents
Code Generation
Microsoft Research
NLP
Up next in Agents
DeltaStreamer: Towards Human-Like Agentic Streaming Video Understanding
MAI-Gym: An Open All-in-One Platform for GUI Agent Evaluation and RL Training across Mobile and Computer Environments
Don't miss new content
Log in to follow topics and personalize your feed.
Related topics you might like
Agents288 episodes
Code Generation67 episodes
NLP135 episodes