Cursor Projects puts a coordinator agent over your repo

Cursor shipped Projects into beta on September 10, and the unit of AI work just changed size. A prompt gets you a diff. A Project gets you a coordinator agent that plans a migration, farms it out to subagents, watches your PRs for weeks, and hands finished work back for review. If you run a small dev team, this is the first agent product that assumes your work outlives your laptop session.

What actually happened

Per Cursor's announcement, a Project wraps a large body of work — a feature, a migration, a whole app — and puts a coordinator agent on top of it. The coordinator writes no code. It plans, delegates to implementation agents, and brings results back. Cursor says it can direct "thousands of subagents," running as many in parallel as the work needs.

Three details matter more than the headline:

• It runs in the cloud. Each Project gets its own machine, so closing your laptop does not stop it. When something has to run on your hardware, the coordinator spins up a local agent to do that one step.
• Context is shared and persistent. A Project keeps a set of files that sync across every cloud and local agent it uses, so what one agent learns about your codebase is not thrown away at the end of a session.
• It can start work without you. The changelog describes subscriptions: point the coordinator at a Slack bug-report channel, a schedule, or your open PRs, and it acts on those signals unprompted.

Cursor's own internal numbers: new users merged 30% more pull requests, and heavy Projects users merged six times as many compared with their own baseline. That is vendor-reported data on vendor-selected users — treat it as a direction, not a forecast for your team.

Why a coordinator agent matters for your business

The bottleneck on a three-person dev team was never typing speed. It was the work nobody schedules: the dependency bump, the design-system cleanup, the dead feature flag from March. A standing coordinator with a cloud machine is a plausible owner for exactly that tier of work.

The part we would get right before turning on subscriptions: an agent that acts on signals is an agent with standing permissions. A coordinator watching a Slack channel and opening PRs is an actor in your repo with no session boundary. Scope its repo access, require human review on merge, and keep branch protection on. Do not give it a token that can deploy.

And watch the meter. Thousands of parallel subagents on a dedicated cloud machine is not the same cost shape as an IDE seat. Before you run a migration this way, price one representative slice and extrapolate. We have seen teams discover their agent bill after the invoice, not before.

Sources: Cursor: Introducing Projects, Cursor changelog: Projects.