Introducing Projects
Today we're launching Projects in Cursor. Projects lets you take on larger bodies of work, such as a feature, a migration, or a full app. It maintains context over months of work, delegates tasks to thousands of subagents, and performs recurring work without being prompted.
In February we outlined our vision for a third era of software development, where fleets of agents take on entire bodies of work. Projects is the concrete implementation of that vision. By moving up a level of abstraction, it frees developers from managing agents and lets them direct the work itself.
At Cursor, we've been using Projects for several months, doing work such as running migrations of a few hundred PRs, keeping our design system consistent, and shipping Projects itself. We've found it to be a substantial productivity multiplier: new users merge 30% more PRs while users who primarily use Projects merge six times as many.
Direct thousands of agents through one coordinator
You oversee a Project by chatting with its coordinator agent. The coordinator doesn't write code itself but directs other agents that do. Because it delegates rather than executes, it is never blocked and is always responsive to direction.
There are three core capabilities that make Projects possible:
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 needs testing on your machine, the coordinator spins up a local agent to run it there.
Shared context. You shouldn't have to onboard an agent every time you start a task. 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 test a service, for example, every future agent can use those instructions. This context grows with the Project, making the coordinator more effective over time.
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. This way it can take action based on signals it detects, without waiting for you to prompt it.
How we use Projects at Cursor
Three patterns cover most of what our engineers do with Projects.
Feature work
Most engineers create a Project for a substantial body of work. A feature usually starts with agents researching the system and recording what they learn as shared context. The coordinator then creates a plan and sends agents to implement and test different parts of it in parallel.
With each turn of feedback, the Project learns your architecture and preferences. When the feature is ready to try, the coordinator can start an agent on your computer and run it locally. After it ships, the same Project can monitor logs and handle bug reports with the full context behind the original decisions.
Migrations
Projects are especially useful for migrations that are easy to start and difficult to finish. At Cursor, we've used them to adopt new frameworks and replace styling systems across hundreds of PRs.
You work with the coordinator to establish a safe approach, then it applies that approach incrementally across the codebase. Early on, you review each PR closely. As the fixes hold up, you review less, and the coordinator keeps working through the migration on its own.
Gardening
Projects are great for handling work that never really ends, such as maintaining code quality or watching for regressions. You can tell the coordinator to follow new PRs, listen for bug reports in Slack, or run on a schedule, and it acts whenever new work appears.
One engineer on our team runs a design-system Project this way. At first, the engineer reviewed each fix and corrected the ones it got wrong. Now 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. The Project is on track to touch 20 to 100 PRs a day, so the coordinator organizes the work and the engineer checks in where attention is needed.
Get started with Projects
Projects are available in beta and rolling out to all users starting today. Start a Project from the left hand nav, describe what you want built, and the coordinator takes it from there. It 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.