What Is Cursor Projects? Coordinator Agents Explained

Every Cursor session you have run so far shares the same limitation. You open a chat, work through a task, and when it is done the context mostly evaporates. The next session starts closer to zero than it should, even on the same codebase.

Cursor's new Projects feature is a direct answer to that limitation. It is not another chat mode. It is a persistent workspace built for work that spans weeks or months, feature builds, migrations, or entire applications, run by something Cursor calls a coordinator agent.

If you have only skimmed the changelog, "what is Cursor Projects" is a fair question, because it behaves nothing like a normal Cursor session. Here is what it actually does, and where it sits next to what Claude Code already offers for long-running work.

What a Project Actually Is

A Project lives in Cursor's left-hand navigation, separate from your regular chats. According to Cursor, a Project is meant for a body of work you would normally have to break into dozens of disconnected sessions: a feature, a migration, or a full application build. Instead of resetting once a task finishes, the Project persists and keeps working over the following weeks or months.

That persistence is the entire point. A single chat that resets is fine for a bug fix. It is a poor fit for a three-month migration where the agent needs to remember decisions made in week one when it is working in week eight.

Projects are in beta and started rolling out to all Cursor users on September 10, 2026.

The Coordinator Agent Does Not Write Code

The part of Projects most worth understanding is the coordinator agent that sits at the center of each one. Unlike a normal Cursor agent, the coordinator does not touch code itself. Its job is to plan the work, break it into discrete tasks, and delegate those tasks to separate agents that do the actual implementation. Once a task comes back finished, the coordinator brings it to you for review.

That division of labor is what lets a Project scale. Because the coordinator creates and manages agents on your behalf rather than doing the work directly, it can run as many of them in parallel as a job requires. A small feature might need one or two. A large migration might need far more, without you having to spin up and track each one manually.

Cloud Agents, With Local Agents When Needed

Each Project runs on its own dedicated computer in the cloud. That means closing your laptop does not stop the work: the coordinator and its subagents keep running. When a task genuinely needs to happen on your own machine, running a local test suite is the example Cursor gives, the coordinator spins up a local agent specifically for that step, then hands control back to the cloud-based work.

This is a meaningful difference from how most Cursor sessions run today, where the agent lives in your editor and stops when you do.

Shared Context That Compounds

The other core mechanic is a set of shared context files that sync across every agent touching a given Project, cloud and local alike. As agents work, they write research, artifacts, and lessons learned back into that shared context. If one agent figures out how to test a particular service, every agent that runs afterward inherits that knowledge automatically instead of re-learning it.

Cursor frames this as a compounding effect: the longer a Project runs, the more effective its coordinator becomes, because the context it is drawing on keeps getting richer. That directly targets the "starting from zero every session" problem that makes long-running AI-assisted work frustrating in a standard chat interface.

Subscriptions: Work Without a Prompt

Projects can also act without being asked. Through subscriptions, you can point a coordinator at a Slack channel, a repository's pull requests, or a fixed schedule, and it will act on whatever signal it detects rather than waiting for you to type a message. Cursor's own example: connect a Project to a bug-report Slack channel, and the coordinator starts delegating a fix to a subagent the moment a new report lands.

That is a step past most current AI coding tools, which are reactive by default. A subscription-driven Project is closer to a standing team member that watches for triggers and responds on its own.

Where Cursor Projects Fits Next to Claude Code

If you already use Claude Code, the coordinator-and-subagents pattern will feel familiar. Claude Code's own subagents let you delegate scoped pieces of work to specialized agents, and modes like Claude Code Ultracode push that same background-work territory further still. The instinct behind both tools is the same: a single flat chat session is the wrong shape for work that spans days or months, so the tools are evolving toward a planner-and-workers structure with persistent memory instead.

Where Cursor Projects goes further, at least on paper, is in making that structure the default surface for big work rather than something you assemble yourself, plus the subscription model that lets a Project trigger itself off Slack or pull requests without a human in the loop. Whether that autonomy is a net win depends heavily on how much you trust a coordinator to delegate correctly at 2am when nobody is reviewing in real time.

For anyone weighing the two tools, our Cursor Auto mode explainer is worth a read for getting Auto mode and model selection right, since a Project's coordinator and subagents inherit whatever routing behavior sits underneath them, and our Cursor Rules complete guide covers setting up rules and configuration that keep a Project's shared context disciplined instead of accumulating noise.

Early Numbers, With a Caveat

Cursor has not published its own usage numbers for Projects yet. AlphaSignal's coverage of Cursor's internal data reported that developers who lean on Projects merge roughly six times more pull requests than casual users, with early adopters seeing about a 30% increase. That is a striking figure, but it comes from Cursor's internal data as reported by a third party, not an independently audited study, so treat it as directional rather than definitive until more usage data is public.

Cursor Projects for Product Managers

You do not need to write code to get value out of a coordinator agent. The same planning-and-delegating pattern maps cleanly onto PM work that currently gets done in scattered one-off chats:

• Competitive teardowns that run for a quarter. Point a coordinator at a set of competitor changelogs and let it maintain a living comparison instead of you re-researching from scratch every time a competitor ships something.
• PRD and spec reviews from multiple angles. Delegate a "review this spec for edge cases, then for scope creep, then for missing success metrics" workflow to subagents instead of doing three passes yourself.
• Discovery synthesis across weeks of interviews. A Project's shared context is well suited to holding onto patterns across dozens of user interviews conducted over a month, rather than losing the thread every time a new session starts.

The underlying skill here, breaking a large ambiguous goal into tasks an agent can execute and reviewing the output critically, is exactly what separates PMs who get real leverage from AI tooling from those who use it for one-off prompts. If you want hands-on practice with Cursor beyond a single Project, our Master Course on building and shipping a production-ready app with Lovable and Cursor walks through the full stack, from frontend to a live deployment.

The Bottom Line

Cursor Projects is a genuine structural change, not a rebrand of the chat window. A coordinator agent that plans instead of codes, cloud execution that survives a closed laptop, shared context that compounds instead of resetting, and subscriptions that let work start without a prompt, together that is a real answer to why long AI-assisted work has felt disjointed so far. It is still in beta, and the biggest number backing it up is third-party reporting on Cursor's own internal data, so the honest read is promising early direction rather than a settled verdict.