Cursor Agent Swarm Reaches 80% Test Pass Rate Building SQLite in Rust Through Tree Decomposition

Cursor says its agent swarm reached an 80% test pass rate while building SQLite in Rust within four hours. The system used tree decomposition, assigning planning and implementation to different agents. Its previous swarm became trapped in conflicts and was stopped before completing its second hour.

The result matters because Cursor did not simply place more coding agents inside one repository. It changed how those agents divide work, preserve architectural decisions, resolve collisions, and review accumulated code. The experiment therefore tests orchestration as much as model intelligence.

Cursor’s earlier swarm had already built a browser engine from scratch. That project produced working software, but Cursor acknowledged that it remained far from polished. The SQLite experiment asks a sharper question: can a structured swarm preserve coherence while hundreds of agents modify one tightly coupled system?

That question remains open. Cursor conducted and graded the experiment, and no independent audit has confirmed the headline result. An 80% score against one SQL test suite also does not establish full SQLite compatibility, production safety, or equivalent performance.

Still, the comparison offers unusually concrete evidence about a growing problem in AI software development. Adding agents increases output, but it also multiplies disagreements. Cursor’s answer is to give planning, execution, reconciliation, and review distinct places in a controlled hierarchy.

Cursor’s Agent Swarm Reached 80% Building SQLite in Rust

The important change was not a larger swarm, but a swarm organized to prevent local decisions from overwhelming the whole project.

Cursor published the results on July 20, 2026, after returning to a task that had defeated its previous system. The assignment was to recreate SQLite in Rust using the database’s documentation as the specification.

According to Cursor’s swarm experiment, the agents received the 835-page SQLite manual. They did not receive SQLite’s source code, executable binary, test suites, or internet access. Cursor says this separation prevented direct copying and reduced opportunities to optimize against visible tests.

The team evaluated the resulting database with sqllogictest. This framework runs SQL statements against multiple database engines and compares their results with known answers. The test framework contains millions of queries covering a broad range of SQL behavior.

The swarm did not know which tests Cursor would use. After each run, Cursor says its researchers inspected both the code and agent activity for shortcuts. They also checked whether implementation work covered the system broadly instead of targeting likely test cases.

Under those conditions, a new Grok 4.5 swarm reached an 80% SQL test pass rate after four hours. The older Grok-based swarm was stopped before two hours because its coordination failures were accelerating.

The four-hour mark was not the final ceiling. Across four model configurations, the new runs scored between 73% and 85% at that cutoff. Cursor says every new configuration eventually reached 100% on the held-out suite.

Those later results make the title’s 80% figure a progress marker, not the experiment’s highest reported score. It remains useful because it compares the same model under two orchestration systems within a fixed period.

Cursor tested four arrangements. Two used one model for both planning and implementation. Two paired a frontier planning model with a faster worker model.

The new swarm outperformed the old harness in every tested arrangement. That consistency supports Cursor’s main claim that system design influenced performance beyond model choice.

However, the evidence comes from Cursor’s own benchmark process. The company has released one generated implementation through the MiniSQLite repository, but it has not published every run as a complete reproducibility package.

The repository lets outside developers inspect at least one output. It does not reproduce the entire experiment, including infrastructure, prompts, model snapshots, hidden grading data, and manual review decisions.

That distinction matters. Cursor has reported a compelling internal result, not an independently established replacement for SQLite.

Tree Decomposition Changed the Coordination Model

Tree decomposition gave the swarm a chain of responsibility, separating global judgment from narrow implementation work.

Cursor’s design begins with a root objective. Planner agents divide that objective into smaller branches, then delegate each branch recursively. Worker agents operate at the leaves, where tasks should be narrow enough for direct implementation.

A planner does not write production code. Its context remains focused on requirements, dependencies, architectural choices, and task boundaries. A worker does not redesign the whole system. It receives a limited assignment and uses its context on that assignment.

This structure attacks a familiar failure mode in long-running agents. A single agent must remember the original goal while handling a growing volume of implementation detail. As its context fills, it can lose either local precision or global direction.

Parallel agents do not automatically solve that problem. Without coordination, they can reproduce the same feature, choose incompatible interfaces, or overwrite one another’s work. More parallelism then creates more repair work.

Tree decomposition limits which agents can make each class of decision. Cursor requires planners to settle shared design questions rather than delegating them to independent workers. It also asks planners to avoid assigning the same architectural choice to multiple branches.

That division turns an unstructured crowd into a hierarchy. The system still uses many agents, but they do not all have equal authority over every part of the project.

The new swarm also records important decisions in shared design documents. Code depending on those decisions carries compile-checked references back to the documents. When two planners contradict each other, a reconciliation agent can merge the decisions and propagate the resolution.

This mechanism addresses what Cursor calls split-brain design. Split-brain occurs when separate planners implement different versions of the same concept across a codebase. Each version can look reasonable locally while making the overall system inconsistent.

The SQLite runs exposed the difference. The old Grok swarm expanded to 54 Rust crates, including three separate SQL packages. A crate is Rust’s package unit, usually representing a library or major component.

The new swarm settled on nine crates early and did not add more. That smaller structure does not automatically mean better software, but it indicates that the planners converged on one architecture.

Cursor argues that context efficiency mattered more than raw concurrency. Each planner retained a higher-level view, while each worker received enough context to execute one bounded task. The hierarchy scaled context alongside task complexity.

This resembles a compiler pipeline. A high-level specification passes through intermediate representations until it becomes executable output. Cursor’s swarm transforms intent into task trees, implementation assignments, reconciled changes, and reviewed code.

Unlike a compiler, every transformation remains probabilistic. A planner can misunderstand the specification. A worker can misread its assignment. A reviewer can approve an incorrect implementation.

The surrounding controls exist to reduce those errors. They cannot make the process deterministic.

For engineering teams, the practical lesson is broader than this benchmark. Agent performance depends on whether requirements, decisions, and exceptions remain available at the right scope. A searchable knowledge base serves a similar purpose for human-led work.

The Cursor agent swarm reached an 80% test pass rate building SQLite in Rust because the hierarchy narrowed what each agent needed to know. The result points toward orchestration as a central engineering discipline for autonomous coding.

The Old Swarm Produced Activity, Not Stable Progress

Cursor’s comparison reverses a common assumption: a higher volume of agent activity can signal coordination failure rather than productivity.

The old Grok 4.5 run generated 68,000 commits during its first two hours. Cursor reports that this was roughly 70 times the new run’s pace. On a superficial dashboard, the old swarm would have looked dramatically more active.

The surrounding evidence tells a different story. The old system accumulated more than 70,000 merge conflicts before Cursor stopped it. The new run recorded fewer than 1,000 conflicts across four hours.

Conflict frequency also accelerated in the old run. Agents were not merely encountering a fixed integration backlog. They were creating disagreements faster as the repository changed.

One file became a particularly severe bottleneck. Cursor says 1,173 agents touched it, producing 7,771 conflicts. The most contested file in the new run saw 47 conflicts.

These numbers describe coordination collapse. Workers repeatedly entered the same area without shared ownership, stable boundaries, or an efficient way to incorporate concurrent changes.

Ordinary Git workflows were not designed for that tempo. Human teams rely on pull requests, code ownership, review queues, and conversations. Those mechanisms become impractical when automated workers generate changes continuously.

Cursor says its earlier browser swarm peaked near 1,000 commits per hour using Git. The new infrastructure can peak around 1,000 commits per second. To handle that load, the company built a dedicated version control system from scratch.

The system does more than store patches. It becomes the layer where collisions appear and where specialized agents can intervene.

When two workers edit overlapping code, Cursor does not expect either worker to absorb the other’s full context. A neutral merge agent resolves the collision on behalf of both parties. Its assignment is integration, not feature ownership.

The swarm also watches for “megafiles,” which attract changes from too many workers. Once agents flag an overgrown file, the system blocks additional commits while another agent separates it into smaller modules.

That response is important because file structure becomes coordination infrastructure. A modular boundary does not only improve readability. It reduces the number of workers competing over the same artifact.

Cursor also found that agents tended to avoid modifying core code. Coding models have learned conventions favoring small, nonbreaking patches, especially inside existing repositories.

That caution can preserve a flawed foundation. Cursor therefore allows an agent to make a focused breaking change outside its assigned scope when the core design requires revision.

The agent leaves an explanation beside the change. Compiler failures then direct affected workers toward that explanation, allowing them to update dependent code.

This approach uses Rust’s type system as a coordination channel. The compiler exposes incompatible interfaces quickly and provides actionable errors. Those errors help agents discover where a global decision has invalidated local assumptions.

An independent architecture critique of earlier swarm experiments identified this exact challenge. Individually capable agents can make locally reasonable choices that fail to compose globally. Shared model behavior creates correlation, not coordination.

Cursor’s new architecture appears designed as an answer to that criticism. It adds global decision authority, persistent design records, specialized reconciliation, and automated enforcement.

That makes the term “swarm” slightly misleading. The design is not a collection of independent peers whose coordination simply emerges. It is a managed organization with hierarchy, rules, records, and enforcement.

The distinction does not weaken the experiment. It explains why it performed better.

Review and Shared Memory Kept Errors From Compounding

Tree decomposition creates clean assignments, but sustained progress depends on finding mistakes before other agents build upon them.

Long-running software work compounds early errors. A mistaken interface can spread into dozens of modules. A temporary workaround can become an assumed requirement. A weak abstraction can attract more code until replacing it becomes expensive.

Cursor used multiple review agents with different views of the work. Some reviewers received a worker’s transcript. Others saw only its output or inspected the surrounding repository without the worker’s reasoning.

No single view caught every defect. A transcript can explain intent but also bias a reviewer toward the original approach. Output-only review provides distance but can miss why a decision was made.

Cursor says combining decorrelated review perspectives improved sustained quality. The company believes review consumed worthwhile compute because checking existing work was cheaper than recreating failed branches.

That claim remains difficult to isolate from the other changes. Cursor altered task decomposition, version control, merge handling, architecture records, and review behavior together. The experiment does not show how much improvement came from each component.

The swarm also maintained a shared Field Guide. This agent-owned folder stored lessons that future workers should know. Its index was inserted into each agent’s context when that agent started.

Cursor imposed a line limit, forcing agents to curate rather than accumulate everything. The system favored surprising discoveries that could shorten a later worker’s path.

This is a form of stigmergy, meaning coordination through changes to a shared environment. Ant colonies leave signals that influence later behavior. Cursor’s agents leave documentation, code references, compiler errors, and operational notes.

The Field Guide addresses a basic limitation of model-based agents. Model weights remain fixed during a run. Without an external record, one worker’s discovery disappears when its context ends.

Persistent notes do not guarantee accurate memory. Agents can record incorrect conclusions, retain obsolete workarounds, or give excessive importance to unusual cases. The guide therefore requires maintenance and review like any other shared artifact.

The same challenge appears in human engineering organizations. Teams need a record of architectural decisions, implementation constraints, and unexpected behavior. Otherwise, each contributor repeats the same investigation.

Tools designed for engineering workflows can help humans preserve that context. Cursor’s experiment suggests autonomous teams need an even stricter version because their personnel turns over continuously.

The code metrics imply that these controls affected coherence. In one model pairing, the old swarm needed 64,305 lines of engine code to pass the full suite. The new swarm passed it with 9,908 lines.

Another pairing produced 19,013 lines and a 97% score under the old harness. The new harness reportedly reached 100% with 4,645 lines.

Fewer lines do not always mean better software. Compact code can hide missing safeguards, narrow assumptions, or incomplete features. Here, however, both test performance and architectural concentration moved in the same direction.

The swarm’s output also differed across strategies. Some runs built broad foundations and scored poorly for hours before improving sharply. Others implemented narrow SQL features early, then plateaued while filling gaps.

This variation shows why one score at one moment can mislead. Cursor advises focusing on overall curves rather than treating every intermediate percentage as a direct productivity ranking.

The Cursor agent swarm reaching an 80% test pass rate building SQLite in Rust therefore reflects more than parallel implementation. Review and persistent shared memory helped prevent early errors from becoming permanent architecture.

An 80% SQL Score Is Not Production-Ready SQLite

The benchmark supports a coordination claim, but it does not establish that the generated database matches SQLite’s reliability, compatibility, or security.

Sqllogictest checks whether database engines return expected results for large collections of queries. That makes it useful for measuring broad SQL semantics. It does not cover every property that production users expect from SQLite.

SQLite’s own testing program includes multiple test harnesses, extensive boundary checks, fault simulation, fuzzing, and long-term regression infrastructure. Correct query results represent one part of that assurance process.

A database must also preserve data during crashes, maintain transaction guarantees, handle corrupted files safely, and behave consistently across platforms. It must manage concurrency, resource limits, unusual encodings, and malformed inputs.

Performance matters too. A logically correct query engine can still be unusable if it consumes excessive memory or performs poorly under realistic workloads.

Cursor did not claim that its generated project was ready to replace SQLite. Its article frames the work as an experiment in swarm organization and model economics. That narrower interpretation fits the available evidence.

The 80% score also came from a four-hour checkpoint. Cursor says every new configuration later reached 100% on the held-out suite, but passing one suite can expose new questions.

How many independent runs produce comparable results? Does a successful architecture survive changes to the specification? Can the swarm extend its own implementation without reintroducing split-brain behavior?

Reproducibility is particularly important. Model outputs vary with prompts, sampling, infrastructure, and model updates. A benchmark that succeeds once does not tell teams how often the method fails.

Cursor compared old and new harnesses using the same model configurations and time budgets. That controls several variables. Yet the company has not provided enough public material for outsiders to rerun the entire evaluation independently.

Manual inspection introduces another uncertainty. Cursor says researchers checked for cheating, shortcuts, and uneven implementation. Those checks are valuable, but unpublished review criteria are difficult to evaluate.

The experiment also benefits from Rust. Its compiler and type system catch incompatible interfaces before execution. Cursor explicitly uses compiler errors to propagate architectural changes across dependent components.

A similar swarm working in a dynamic language might receive less immediate feedback. Some disagreements would surface only at runtime, while others might remain hidden until unusual production inputs appear.

SQLite is also unusually well specified. The swarm received hundreds of pages describing expected behavior, and a mature external test framework could score its output.

Many commercial systems lack those advantages. Requirements remain scattered across tickets, conversations, dashboards, and undocumented operational knowledge. Their success criteria can be subjective or contradictory.

This means the experiment may reveal a condition for effective agent swarms rather than a universal recipe. The better the specification and verification environment, the more safely the system can delegate implementation.

Security deserves separate caution. Cursor says it has used the architecture to find vulnerabilities in open-source projects. That is a company-reported application, not evidence that swarm-generated security patches are consistently safe.

Database engines process untrusted inputs and protect durable state. A subtle parser error, integer edge case, or transaction bug can remain invisible across millions of ordinary queries.

The right conclusion is measured. Cursor reports that its agent swarm reached an 80% test pass rate building SQLite in Rust under a constrained benchmark. The evidence does not support calling the output a production-grade SQLite implementation.

Model Choice Mattered Less Than Role Assignment

Cursor’s results suggest that frontier intelligence delivers the most value at decision points, while implementation consumes most of the total work.

The company tested systems where one advanced model handled both planning and execution. It also tested hybrid systems where a frontier model planned and a faster model implemented the resulting tasks.

All four new configurations eventually produced similar test outcomes. Their resource consumption differed substantially, especially between planning and worker roles.

Workers generated at least 69% of the tokens in every run. In most configurations, they generated more than 90%. That distribution makes sense because implementation contains many repetitive, localized actions.

Planning required fewer tokens but carried greater leverage. A planner chose the architecture, divided the specification, assigned ownership, and resolved ambiguity before workers began changing code.

A weak decision at that level can create thousands of unnecessary downstream actions. A good decision can turn an uncertain design problem into several explicit implementation tasks.

This pattern challenges the idea that every agent needs the most capable available model. If a planner reduces ambiguity effectively, many workers only need to follow bounded instructions and respond to compiler feedback.

The hybrid results also show that planner efficiency cannot be judged in isolation. One planner may use fewer tokens while producing assignments that force workers through longer implementation paths.

Teams therefore need to measure the whole trajectory. Planner quality includes the amount of downstream work, conflict, and revision its decisions create.

Cursor’s experiment turns model selection into an organizational design question. The best model for architectural judgment may differ from the best model for repetitive implementation, merging, testing, or review.

Specialization can also improve evaluation. A merge agent can be judged on clean integration. A reviewer can be judged on defects found. A planner can be judged on branch independence and downstream stability.

One general-purpose agent performing every role creates murkier feedback. When the project fails, teams cannot easily distinguish flawed planning from weak implementation or insufficient review.

The new system’s lower activity rate reinforces this interpretation. It produced fewer commits than the old swarm, but those commits encountered dramatically fewer conflicts and contributed to a more concentrated architecture.

The output metric should therefore be accepted, stable functionality rather than agent motion. Commit counts, token volume, and concurrent worker totals can all increase while useful progress declines.

This principle creates pressure for coding-agent vendors. Model access alone becomes less differentiating when orchestration determines whether output composes into maintainable software.

It also pressures enterprise buyers to change evaluation criteria. A short demonstration can show that an agent writes code. It cannot show whether a multi-agent system maintains decisions across hours of concurrent work.

Buyers should ask how the system represents architecture, assigns ownership, records reasoning, resolves conflicts, and validates completed branches. They should also ask what happens when the specification changes midway.

Cursor’s tree model provides one concrete answer. It places expensive judgment near the root and high-volume implementation near the leaves. Reconciliation and review operate between those layers.

That design resembles a software organization, but it runs at machine tempo. The striking part is not that agents replaced an engineering hierarchy. Cursor recreated hierarchy because unconstrained parallelism failed.

What to Watch After Cursor’s SQLite Experiment

The next test is whether Cursor can turn one controlled benchmark into repeatable performance on evolving, externally audited codebases.

The first signal is independent reproduction. Developers need the prompts, harness behavior, model identifiers, grading process, and several generated repositories. Repeated runs would reveal variance that one successful trajectory cannot show.

A reproduction does not need to recreate Cursor’s proprietary infrastructure exactly. It should test whether hierarchical planning consistently reduces conflicts and architectural duplication under comparable workloads.

The public MiniSQLite code offers a starting point. Outside reviewers can examine SQL coverage, unsupported behavior, unsafe assumptions, and module design. They can also compare its behavior with SQLite beyond the held-out suite.

Evidence of serious failures would not erase the coordination result. It would narrow the claim from database implementation to benchmark-directed functional synthesis.

The second signal is performance on changing specifications. Cursor’s experiment began with a large, stable manual. Real projects change while developers are implementing them.

A useful follow-up would modify requirements during a long run. The swarm would need to revise shared decisions, invalidate outdated tasks, and update dependent branches without returning to conflict-heavy churn.

That test would pressure the system’s design documents and Field Guide. Persistent memory helps only when the swarm can identify which memories are obsolete.

The third signal is broader language and repository coverage. Rust provides strong compile-time feedback, while SQLite offers mature specifications and measurable outputs.

A credible general system should sustain coherence in dynamic-language services, mixed-language applications, and existing repositories with inconsistent documentation. It should also handle operational requirements that cannot be reduced to query correctness.

Cursor says it has applied the architecture to browser construction, vulnerability repair, test coverage, GPU optimization, mathematics, and synthetic data generation. Detailed evaluations of those tasks would show whether tree decomposition generalizes.

The most valuable reports would include failed runs. Teams need to know when the hierarchy still breaks, which conflicts escape reconciliation, and how often reviewers approve locally correct but globally harmful work.

Another useful measure is human intervention. A swarm can appear autonomous while researchers repeatedly adjust prompts, stop loops, reinterpret requirements, or repair infrastructure.

Cursor disclosed that it paused the old Grok run and manually reviewed outputs. Future evaluations should quantify intervention across both successful and unsuccessful runs.

Maintenance will provide the hardest evidence. Building a new repository avoids legacy constraints, backward compatibility commitments, and years of accumulated design decisions.

If Cursor’s system can make a significant change to its generated database months later, while preserving behavior and architecture, the case becomes stronger. If it must regenerate large portions, the method looks more like synthesis than sustainable engineering.

For developers, the immediate takeaway is not to deploy thousands of coding agents. It is to treat orchestration, specifications, shared context, and automated verification as first-class parts of agentic development.

For engineering leaders, the key question is equally practical: can your organization express intent precisely enough for a hierarchy of agents to act without inventing incompatible assumptions?

Cursor’s agent swarm reached an 80% test pass rate building SQLite in Rust through tree decomposition, according to the company’s experiment. The result challenges the belief that better coding agents alone will unlock larger autonomous projects.

The emerging constraint is coordination. Watch whether independent reviewers can reproduce the result, whether the swarm survives changing requirements, and whether it works beyond Rust and unusually complete specifications. Those signals will determine whether Cursor built a durable engineering system or an impressive benchmark machine.