Cursor's Projects Lets a Coordinator Agent Direct Thousands of Subagents

Cursor just shipped Projects, a new mode of working that swaps the familiar chat-per-task loop for a single, persistent thread run by a coordinator agent. Rather than babysitting one agent at a time, you talk to the coordinator, and it farms work out to a fleet of subagents that keep going whether your laptop is open or not.

Projects is meant for larger bodies of work such as a feature, a migration, or a full app. It maintains context over months, delegates tasks to thousands of subagents, and performs recurring work without being prompted. It is the concrete product form of the third era of software development vision Cursor laid out earlier this year, where developers direct the work rather than manage individual agents.

The coordinator pattern

You oversee a Project by chatting with its coordinator agent. The coordinator doesn't write code itself; it directs other agents that do. Because it delegates rather than executes, it is never blocked and stays responsive to direction. That separation is the whole trick: the thing you talk to never has its hands full compiling code or running tests, so it can keep planning and dispatching while workers grind.

Three capabilities hold the design together:

• Cloud by default, local when needed. A Project runs on its own computer, so closing your laptop doesn't stop it. This lets a Project run more subagents in parallel than your laptop could support. When something has to be tested against your machine, the coordinator spins up a local agent on demand.
• Shared context that grows. Each Project maintains a set of files that sync across every cloud and local machine its agents use. Agents add research and artifacts, along with what they learn about the codebase and how you prefer work to be done. If one agent figures out how to spin up a service for testing, every future agent inherits those notes.
• Subscriptions. The coordinator can watch a Slack channel, run on a schedule, or follow all your PRs, fixing CI and acting when they open or merge. It reacts to signals instead of waiting for a prompt.

Numbers from the dogfooding

Cursor has been running this internally for months. They report it as a substantial productivity multiplier: new users merge 30% more PRs, while users who primarily use Projects merge six times as many. Take those with the usual grain of salt for vendor-reported metrics, though the gap between casual and heavy users suggests the workflow rewards commitment rather than dabbling.

Three workflows it targets

The blog spells out the patterns that map cleanly onto Projects:

1. Feature work. A feature usually starts with agents researching the system and recording what they learn as shared context. The coordinator then plans and parallelizes implementation, and after ship it can monitor logs and triage bugs with the original decision history intact.
2. Migrations. Projects are especially useful for migrations that are easy to start and difficult to finish. Cursor used them to swap frameworks and styling systems across hundreds of PRs, with human review tapering off as confidence builds.
3. Gardening. Endless upkeep like enforcing code quality or catching regressions. One engineer runs a design-system Project where the coordinator scans every new PR, extracts components that belong in the design system, and adds a lint rule whenever it sees the same mistake twice. That Project is on track to touch 20 to 100 PRs a day.

The context rot problem

The pain point every heavy Cursor user recognizes is context rot: you start a chat, feed the agent your architecture, get somewhere useful, then start a new chat tomorrow and re-explain everything. Projects treats accumulated knowledge as a first-class artifact that syncs across machines and agents, so onboarding cost is paid once. Pairing that with subscriptions turns the IDE from a request-response tool into something closer to a background worker that reports in.

Where it will struggle

Cursor is upfront that this is beta, and the workflow itself carries real risk. Migrations touching hundreds of PRs and a coordinator that auto-fixes CI on merge mean small mistakes compound quickly if the shared context drifts or a subagent misreads a convention. The blog's own framing acknowledges the trust curve: early on, you review each PR closely, and as the fixes hold up, you review less, and the coordinator keeps working through the migration on its own. Teams without strong CI, code review discipline, or observability will feel the sharp edges first.

It also fits poorly with quick one-shots. Projects works best on work that will outlive a single chat, whether that's a feature with several PRs, a migration, or a job you want handled while you're away. For a five-minute refactor, the overhead of setting one up is likely more than the task itself.

How to try it

Projects are available in beta and rolling out to all users starting today. You start one from the left-hand nav in Cursor, describe the outcome you want, and the coordinator takes over from there. The feature builds on Cursor's earlier Automations and long-running agents work, which are worth reading if you want the lineage.

Where the category is heading

Projects lines up with where the whole coding-agent category is drifting: away from the single-turn autocomplete metaphor and toward orchestration layers that manage swarms of workers over long horizons. GitHub, Devin, and open-source frameworks like OpenHands and Claude Code are all converging on similar primitives: persistent context, background execution, and multi-agent delegation. Cursor's bet is that the coordinator abstraction, one thing you talk to and many things doing work, is the right seam for humans to stay in the loop as the number of concurrent agents scales into the thousands.