Overview
Cursor's research team details their iterative journey building a multi-agent system capable of orchestrating thousands of AI coding agents to autonomously develop a web browser. The article chronicles the evolution from single-agent approaches through various multi-agent architectures, ultimately arriving at a recursive planner-worker design that achieved ~1,000 commits per hour across 10M tool calls over one week with minimal human intervention.
What You'll Learn
1
How to design a recursive planner-worker multi-agent architecture for autonomous coding at scale
2
Why self-coordination among equal-role agents fails and how structured roles with ownership solve coordination problems
3
How to write effective prompts and instructions for long-running autonomous coding agents
4
When to accept error rates in multi-agent systems to maximize throughput instead of enforcing 100% correctness
5
How freshness mechanisms like scratchpad rewriting and automatic summarization prevent agent drift over long sessions
Prerequisites & Requirements
- Understanding of distributed systems concepts (concurrency, locking, synchronization)
- Familiarity with AI/LLM agent systems and prompt engineering
- Understanding of Git workflows (branching, rebasing, merge conflicts)
- Experience with multi-agent or multi-process system design(optional)
- Familiarity with Rust and Cargo build system(optional)
Key Questions Answered
How do you coordinate thousands of AI coding agents working on the same codebase?
The final design uses a recursive planner-worker hierarchy where a root planner owns the full scope, spawns subplanners for subdivided work, and workers pick up individual tasks on their own repo copies. Workers submit handoff reports back to planners containing findings, concerns, and deviations. This eliminates cross-talk and global synchronization overhead while maintaining full ownership through the chain.
Why does self-coordination fail in multi-agent coding systems?
When agents with equal roles share a coordination file, they hold locks too long, forget to release them, and don't understand locking significance. Locking causes extreme contention where 20 agents slow to 1-3 agent throughput. The lack of structure means no agent takes on complex tasks — they avoid conflict by opting for smaller, safer changes rather than taking project ownership.
What throughput can a multi-agent coding system achieve?
The system peaked at approximately 1,000 commits per hour across 10 million tool calls over a one-week period. Once started, it required no human intervention. This was achieved by accepting some error rate rather than requiring 100% correctness before every commit, and by allowing moments of turbulence from synchronization conflicts to naturally converge.
How should you write prompts for long-running autonomous coding agents?
Use constraints rather than instructions — 'No TODOs, no partial implementations' works better than 'remember to finish implementations.' Don't instruct for things models already know, only domain-specific knowledge. Avoid checkbox mentality for complex tasks. Give concrete numerical ranges like '20-100 tasks' instead of vague terms like 'many tasks' which produce conservative outputs.
Should multi-agent coding systems require 100% correctness before committing?
No. Requiring 100% correctness before every commit causes major serialization and throughput slowdowns. Even small errors cause the whole system to halt as workers go outside scope to fix irrelevant issues. The ideal efficient system accepts a small stable error rate, trusting that other agents will fix issues soon, with a final 'green' branch where an agent does fixup passes before release.
What infrastructure bottlenecks appear when running hundreds of AI agents simultaneously?
After limiting RAM usage, disk becomes the hotspot — hundreds of agents compiling simultaneously create many GB/s of build artifact reads and writes. Shared locks in tools like Git and Cargo cause contention. Project structure and compilation time dominate throughput more than thinking and coding time. Restructuring into smaller crates significantly improved throughput.
How do you prevent AI agents from drifting during long-running sessions?
Four freshness mechanisms work together: scratchpad files should be frequently rewritten rather than appended to, agents automatically summarize when reaching context limits, self-reflection and alignment reminders are added to system prompts, and agents are encouraged to pivot and challenge assumptions at any time. These keep the system dynamic and aligned with goals.
What models did Cursor use for their multi-agent browser project?
The project started with Anthropic's Opus 4.5, which showed deep knowledge but lost track of complex tasks. They later switched to OpenAI models (GPT-5.1 and GPT-5.2) because these showed better results for precisely following instructions, which was deemed a good fit for long-running autonomous agents.
Key Statistics & Figures
Peak commit throughput
~1,000 commits per hour
Achieved during the one-week continuous autonomous run
Total tool calls
10 million
Over the one-week continuous run period
Continuous run duration
1 week
System ran continuously without human intervention
Peak concurrent agents
Several hundred
Running on a single large Linux VM, which was typically saturated
Agent throughput degradation with shared coordination
20 agents slowed to throughput of 1-3
Due to lock contention on the shared coordination file
Technologies & Tools
Some links below are affiliate links. We may earn a commission if you make a purchase.
Programming Language
Rust
Used to build the multi-agent harness and the browser project itself
Version Control
Git
Used for agent coordination, committing work, rebasing, and merging worker changes
Build Tool
Cargo
Rust build system; shared locks caused contention issues with many concurrent agents
AI Model
Opus 4.5
Initial model used for browser planning and implementation; showed deep knowledge but lost track of complex tasks
AI Model
Gpt-5.1
Used for long-running agents due to better instruction-following capabilities
AI Model
Gpt-5.2
Later model iteration used for improved instruction-following in autonomous agents
Infrastructure
Linux Vm
Single large virtual machine used to run all agents, avoiding distributed systems complexity
Infrastructure
SSH
Used to access the VM and control the harness via a terminal interface
Developer Tool
Cursor
Used to analyze logs and compare them against prompts to understand agent behavior patterns
Key Actionable Insights
1Use constraints instead of instructions when prompting AI agents. Negative constraints like 'No TODOs, no partial implementations' are more effective than positive instructions like 'remember to finish implementations' because models generally do good things by default and constraints define clear boundaries around acceptable behavior.This is especially important for long-running agents where ambiguous instructions get amplified over thousands of actions and tool calls.
2Give each agent a single, well-defined role rather than overloading one agent with multiple responsibilities. The continuous executor failed because it was simultaneously asked to plan, explore, research, spawn tasks, check workers, review code, merge outputs, and judge completion. Separating into dedicated planners and workers eliminated pathological behaviors.This mirrors established software engineering principles of single responsibility, but is especially critical for AI agents which become overwhelmed and exhibit erratic behavior when given too many simultaneous objectives.
3Accept a small, stable error rate to maximize throughput rather than enforcing 100% correctness at every step. When every commit had to be perfect, the entire system would grind to a halt from a single typo as multiple agents piled on to fix it. Allowing slack and trusting other agents to fix issues soon keeps the system moving productively.Use a separate 'green' branch with periodic fixup passes for release-quality code, similar to how continuous integration uses staging branches.
4Provide concrete numerical ranges in instructions rather than vague quantifiers. Saying 'generate 20-100 tasks' produces dramatically different behavior than 'generate many tasks,' which defaults to conservative, safe outputs. Specific numbers convey ambition and scope expectations clearly.This applies broadly to any LLM interaction where you need to control output quantity or scope — production systems, batch processing, or task decomposition.
5Invest heavily in observability and logging from the start of any multi-agent system. Log all agent messages, system actions, and command outputs with timestamps for replay and analysis. This data can be fed back into AI tools to identify patterns across large volumes of agent behavior that humans would miss.The Cursor team used their own tool to analyze harness logs, enabling rapid iteration on system design by identifying repeated failure patterns across many agents.
6Design worker agents to operate on isolated copies of the repository and communicate results only through structured handoff reports rather than direct inter-agent communication. This eliminates coordination overhead, prevents cross-talk, and makes the system anti-fragile since individual agent failures don't cascade to others.The handoff should include not just what was done, but concerns, deviations, findings, and feedback so that planners with broader context can make informed subsequent decisions.
Common Pitfalls
1
Overloading a single agent with too many simultaneous roles and responsibilities. The continuous executor was asked to plan, explore, research, spawn tasks, review code, merge outputs, and judge completion all at once, which led to pathological behaviors including random sleeping, refusal to plan, doing work itself instead of delegating, and claiming premature completion.
Separate concerns into dedicated roles — planners plan, workers execute, and each role has clear boundaries. This mirrors the single responsibility principle in software design.
2
Relying on equal-role self-coordination with shared state files and locking mechanisms. Agents consistently held locks too long, forgot to release them, and performed illegal lock operations. Locking is narrowly correct and easy to get wrong, and more prompting didn't help fix this fundamental coordination challenge.
Instead of peer coordination, use hierarchical structures where a single owner delegates work and receives structured handoffs back.
3
Using vague or underspecified instructions when directing autonomous agents at scale. Instructions like 'spec implementation' caused agents to deep-dive into obscure, rarely-used features rather than intelligently prioritizing high-impact work. Implicit assumptions about performance expectations were ignored until made explicit.
Scale amplifies instruction quality problems — spend disproportionate time on initial specifications and include explicit constraints, numerical ranges, and dependency philosophies.
4
Requiring 100% correctness before every commit in a multi-agent system. A single small error like an API change or typo would cause the entire system to halt as workers went outside their scope to fix irrelevant issues, with multiple agents trampling each other trying to fix the same problem simultaneously.
Accept a small stable error rate and use a separate reconciliation branch. Trust that the system's ownership model will catch and fix errors promptly.
5
Planning everything upfront and rigidly executing the plan. Doing all planning before execution made it impossible for the system to dynamically readjust when new issues were discovered. Agents went in counterproductive directions and couldn't self-correct until the next full iteration of the plan-execute loop.
Use continuous planning within the executor role, allowing plans to evolve as workers report findings and the codebase state changes.
6
Using a monolithic project structure with many agents compiling simultaneously. Hundreds of agents building a monolith created many GB/s of disk I/O for build artifacts, making compilation time dominate over thinking and coding time. Restructuring into self-contained crates dramatically improved throughput.
Project architecture directly affects agent throughput — modular designs with independent compilation units allow agents to build and test their changes without contending for shared resources.
Related Concepts
Multi-agent Systems
Autonomous Coding Agents
Distributed Systems Coordination
Optimistic Concurrency Control
Prompt Engineering For Agents
Anti-fragile System Design
Recursive Task Decomposition
Copy-on-write File Systems
Lock Contention And Concurrency
Agent Observability And Logging
Browser Engine Architecture
Linear Scaling Of Compute Throughput
Eventual Consistency In Codebases
Self-converging Systems
Ai-assisted Software Development