Cursor’s new coordinator agent writes no code itself

Cursor on September 10 started rolling out Projects in beta to all its users. In a Project, one coordinator agent is in charge, and it never writes code itself. It plans the work and hands it to coding agents, up to thousands of them, which research, implement and test in parallel.

Projects is built for work too big for one chat session: features that span several PRs, broad migrations, whole applications, and recurring maintenance that has to continue after any single conversation ends, per Cursor’s announcement as recapped by Testingcatalog. Projects sit in the left-hand navigation. You describe what you want built, and the coordinator takes it from there.

You talk only to the coordinator. It breaks the request into tasks and dispatches them to coding agents. Cursor says this keeps the coordinator responsive: it stays free to answer you while the other agents do the slow work. In a single-agent chat, the agent you’re talking to is also the one running the tests.

Each Project gets its own cloud computers. Work keeps going after you close the laptop, and more agents can run at once than a local machine would allow. Some tasks still need your hardware, and for those the coordinator can start a local agent. A set of shared files syncs across the Project’s cloud and local machines. It carries research, artifacts, knowledge about the codebase, testing instructions and your preferences into future tasks.

Subscriptions turn a Project into something that keeps running between your prompts. A coordinator can watch Slack for bug reports, run on a schedule, set reminders, or follow pull requests. When a PR opens or merges, or CI breaks on it, the coordinator can respond and fix it. Subscriptions themselves came earlier: Cursor’s August 19 update let cloud agents wake on PR and Slack events, and let subagents run on their own virtual machines.

Cursor describes three common patterns. The first is feature development. The second is incremental migrations, where a large change lands as a long series of smaller PRs. The third is what the company calls “gardening”: ongoing code-quality upkeep and regression monitoring, with nobody needing to remember to start it.

The company says it has used Projects internally for several months, on migrations covering hundreds of PRs, on design-system maintenance, and on building Projects itself. Cursor also gives two adoption figures: new Projects users merge 30% more PRs, and people who use Projects as their main workflow merge six times as many.

The gardening pattern shows up in one internal design-system Project, which Cursor expects to touch 20 to 100 PRs per day. It scans incoming changes, pulls out components that can be reused, and adds a lint rule once the same mistake has shown up twice.