Agent swarms and the new model economics

Earlier this year, we ran experiments to test the limits of scaling agents to cooperate toward a goal. Our hypothesis was that this would unlock a new tier of task scale and complexity.

The flagship project was a long-running swarm building a web browser from scratch. It succeeded as a proof of concept, but fell far short of polished software.

That work was deliberately empirical. We started from a blank canvas and hill-climbed toward a stable, effective system. Since then, our goal has been to understand the agent swarm well enough to engineer it deliberately.

To test that progress, we returned to a task the old swarm had struggled with: building SQLite from scratch, in Rust, from nothing but its documentation.

Our initial results have been promising. We ran the old and new swarms on the same task, with the same models and the same time budget, and measured how much of a held-out SQL test suite each could pass.

The new swarm did better in every model configuration. Using Grok 4.5, it reached 80% in four hours, while the old swarm spiraled and had to be paused before its second hour.

We also varied which models did which jobs. In some runs, one model handled everything while in others, a frontier model planned while a fast, inexpensive model carried out the work. Every mix produced similar quality, but the costs varied enormously.1

Descriptions of large tasks naturally take the shape of trees, with a goal at the root that subdivides recursively into basic units of work. Our swarm has two roles, both organized around that same tree-like decomposition:

• Planner agents, powered by the smartest models, split a goal into pieces and delegate them.
• Worker agents, generally powered by faster and less expensive models, execute those pieces.

The design is a superset of more rigid orchestration systems. Rather than imposing a fixed topology on the problem, the swarm’s shape grows to cover the problem’s contours, and compute and context scale in proportion to the task’s complexity.

We think this is why the design generalizes to tasks as diverse as building a browser, solving math problems, and optimizing GPU kernels. We’ve also used it internally to find and fix vulnerabilities in open-source software, raise test coverage on our own codebase, and generate billions of tokens of synthetic training data.

When a single agent takes on a complete task, it has to walk the entire tree itself, descending to each leaf while holding its ancestors, its current position, and the wider goal in context the whole time.

We think this explains why long-running single agents drift. They can either focus on the work in front of them and lose sight of the bigger picture, or hold the big picture and do a worse job on the piece.

In a swarm, a planner never implements, so its context never fills with low-level detail, and a worker never plans, so it can spend all its context on one narrow piece of work.

We suspect the ability to scale the agent swarm comes from this context efficiency, more than from parallelism itself. That efficiency is present in the swarm at every scale, which is why this decomposition helps agent performance even on moderately sized tasks.

There are echoes of this structure elsewhere. The economist Ronald Coase, asking why firms exist at all, argued that coordination costs grow faster than the work itself, so organizations settle into tiers of bounded units rather than letting everyone talk to everyone.

In an earlier post about the swarm, we noted that tools like Git and Cargo rely on coarse locks for concurrency control. This is fine for one developer but unworkable for the volume of work produced by hundreds of concurrent agents.

The browser swarm from earlier this year peaked at roughly 1,000 commits per hour on Git. The new system peaks at around 1,000 commits per second.

To facilitate this rate of activity, we built a new version control system (VCS) from scratch. Throughput was not the only reason to own this layer. Every change in the system passes through the VCS, so it is where collisions first become visible, and several of the coordination mechanisms in the next section are implemented directly inside of it.

Human engineering teams have standard coordination mechanisms like code review, ownership, standups, and merge queues. Those systems work at human tempo, but at the commit-rate of the swarm, we see failure modes that human teams don’t routinely encounter.

Two planners, unaware of each other, implement the same concept in different ways in different parts of the codebase.

We fixed this through prompting. Planners make design decisions themselves rather than delegating them, and we require them to ensure that no two delegated subtrees decide the same question.

A harder form of contention is when two planners know about each other and fight through back-and-forth changes over the same files.

The problem is two pictures of reality, and merge tooling can't fix a disagreement. Instead, we have agents record decisions in shared design docs. Code that depends on a decision carries a compile-checked reference back to its doc. When planners unknowingly contradict each other, a reconciler merges the docs and the references propagate the resolution downstream.

Within the swarm, agents constantly collide on the same files. In order to resolve a collision they would have to stop, absorb the other agent's context, and merge around it. Worker agents are bad at this and, in practice, either overwrite the other change or abandon their own.

To fix this, we created a system where a neutral third-party agent intervenes on merge conflicts and resolves them on behalf of all parties. Its only goal is to be impartial and efficient, similar to the way merge queues work in engineering teams.

Some files are particularly popular places for agents to work. Each agent might add only a small amount of code, and no single agent is responsible for keeping the files small.

These “megafiles” choke everything. They’re expensive to transport, diff, and merge, and become the site of constant collisions.

To fix this, we gave worker agents a way to flag bloated files. Once flagged, we block new commits and an outside agent decomposes the overgrown file into smaller modules.

Agents have learned, from working in existing codebases with humans in the loop, not to touch core code even when it needs to change.

To fix this, we license intentional breakage. An agent that judges a core change worthwhile can make a focused patch outside its scope and leave a comment explaining why it did it.

The compiler carries the change through the rest of the system, and everything depending on the old design fails to build. Each agent that hits one of those errors finds the comment, reads the reasoning, and updates its own piece of work to match.

In a system that is both long-running and multi-agent, errors accumulate, and the swarm needs a way to correct itself before small mistakes become foundational.

We experimented with many kinds of review lenses, such as giving a review agent the worker's full transcript, or only its output, or nothing but the codebase. We also tried reviewers running on different models, with different training and a different personality.

No single lens catches everything, but decorrelated lenses stack, the way self-driving systems reach above-human reliability without any single perfect component. The compute spent on review is high return, since review is much cheaper than the work it audits. We suspect this stacked review system was a major contributor to the sustained quality of the runs.

Stigmergy is the mechanism by which swarm organisms like ants and termites coordinate without direct communication. They shape the environment, and the environment shapes the next organism.

We had encoded rules like “keep notes” and “document decisions” in earlier runs because they seemed obviously good. In retrospect, they were letting agents institutionalize.