A Thousand AI Agents Without a Boss: What Is Known About the Agensh Experiment

On October 30, 2026, the MTS blog on Habr published a breakdown of a preprint (a scientific text before peer review) from Microsoft Research. In it, up to 1024 instances of a single model together reproduced the behavior of ready-made programs for six hours. There was no boss: no manager, no team lead, no distribution of subtasks.

What Exactly Was Launched

An AI agent is a model that receives a goal, calls tools and checks the result. Usually agents are connected by a hierarchy: the main one breaks down the task and distributes pieces to executors. Here the scheme is flat. The instruction says that everyone is equal and each decides for themselves.

This is not "communism" in the literal sense, but the absence of an orchestrator — a component that distributes work. A single agent hits the boundaries of its own context (the window that holds the history of work). It has one flow of actions and one memory. It works sequentially, so a complex task takes a lot of time. Dividing the task among agents is a way to reduce this time. But then they need to somehow agree on who does what.

Why Hierarchy Hits a Ceiling

Most multi-agent systems (systems of several agents) are arranged hierarchically. This is how subagents in Codex and Claude Code, agent teams in Claude Code, Copilot fleet and Kimi Agent Swarm work. The scheme has a limit: as the number of executors grows, the main agent plans, coordinates and merges other people's work more. It becomes a bottleneck.

The developers of such systems admit this too. In Anthropic's research system, the lead agent launches subagents synchronously and waits for each group to complete. This is easier to coordinate. An example from ordinary development: if you have ten executors and one dispatcher, the dispatcher becomes the bottleneck. The flat scheme tries to remove this node.

What the Swarm Showed and What Is Missing from the Numbers

The source says that the swarm showed a better result than a single agent. At the same time, it itself introduced reviewers (agents that check others' work), integrators (those who bring pieces into one result) and regulations. That is, the rules appeared along the way, without external assignment.

Then the caveats begin. The summary has no metrics: what exactly was considered "better", how many runs there were, how it was compared with a single agent. The preprint's name is given as Agensh — check against the primary source. The article's reach of 4.2K and reading time of 7 minutes refer to the article on Habr itself, not to the experiment. There are also no prices or token consumption in the summary.

Where the Trap of the Flat Scheme Is

Without a boss, agents must somehow divide the work. Exactly how — a queue, voting, random choice — is not described in the summary. There is no data. If two take one subtask, duplication results. If no one takes it, there is a hole in the result.

The regulations that the swarm introduced itself look like an attempt to close this. But who approved them, how compliance was checked and what happened in case of violation is unknown. Transferring the flat scheme to a real repository can only be done as a hypothesis: in ordinary development, a team without a team lead sometimes copes if the task divides well and there are tests. If it divides poorly, chaos begins.

What to Do About This

1. Read the preprint, not the retelling. Look at the metrics, the number of runs and the cost of model calls. This is not in the summary.
2. Do not drag the flat scheme straight into prod. First a hierarchy with a small number of executors, then experiments with the swarm.
3. Establish a rule for distributing tasks. Without it, the swarm may duplicate work or leave gaps.
4. Build in review and integration. In the source, the swarm itself introduced reviewers and integrators — which means this is a bottleneck.
5. Calculate the budget according to your own tariff. 1024 instances for six hours is a lot of model calls; there are no prices in the source.