AI Engineering Illustrated

Posted on Oct 14 Originally published at ragmehta.substack.com

How Cursor Got Thousands of AI Agents to Build One Browser

#machinelearning #ai #agents #cursor

Locks failed, one boss agent burned out, and a tree of planners won. Here's what Cursor's multi-agent experiments teach about coordinating agents at scale.

One coding agent is good at a focused task: fix this bug, add this endpoint, write these tests. Give it something the size of a web browser and it falls apart. Cursor engineer Wilson Lin tried exactly that. He asked a frontier model to plan a browser engine and kept telling it to "keep going." The model lost track of what it was doing, declared success long before it was finished, and got stuck on hard details.

So Cursor asked a different question: if you spend 10× more compute, can you get 10× more useful work? In a research project that ran for a few weeks around the start of 2026, the team built a harness that ran hundreds of agents per machine, about 2,000 at peak, on a single codebase. It wrote a browser engine called FastRender with more than a million lines of Rust. At its peak, the system landed about 1,000 commits an hour with no human steering.

The browser was only the test case. The real output was a set of coordination lessons that became a product: Cursor Projects, launched September 10, 2026, where one coordinator agent directs thousands of subagents. This issue walks through the four designs Cursor tried, why three failed, how the winner works, and what it cost.

Background: Why One Agent Isn't Enough

A few terms first.

Agent: a language model calling tools in a loop: read files, run commands, edit code, repeat.
Harness: the program around the model that runs that loop, supplies tools and manages context. (Issue 005 took a single-agent harness apart.)
Multi-agent system: several agents, each with its own context window, splitting up one goal.
Throughput: useful work per hour. For Cursor, mostly commits that move the project forward.

A single agent has two hard limits on a big project. It does one thing at a time, and it has one context window that fills with old tool output until the agent loses the plot. Many agents, each with a fresh context, fix both in principle. In practice they create the problem every human team has: coordination. Who works on what? How do you stop two agents fixing the same bug? Who decides the project is done?

Cursor's research is useful because it reports the designs that didn't work. Lin describes it in two posts: Scaling long-running autonomous coding (January 14, 2026) and the longer Towards self-driving codebases (February 5, 2026). Everything below comes from those posts unless another source is linked.

Four Harness Designs, Three Failures

The team started with a simple Rust harness on one large Linux VM, controlled over SSH. Before tuning anything, they logged every agent message, system action and command output with timestamps, so sessions could be replayed and mined for patterns. That observability made every later step possible.

1. Flat peers and a lock file. The first idea was the least prescriptive: every agent has the same role, and they coordinate through a shared state file. An agent reads the file to see what others are doing, claims a task and updates its status, with a lock so two agents can't grab the same task.

It failed fast. Agents held locks too long, forgot to release them, or edited the file without locking at all. Even when locking worked, 20 agents slowed to the throughput of 2 or 3, mostly waiting. Swapping locks for optimistic concurrency control (read freely; a write fails if the state changed since you read it) was more robust, but exposed a deeper problem. With no hierarchy, agents became risk-averse, picking small, safe changes. No one owned the project, so work churned without progress.

2. Planner, executor, workers and a judge. Next, roles. A planner wrote the approach and deliverables. An executor owned delivering that plan and spawned workers to do the tasks. After each round, an independent judge decided whether the work was finished or another iteration should run. This fixed most coordination problems, because a single agent now owned the outcome. But it was rigid. Each round waited for the slowest worker, and because all planning happened up front, the system couldn't adjust when it discovered new problems mid-round.

3. The continuous executor. So Cursor removed the separate planner. The executor planned and spawned tasks continuously, and to keep it from drifting over long runs the team added "freshness" mechanisms:

a scratchpad.md that agents rewrite rather than append to,
automatic summarizing when an agent nears its context limit,
self-reflection and alignment reminders in the system prompts,
explicit permission to pivot and challenge assumptions.

It worked well enough that the judge was dropped. Then the executor started misbehaving: sleeping at random, doing work itself, spawning only a few narrow tasks, merging badly and claiming early completion. The diagnosis: too many jobs at once (plan, explore, spawn, monitor, review, edit, merge, decide when to stop). One agent was doing a whole management chain's work.

4. A tree of planners, workers and handoffs. The final design split those jobs back apart, but this time into a hierarchy that can grow. That's the design the rest of this issue is about.

How the Final System Works

Following the numbers in the diagram:

You write the instructions. A human gives the system its goal and constraints. Once a run starts, Lin told Simon Willison, "there's actually no way to steer it." The only control is stopping it, so the instructions carry a lot of weight (more on that below).
The root planner owns the whole scope. It studies the current state of the repo and writes specific, targeted tasks that move toward the goal. It writes no code itself, and it doesn't know or care which agent picks up each task.
Planners spawn subplanners. When a planner decides its scope can be split, it creates subplanners that each fully own one slice, say the CSS engine. This is recursive, so planning itself runs in parallel, and no single planner gets tunnel vision on a huge project.
Workers take one task each. A worker drives its task to completion and knows nothing about the larger system. It doesn't talk to other workers or planners, and it works on its own copy of the repo.
Workers push to one shared branch. There's no central merge gate. Workers resolve their own conflicts.
A handoff goes back up. When a worker finishes, it writes a single handoff that the system delivers to the planner that asked for the task. The handoff covers what was done plus notes, concerns, deviations, findings and feedback. The planner gets it as a follow-up message, pulls the latest code and plans again.

Step 6 is the subtle part. Even a planner that thinks it's "done" keeps receiving handoffs, so it keeps planning. Information flows up the tree toward agents with an increasingly global view, without any global synchronization or cross-talk between workers. Lin notes that this looks a lot like how some human software teams work, even though the models were never trained to organize this way.

Why there's no integrator. Cursor originally added an integrator agent for quality control and to serialize the pushes, rebases and merges from hundreds of workers. It became the obvious bottleneck: hundreds of workers and one gate. Prompt changes didn't fix it, so the team removed it. Workers turned out to be capable of handling conflicts themselves. And conflicts were rarer than you might expect. Lin told Willison that most commits had no merge conflicts, because planners split the work so that tasks rarely overlapped in time or files.

Different models for different roles. Cursor found OpenAI's GPT-5.2 better at extended autonomous work than Claude Opus 4.5, which "tends to stop earlier and take shortcuts." GPT-5.2 was also a better planner than the coding-specialized GPT-5.1-Codex, because the job was "more expansive than merely coding," Lin said: operating inside a harness without a user to ask. The system now picks a model per role.

Throughput Over Perfection

The most counterintuitive decision in the project is about correctness. At first, Cursor required 100% correctness before every commit. That caused heavy serialization. One small error, like an API change or a typo, could halt the whole system. Workers wandered outside their scope to fix unrelated breakage, and many agents piled onto the same issue and trampled each other.

So the team allowed some slack. If a commit introduces a small error, agents trust that another agent will fix it soon, which is true because every part of the codebase has an owner in the tree. The result, in Lin's words, is an error rate that "remains small and constant," not one that grows. He suggests the ideal setup accepts some error rate and adds a final "green" branch, where an agent regularly takes a snapshot and does a quick fix-up pass before release.

The same logic applies when two agents touch the same file. Rather than over-engineer a prevention scheme, the harness accepts "moments of turbulence" and lets the code settle. That costs some tokens but keeps the system simple enough to align and observe.

The numbers from the stable run: about 1,000 commits per hour across 10 million tool calls over one week, with no human intervention after launch. By the time Willison wrote about it, the repo had nearly 30,000 commits.

This is a classic distributed-systems trade-off, made consciously: give up per-commit consistency to get throughput, then reconcile at the end. It's similar to eventual consistency in a database, applied to a codebase.

The Machine Became the Bottleneck

Cursor deliberately avoided building a distributed system. Each multi-agent run had its own large machine, which made metrics easy to watch and state easy to share. Lin told Willison each machine ran about 300 agents, which works because agents spend much of their time thinking rather than running tools. To go beyond one machine, the team split the browser into separate work streams (for example, CSS) and ran one harness per stream on its own machine.

Scaling up exposed bottlenecks that a single developer never sees:

RAM first. After agent memory was capped, the hotspot moved.
Then disk. With a monolithic project, hundreds of agents compiling at once read and wrote many GB/s of build artifacts. Compilation, not thinking, came to dominate time. A later run restructured the project into many self-contained crates and spent far less time waiting on builds, running at "multiple times more throughput."
Then shared locks in tools. Git and Cargo use shared locks as simple concurrency control. The team noticed contention from many agents running git restore at once.

Lin's takeaway: codebase structure affects token throughput. He floats borrowing from databases and storage systems: finer concurrency control instead of coarse tool locks, and copy-on-write plus deduplication for hundreds of near-identical repo copies.

Feedback loops kept agents honest. A week-long autonomous run needs signals that tell agents whether they're right. FastRender used three, according to Lin's interview with Willison:

Specs in the repo. Git submodules pulled in the CSS, HTML, DOM and ECMAScript specifications, and the agent-written code often cites them.
Screenshots vs. golden images. GPT-5.2 can read images, so agents compared rendered screenshots against golden samples.
The Rust compiler. "You can get a lot of verification just from compilation."

Instructions Get Amplified

The harness turned out to be the easy part. The instructions were harder. A multi-agent run is like a normal coding agent with "orders of magnitude more time and compute," Lin writes, and that "amplifies everything, including suboptimal and unclear instructions." Agents follow instructions to the end, good or bad.

Examples from the browser project:

"Spec implementation" was vague enough that agents dove into obscure, rarely used features instead of prioritizing.
Performance expectations were assumed, not stated. It took explicit instructions and enforced timeouts to get agents to balance speed with other goals.
With no stated dependency policy, agents pulled in libraries they could have written. One added QuickJS to unblock itself while other agents were still building the JavaScript engine. A later run listed the banned libraries, which fixed it.

From all this, Cursor drew a few prompting rules that apply well beyond browsers:

Only instruct what the model doesn't know, like multi-agent etiquette or how to run your tests. Treat it like "a brilliant new hire" who knows engineering but not your codebase.
Constraints beat instructions. "No TODOs, no partial implementations" works better than "remember to finish implementations."
Avoid checklists for deep work. A list of specific items makes the model focus on the list and implicitly deprioritize everything else.
Use numbers for scope. "Generate many tasks" gets a cautious handful. "Generate 20–100 tasks" signals ambition, and the team saw very different behavior.

Cursor's January post sums it up: "The harness and models matter, but the prompts matter more."

How Other Teams Coordinate Agents

Cursor's tree isn't the only working design. Comparing it with two Anthropic write-ups shows how much the right structure depends on the task.

Anthropic's C compiler: peers with git locks. Nicholas Carlini ran 16 Claude agents in parallel, each in its own Docker container with its own clone of a shared repo. There's no orchestrator. An agent claims a task by writing a file to current_tasks/, and git's synchronization forces a second agent that claims the same task to pick another one. Over nearly 2,000 Claude Code sessions, two billion input tokens and just under $20,000, they produced a 100,000-line Rust C compiler that builds Linux 6.9 on x86, ARM and RISC-V.

Two of Carlini's lessons mirror Cursor's. First, the verifier decides everything: if it isn't "nearly perfect," Claude "will solve the wrong problem." Second, flat parallelism breaks on one giant task. When all 16 agents hit the same Linux-kernel bug, they overwrote each other's fixes. The fix was GCC as a known-good oracle: compile most kernel files with GCC and a random subset with Claude's compiler, so each agent could chase a different failing file. The test suite, not a planner, splits the work.

Anthropic's Research feature: one lead, parallel subagents. In Claude's Research system, a lead agent plans, spawns 3–5 subagents that search in parallel, and synthesizes their findings. An Opus 4 lead with Sonnet 4 subagents beat single-agent Opus 4 by 90.2% on Anthropic's internal research eval, at about 15× the tokens of a chat. Token usage alone explained 80% of performance variance on BrowseComp. The lead waits for each batch of subagents to finish, which Anthropic calls a bottleneck: the same "slowest worker" problem as Cursor's design 2. Anthropic also notes that most coding tasks have fewer truly parallel pieces than research.

Cursor's own follow-ups. The same harness later took on 235 CUDA kernel problems with NVIDIA, with a planner rebalancing work by benchmark results. Over three weeks it reached a 38% geometric-mean speedup over baselines, and the benchmark threw out any "cheated" result faster than a B200 can physically run. After a February research preview of long-running agents (plan first, then have agents check each other's work), September brought Projects: a coordinator that "doesn't write code itself but directs other agents that do," with shared context files synced to every agent and subscriptions to Slack, schedules and PRs. Cursor says users who mainly work through Projects merge six times as many PRs.

The common thread across all three teams: separate the agents that decide what to do from the agents that do it, give every worker a fresh context and an isolated workspace, and invest heavily in automated checks.

The Trade-offs (and the Skeptics)

The approach has real costs, and the critics have a point.

Code quality. Software Improvement Group ran the public FastRender code through its analysis platform. It scored 1.3 out of 5 for maintainability, in the bottom 5% of systems SIG sees, and 2.1 out of 5 for architecture, meaning tightly coupled components. SIG sized the code at roughly 110 person-years of Rust and warned of "a new class of legacy: large, opaque, and hard to trust." Cursor never presented FastRender as production software, and the browser's own quirks (JavaScript turned off behind a feature flag, vendored layout libraries) show it.
"From scratch" is debatable. The agents pulled in dependencies such as Taffy for flexbox and grid layout. Critics quoted by SIG note that the agents' planning documents used Servo and Chromium as guides.
Cost. "Trillions of tokens," Cursor writes. SIG cites estimates of 10 to 20 trillion, several million dollars at list prices. Even Anthropic's far smaller compiler run cost about $20,000. The work has to be worth the tokens.
Verification is the ceiling. Carlini's compiler started breaking existing features with each new one near the end of the project. Cursor's final "green branch" pass is still a proposal. Carlini, who used to work in penetration testing, worries about "programmers deploying software they've never personally verified."
No mid-run steering. The research harness could only be stopped, not redirected. Projects adds a coordinator you can chat with mid-run.

Key Takeaways

Structure beats self-organization. Equal agents sharing a lock file were slow (20 agents ≈ 2–3) and risk-averse. Clear ownership through planners, workers and handoffs is what scaled.
Separate deciding from doing, and keep each role small. One agent juggling planning, merging and judging broke down. Recursive subplanners and narrow workers didn't.
Throughput needs slack. Accepting a small, stable error rate plus a final fix-up pass beat requiring every commit to be green. Removing the central integrator also helped.
The environment is part of the system. Disk I/O, tool locks, build structure and feedback signals (specs, screenshots, compilers, test oracles) shaped results as much as the models did.
Instructions get amplified. At thousands of agents, vague specs become wasted weeks. Use constraints, explicit numbers and a stated policy for dependencies and performance.

DEV Community