I’ve been reading a very insightful agent-swarm article from Cursor recently:

https://cursor.com/zh-Hant/blog/agent-swarm-model-economics…

The core idea is actually not complicated:

“Turn a big task into a tree”

At the top is the Planner, responsible for understanding goals, breaking down tasks, and making architectural decisions.

Below are Workers, responsible for executing specific small tasks.

The Planner doesn’t write code, and the Worker doesn’t need to understand the entire project.

This is the first level of control: context isolation.

The most common problem with a single Agent is:

It looks at the global goal while diving into local implementation.

The context keeps growing, and eventually it either forgets the global picture or breaks the local implementation.

Cursor’s approach is to let the Planner maintain the global perspective and let the Worker handle only a small, well-defined piece of work.

The second level of control is ownership isolation.

Each Worker works in its own copy of the code, and after finishing, only submits a handoff:

what was done, what was discovered, and what risks remain.

They don’t need to chat with each other; instead, they report upward through the Planner.

The third level of control is writing collaboration information into the environment.

For example, design decisions, shared documents, and a Field Guide.

The next Agent doesn’t need to read all the history; it just reads the key experiences that have already been distilled.

This is somewhat like ants collaborating through the environment, rather than all ants having meetings with each other.

The fourth level of control is handling conflicts specifically.

If there’s a Planner conflict, merge the design decisions.

If there’s a code conflict, have a neutral Agent handle it.

If a file is too large, pause the commit and split the module.

It’s not about letting all Agents do whatever they want and then praying they can merge in the end.

What did this structure ultimately bring?

In the SQLite reconstruction experiment, Cursor claims that the new Agent Swarm using Grok 4.5 reached about 80% test pass rate in 4 hours, while the old version lost control and had to be paused before 2 hours.

So the core of Agent Swarm is not:

“Launch 1000 Agents simultaneously.”

But rather:

“How to make each Agent only know what it needs to know, only be responsible for what it needs to be responsible for, and hand the results back to the correct control layer.”

This is actually very similar to a recursive management system:

The Planner manages sub-Planners. Sub-Planners manage Workers. Workers are responsible for specific execution. Testing and Review are responsible for feedback.

This set of control structures is worth learning:

Context isolation, task ownership, structured handoff, independent review.

Concurrency is just the surface.

What truly makes Agent Swarm powerful is the control algorithm.

#AIAgent #Cursor #VibeCoding

Agent Swarm and the New Model Economics

Source: https://cursor.com/zh-Hant/blog/agent-swarm-model-economics Earlier this year, we ran a series of experiments to test the limits of scaling agents to collaborate toward a common goal. Our hypothesis was that this would unlock new levels of task size and complexity.

The flagship project was a long-running agent swarm that built a browser from scratch (https://cursor.com/blog/scaling-agents). It was successful as a proof of concept, but there was still a large gap to a mature, polished piece of software.

That work was deliberately empirical. We started from a blank canvas and worked our way toward a stable and effective system (https://cursor.com/blog/self-driving-codebases). Since then, our goal has been to understand agent swarms well enough to engineer them intentionally.

To validate this progress, we went back to a task that an older version of the agent swarm struggled with: building SQLite from scratch in Rust, based solely on its documentation.

Our initial results are very encouraging. We ran the old and new agent swarms on the same task, using the same models and the same time budget, and measured how many of a reserved SQL test suite they could pass.

The new agent swarm performed better in every model configuration. With Grok 4.5, it reached 80% in four hours, while the old agent swarm gradually lost control and had to be paused before the second hour.

We also varied which models handled which work. In some runs, a single model handled everything; in others, a frontier model handled planning, while fast, low-cost models handled execution. Every combination produced similar quality, but the cost varied wildly. 1 (https://cursor.com/zh-Hant/blog/agent-swarm-model-economics#fn-1)

Cost of rebuilding SQLite by model combination under old and new agent swarmsCost of rebuilding SQLite by model combination under old and new agent swarms

https://cursor.com/zh-Hant/blog/agent-swarm-model-economics#trees-and-leaves

The description of a large task naturally takes a tree shape: the root is the goal, and it is recursively broken down into atomic work units. Our agent swarm has two roles, both organized along the same tree decomposition:

• Planning agents, driven by the most capable models, split goals into parts and delegate them.
• Worker agents, usually driven by faster, cheaper models, execute those parts.

This design covers a wider range than rigid orchestration systems. Instead of imposing a fixed topology on the problem, the agent swarm naturally expands along the contours of the problem, scaling compute and context proportionally with task complexity.

We believe this is why the design generalizes to vastly different tasks like building a browser (https://cursor.com/blog/scaling-agents), solving math problems (https://x.com/mntruell/status/2028903020847841336), and optimizing GPU kernels (https://cursor.com/blog/multi-agent-kernels). We’ve also used it internally to find and fix vulnerabilities in open-source software, improve test coverage in our own codebase, and generate billions of tokens of synthetic training data.

https://cursor.com/zh-Hant/blog/agent-swarm-model-economics#what-the-tree-means-for-memory

When a single agent takes on a complete task, it must walk the entire tree itself, going down to every leaf node, while always keeping ancestor nodes, its current position, and the broader overall goal in context.

We believe this explains why long-running single agents tend to drift. They either focus on the immediate task and lose sight of the big picture, or they try to maintain the global perspective and do a poorer job on the local parts.

In the agent swarm, the planner is never the implementer, so its context doesn’t get filled with low-level details; the worker is never the planner, so it can devote its entire context to a small, well-defined piece of work.

Diagram of task decomposition between planning agents and worker agents in the task treeDiagram of task decomposition between planning agents and worker agents in the task tree

We suspect that the scalability of agent swarms comes more from this context efficiency than from parallelism alone. This efficiency exists at any scale of the swarm, which is why this decomposition improves agent performance even for moderate-sized tasks.

This structure has parallels elsewhere. Economist Ronald Coase, when asking why firms exist, argued (https://en.wikipedia.org/wiki/The_Nature_of_the_Firm) that coordination costs grow faster than the work itself, so organizations naturally form hierarchical units with boundaries, rather than having everyone communicate with everyone.

https://cursor.com/zh-Hant/blog/agent-swarm-model-economics#a-version-control-system-for-agents

In a previous article on agent swarms (https://cursor.com/blog/self-driving-codebases), we mentioned that tools like Git and Cargo rely on coarse-grained locking for concurrency control. This is fine for a single developer, but completely breaks down for the scale of work produced by hundreds of concurrent agents.

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

To support this speed, we built a new version control system (VCS) from scratch. Throughput is not the only reason we took control of this layer. Every change in the system goes through the VCS, so conflicts surface there first, and several coordination mechanisms described in the next section are implemented directly within it.

https://cursor.com/zh-Hant/blog/agent-swarm-model-economics#failure-modes-at-1000-commits-per-second

Human engineering teams have a standard set of coordination mechanisms, such as code review, ownership, standups, and merge queues. These work well at human pace, but at the commit rate of a swarm, we see failure modes rarely encountered by human teams.

https://cursor.com/zh-Hant/blog/agent-swarm-model-economics#brain-split-design

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

We fixed this by adjusting the prompts. Planners make design decisions themselves rather than delegating them, and we require them to ensure that no two delegated subtrees make decisions about the same problem.

https://cursor.com/zh-Hant/blog/agent-swarm-model-economics#planner-vs-planner-conflicts

A more insidious conflict is when two planners are aware of each other but still modify the same set of files back and forth, pulling in opposite directions.

The problem is that both parties have two different understandings of reality, and a merge tool cannot fix this divergence. Instead, we have agents record decisions in shared design documents. Code that depends on a decision includes a compile-time checked reference back to the corresponding document. When planners unknowingly contradict each other, a coordinator merges these documents, and the references propagate the resolution downstream.

https://cursor.com/zh-Hant/blog/agent-swarm-model-economics#merge-conflicts

In this agent swarm, agents frequently conflict on the same file. To resolve such conflicts, they would have to pause their own work, absorb the context of the other agent, and complete the merge on that basis. Worker agents are not good at handling this; they often either overwrite the other’s changes or abandon their own.

To fix this, we built a system where a neutral third-party agent intervenes when a merge conflict occurs and resolves the conflict on behalf of all parties. Its sole goal is to remain impartial and efficient, similar to how a merge queue operates in an engineering team.

https://cursor.com/zh-Hant/blog/agent-swarm-model-economics#bloated-files

Some files are particularly prone to becoming focal points for agents. Each agent might only add a small amount of code, and no single agent is responsible for keeping these files lean.

These “bloated files” drag everything down. They are expensive to transfer, diff, and merge, and they become hotspots for conflicts.

To fix this, we allow worker agents to flag bloated files. Once flagged, we block new commits and have an external agent split the overgrown file into smaller modules.

https://cursor.com/zh-Hant/blog/agent-swarm-model-economics#ossification

Agents working with humans in an existing codebase have learned: even if core code needs to change, don’t touch it.

To solve this, we allow intentional breaking changes. If an agent determines that a core change is worthwhile, it can submit a targeted patch outside its own scope, along with a comment explaining why.

The compiler propagates this change to the rest of the system, and everything that depends on the old design fails to build. Every agent encountering these errors finds the comment, reads the rationale, and updates its own part to align.

https://cursor.com/zh-Hant/blog/agent-swarm-model-economics#review-perspectives

In a system that is both long-running and multi-agent, errors accumulate, so the swarm needs a mechanism to self-correct before small mistakes become fundamental problems.

We tried many different types of review perspectives, such as having a review agent look at the full conversation history of the worker, only its output, or nothing beyond the codebase. We also tried running reviewers on different models, with different training and different personalities.

No single perspective catches everything, but decorrelated perspectives can be stacked; much like how autonomous driving systems don’t rely on any single perfect component yet still achieve superhuman reliability. Compute spent on review has high returns because review costs are much lower than the work it audits. We suspect this stacked review system is a major factor in the sustained quality of these runs over long periods.

https://cursor.com/zh-Hant/blog/agent-swarm-model-economics#letting-agents-shape-the-environment

Stigmergy (https://en.wikipedia.org/wiki/Stigmergy) is the mechanism by which social insects like ants and termites coordinate without direct communication. They shape the environment, and the environment in turn influences the next individual.

In our previous runs, we added rules like “keep notes” and “record decisions” because these practices were clearly good. In hindsight, this was about having agents crystallize knowledge for themselves and their teammates.

We pushed this idea further with an experiment where agents write and share context themselves, called the Field Guide. This is a fully agent-managed folder, whose index.md is automatically injected at the startup of every agent. The agents’ job is to curate content for this guide, with the only constraint being a line budget.

The logic behind this guide is: model weights are frozen, so what is truly worth recording are the unexpected situations, allowing the next agent to have a shorter trajectory.

The Field Guide is an early-stage experiment with promising results. We expect these benefits to be even more pronounced in codebases that agents cannot fully grasp. Training models to write for successors, letting better information sediment lead to better feedback, would be an interesting follow-up research direction.

https://cursor.com/zh-Hant/blog/agent-swarm-model-economics#the-sqlite-experiment

We instructed the new version of the agent swarm, equipped with all the above improvements, to implement the entire 835-page SQLite manual in Rust. We provided no source code, test suite, SQLite binary, or internet access.

To measure progress, we used sqllogictest (https://www.sqlite.org/sqllogictest/doc/trunk/about.wiki) as the scoring metric. This is a test suite created by the SQLite project to check that different database engines return the same results for the same queries. It contains millions of queries with known correct answers, and the score is the proportion that the swarm’s database answers correctly. Progress appears as a continuously rising curve during each run.

The system was never told about this suite. After each run, we manually reviewed the code and the entire run process to check for cheating or shortcuts, and to confirm that the system’s construction was evenly spread, not just concentrated on the parts the test would check.

When reading these curves, keep in mind that agents choose their own strategies. Some lay a broad foundation first, scoring low for the first few hours before a steep late rise; others dive deep into one area, scoring early, then level off as they fill in the rest. The trend matters more than the exact score at any given moment.

https://cursor.com/zh-Hant/blog/agent-swarm-model-economics#results-by-model-combination

We tested four configurations spanning capability and cost:

1. GPT-5.5 as both planner and worker. Using the powerful frontier model throughout. 2 (https://cursor.com/zh-Hant/blog/agent-swarm-model-economics#fn-2)
2. Grok 4.5 as both planner and worker. Our cost-effective frontier model, serving as a baseline for comparison.
3. Opus 4.8 as planner, Composer 2.5 as worker. Frontier judgment paired with efficient execution.
4. Fable 5 as planner, Composer 2.5 as worker. To see whether a lower-tier planner makes this hybrid mix more or less worthwhile.

The new test framework outperformed the old one in every combination.

The Fable 5 hybrid mix passed about two-thirds of the test suite in the first hour. By the four-hour cutoff, the new runs yielded results between 73% and 85%, while the old runs were between 11% and 77%.

The old Grok 4.5 run was paused before reaching two hours (detailed below). All new configurations eventually passed 100% of the test suite.

In the future, we hope to run a full planner-worker N×N combination matrix. In this round, the important comparison was between test framework versions, and the behavioral differences that ultimately emerged were far greater than the score differences suggest.

SQLite test suite scores over time for GPT-5.5 under old and new agent swarmsSQLite test suite scores over time for GPT-5.5 under old and new agent swarms

SQLite test suite scores over time for Grok 4.5 under old and new agent swarmsSQLite test suite scores over time for Grok 4.5 under old and new agent swarms

SQLite test suite scores over time for Opus 4.8 planner with Composer 2.5 workerSQLite test suite scores over time for Opus 4.8 planner with Composer 2.5 worker

SQLite test suite scores over time for Fable 5 planner with Composer 2.5 workerSQLite test suite scores over time for Fable 5 planner with Composer 2.5 worker

https://cursor.com/zh-Hant/blog/agent-swarm-model-economics#deep-dive-into-these-runs

Starting with the most basic activity metric, we can see the difference in commit rate between Grok 4.5 under the old test framework versus the new one. The old run produced 68,000 commits in the first two hours, about 70 times faster than the new run.

One interpretation is that its output was higher; another is that most of these commits were just busywork (thrashing, contention, back-and-forth changes).

Cumulative commits over active minutes for Grok 4.5, old vs new test frameworkCumulative commits over active minutes for Grok 4.5, old vs new test framework

The merge conflict data strongly supports the latter interpretation. The old run accumulated over 70,000 conflicts before we paused it, and it was accelerating, not stabilizing; in contrast, the new run recorded fewer than a thousand conflicts over the full four hours.

Cumulative merge conflicts over time for Grok 4.5, old vs new test frameworkCumulative merge conflicts over time for Grok 4.5, old vs new test framework

Conflicts were concentrated in the files that grew largest. In the old run, the largest file ballooned over the entire run, and the single most conflicted file accumulated 7,771 conflicts, touched by 1,173 unique agents. In the new run, the most contended file in the entire codebase saw only 47 conflicts.

Size (in lines of code) of the hottest file over run progress for Grok 4.5, old vs new test frameworkSize (in lines of code) of the hottest file over run progress for Grok 4.5, old vs new test framework

The biggest coordination failure of the old agent swarm—brain split, where planners duplicated each other’s work—was reflected in the package structure. Rust code is organized into packages called crates; in a project like this, each crate roughly corresponds to a major component.

The old run ballooned to 54 crates, including three independent SQL packages. The new run converged early to nine crates and never added more.

Number of Rust crates over time for Grok 4.5 SQLite run, old vs new test frameworkNumber of Rust crates over time for Grok 4.5 SQLite run, old vs new test framework

All of this ultimately reflected in the final codebase. For the Fable 5 combination, both old and new swarms eventually passed the full test suite, but the old one required 64,305 lines of engine code, while the new one used only 9,908 lines. The Opus combination showed the same trend: 19,013 lines for 97% under the old framework, 4,645 lines for 100% under the new one.

Engine code lines needed to complete the SQLite experiment, old vs new test frameworkEngine code lines needed to complete the SQLite experiment, old vs new test framework

https://cursor.com/zh-Hant/blog/agent-swarm-model-economics#model-economics

We mentioned earlier that each model combination produced similar quality, but the cost varied enormously, from $10,565 for Opus 4.8 hybrid. The token data shows where this difference comes from.

The cost structure of each run was consistent: workers accounted for at least 69% of tokens, and in most cases over 90%.

But the dollar cost distribution is not the same as token distribution, because planner tokens are more expensive. In the Opus 4.8 with Composer 2.5 combination, Opus as planner used a small number of tokens but accounted for about two-thirds of the total cost; Composer as worker handled the vast majority of tokens but only accounted for the remaining third.

Token usage by model role (planner vs worker) for SQLite agent swarm configurationsToken usage by model role (planner vs worker) for SQLite agent swarm configurations

In large tasks, there are actually few moments that truly require frontier intelligence: the initial decomposition, design decisions, and certain trade-offs. Once the frontier planner converges ambiguity into detailed, explicit instructions, cheaper models can simply follow them. This is a huge potential source of cost savings. In the run using GPT-5.5 as both planner and worker, the worker cost alone was $411.

Another notable detail comes from comparing the two hybrid runs. The Fable 5 planner’s bill was slightly lower than the Opus 4.8 planner, even though its token price is about double, because it used far fewer planning tokens. But the Fable run’s worker consumed several times more tokens, making the overall run significantly more expensive.

https://cursor.com/zh-Hant/blog/agent-swarm-model-economics#spec-as-prompt

Every leap in AI capability has raised the level of abstraction at which engineers can work.

Autocomplete let engineers work line by line. Early models raised that to a code block, and agents raised it to a file or a feature.

With agent swarms, the unit of work becomes a specification.

To do this, the swarm must actually follow the specification, which is what most of this article has been about. We gave the swarm 835 pages of text, and it gave us back a database. The scarce resource in this experiment, and what we expect will continue to be scarce in software engineering going forward, is a good enough description of intent.

Seen this way, the agent swarm starts to resemble a compiler. A compiler translates source code through a series of intermediate steps into machine code. The agent swarm does something similar for intent. The planner parses the goal into a task tree, then refines it step by step into executable work. The difference is that a compiler preserves semantics at every step, while every step of the agent swarm is probabilistic. Everything described in this article is aimed at narrowing that gap.

We invite you to explore the results of the agent swarm. The codebase from the solo Opus 4.8 run is publicly available at github.com/cursor/minisqlite (https://github.com/cursor/minisqlite). Based on our initial look, it seems pretty good, but we haven’t done a deeper manual analysis yet. Feel free to take a look yourself and tell us what you find.

1. To understand the cost of using frontier models alone, we also ran Opus 4.8 and Fable 5 standalone. We only did an informal evaluation of these runs, so we won’t draw any conclusions about their quality here, though based on experience we expect both models would perform well. Their costs are shown as hatched bars in the chart. ↩ (https://cursor.com/zh-Hant/blog/agent-swarm-model-economics#fnref-1)
2. We originally wanted to use GPT-5.6 Sol as the frontier configuration. This new model seemed more susceptible to literal phrasing and emphasis than the other models we tested, and we encountered runaway spirals that didn’t occur with other models. With such a recent model release, we didn’t have enough time to adjust the prompts; and tuning for only one model while leaving others unchanged would have skewed the comparison, so we switched to GPT-5.5. ↩ (https://cursor.com/zh-Hant/blog/agent-swarm-model-economics#fnref-2)