Correction, October 13, 2026: Cursor already offered cloud agents and event-triggered Automations. Projects adds a persistent coordinator and shared context for larger bodies of work.

What happened

Cursor launched Projects on September 10, rolling out in beta to all users of its AI coding tool. The company’s editor is where you chat with an AI agent to write, edit, and run code instead of typing every line yourself.

Cursor already offered scheduled and event-triggered Automations. Projects adds a coordinator above individual tasks: you describe a larger body of work, like a feature, a full migration, or an entire app, and a coordinator agent takes it from there. The coordinator doesn’t write code itself. Instead, it breaks the work into pieces and directs other agents, called subagents, to do the actual coding, testing, and fixing.

Three things make this possible, according to Cursor. A Project runs on Cursor’s own servers by default, not just your laptop, so it keeps working after you close your laptop and can run far more subagents at once than your machine could handle alone. When something needs to be tested on your machine specifically, the coordinator can still spin up a helper there. Second, each Project keeps a shared set of files that every agent working on it can read and add to, so a new subagent doesn’t need to be walked through your codebase from scratch the way a new hire would. Third, you can set up what Cursor calls subscriptions: instructions for the coordinator to watch a Slack channel, run on a fixed schedule, or watch your pull requests (proposed code changes waiting for review before they merge into your project) and act automatically when one opens or merges, including fixing failing checks.

Cursor says internal users saw real gains from this: people trying Projects for the first time merged 30% more pull requests than before, and people who use Projects as their main way of working merged six times as many. Check your account’s usage and spending controls as subagent work grows; the reported productivity figures do not establish the cost of your own tasks.

Why it matters

Projects changes what you personally have to manage. Chatting with one agent means you’re still the one deciding what to work on next, reviewing each step, and keeping track of what’s in progress. A coordinator that runs on its own schedule and reacts to Slack messages or pull requests can start work without a new prompt each time. You still set direction, review results and decide which actions require approval.

Cursor’s underlying setup has also been shifting: OpenAI plans to end Cursor’s direct model access following SpaceX’s acquisition of the company. A coordinator that acts on your repository without a prompt each time has more room to cause damage before you notice. If a subscription responds to every pull request that opens and misreads what “fixing CI” (the automated checks a project runs before code is allowed to merge) should mean for your project, it can prepare a change you did not intend. Keep review and merge permissions separate from permission to run the subscription.

Who should care

Anyone using Cursor for work that spans more than one sitting, a feature that takes a few days, a migration touching many files, or recurring maintenance you currently do by hand. If you’ve been manually re-explaining your codebase to a fresh chat every time you start a new session, the shared context Projects keeps between agents is aimed directly at that annoyance.

It matters less if your Cursor use is mostly quick, one-off edits you review immediately. Adding a coordinator and subscriptions on top of that kind of work is more setup than the task needs.

What builders should do next

Before turning on any subscription that acts automatically, especially one tied to pull requests or a schedule, limit the connected account to the permissions needed for a trial. Start with a reporting task and keep repository protections that require review before merging. Cursor’s own shared-context files give you a way to check this: after a few cycles, read through what the coordinator recorded about what it did and why, before you let a subscription act without your review in the loop.

If you want to compare Projects against how you work today, pick a real task you would normally handle over a few sessions, for example adding a small feature and its tests across three or four files. Do it once the normal way, chatting with a single agent step by step. Then do a similar-sized task once through a Project instead, coordinator and subagents. Compare four things: how many times you had to correct a subagent’s work after the fact, how long the whole task took from start to a version you’d actually ship, how much of your Cursor usage allowance each approach consumed, and how easy it was to recover when something went wrong. Cursor’s own 30% and six-times figures come from its internal usage, not from a controlled test, so they do not predict the gain for your own codebase.

End of article