Evidence at a glance
The mechanism in one line
Compress the visual or contextual input before the main reasoning path.
Route or verify the expensive step instead of repeating the full path.
Translate the mechanism into a bounded deployment or evaluation check.
Removing the Lead Does Not Remove Coordination
On October 24, 2026, Microsoft Research open-sourced Agensh, a decentralized harness for large teams of coding agents. It aims to reduce reliance on the central orchestrator used by many multi-agent systems. In a conventional orchestrator-worker design, a lead agent plans the work, assigns tasks, and integrates results. In Agensh, each worker finds its own subtask and coordinates through shared resources.
The change matters not because a system without a lead is inherently better, but because it reallocates the work of coordination. Planning and collision handling that might otherwise sit with a lead agent are shifted onto team conventions, shared state, and execution infrastructure. The central question is therefore not whether many models can run in parallel, but whether a team without a single scheduler can maintain a reliable working order.
A Shared Loop, Backed by Shared Infrastructure
Agensh has every worker asynchronously repeat the same five-step loop: read the goal and peer progress, claim a subtask, act and share useful findings early, verify against acceptance criteria, and merge progress into a shared repository. If claims overlap, workers can contact one another directly rather than wait for a lead agent to resolve the dispute. The loop primarily lives in the prompt, which is essentially the same for every worker apart from its identifier.
That does not mean Agensh has no central infrastructure. Gitea hosts the shared repository, branches, and pull requests. Mattermost carries team messages and direct messages, while a shared context board stores short notes such as observations, facts, failures, claims, and patch summaries. Agensh removes a lead agent that directs the team, not the service layer that supports collaboration or the underlying single-agent execution harness. The public repository says the experiments integrated Agensh with the Copilot harness, and other harnesses would need adapters.
The Scores Improve, but 1,024 Agents Is Not a Full-Benchmark Result
The main experiment used the five hardest ProgramBench reconstruction tasks: FFmpeg, Gromacs, Pandoc, PHP-src, and ctags. Agents had to rebuild programs from observed behavior and accompanying documentation, offline, within a six-hour budget. With GPT-5.6-sol at high reasoning effort, the mean final test-pass rate across the five tasks rose from 19.31% with one agent to 28.78% with 128, a gain of 9.47 percentage points, or about 49% relative.
The figure of 1,024 agents, however, applies to Pandoc alone, not the five-task mean. On Pandoc, GPT-5.6-sol rose from 33.89% with one agent to 50.94% with 128, and 55.06% with 1,024. The team also reported faster progress: 128 agents reached a 30% pass rate at the 30-minute checkpoint, compared with 60 minutes for 32 agents and 90 minutes for eight. The repository reports a separate GPT-6.1-sol configuration, where Pandoc rose from 56.19% with one agent to 79.59% with 32. Those figures should not be mixed with the GPT-5.6-sol results, and they are not in the v1 paper.
Scaling Depends on Parallelism and Visible Work
The results support a useful but limited conclusion: for these complex reconstruction tasks, adding workers can improve final scores and bring some milestones forward. They do not show that capability grows in proportion to the number of agents. The five-task mean increased by only 1.37 percentage points from one agent to eight before rising further, and the public materials do not establish that all programming tasks can be decomposed in the same way. Nor do they provide a quantitative comparison with other multi-agent harnesses using the same model, tasks, and budget.
The architectural point is that parallel work must remain visible, reusable, and verifiable. Claims can reduce duplicated effort, short findings let others continue an exploration, acceptance criteria constrain local results, and Git merges expose interface problems and conflicts. These mechanisms are not decoration: without a common workspace and searchable progress records, more workers can also mean more repeated work and incompatible patches. Agensh puts coordination rules into a shared protocol rather than relying on the judgment of one lead agent.
Treat Scale as an Experimental Variable, Not a Deployment Goal
Deployment constraints should not be obscured by the fact that Agensh is open source or has a single-node default. The repository describes a Linux and Docker Compose setup with eight workers on one node. The reported Pandoc run with 1,024 agents used 16 nodes, with 64 agents per node, a 64 GiB memory ceiling per worker, and input and output token limits for each worker. A single-node reproduction guide is not the same as a complete reproduction of that distributed run, so their infrastructure conditions should not be conflated.
For engineering teams, the safer approach is to measure a scaling curve on representative tasks while tracking final quality, time to target, model and infrastructure consumption, and rework caused by claim collisions or failed merges. The public evidence shows that Agensh can scale to a large team on specific benchmarks and configurations, with gains on some measures. It does not establish that scale itself creates quality, nor does it provide the matched comparisons needed to judge unit cost or general advantage. The first element worth adopting is the explicit collaboration protocol. The number of agents should follow from task decomposability and measured returns.