Cursor Projects: the boss who doesn't write code

I have been handing long tasks to agents for weeks. The model holds up. The chat does not.

You start clean. Then you open another thread. You restate the repo, the preferences, what last week already learned. It is not that the model is dumb. It is that the container is a chat: it is born, it dies, and the next one starts from zero.

On 10 September Cursor launched Projects. Beta, rolling out from the editor’s left-hand nav. The post does not sell a smarter chat. It sells a coordinator.

The boss who doesn’t write code #

In a Project you do not talk to the agent that pens the diff. You talk to a coordinator agent. Cursor is blunt about it: it does not write the code. It plans, it delegates, and it brings the work back for you to check.

The ones that implement are other agents. Research, implementation, tests. In parallel when the work needs it. The coordinator stays free so you can redirect without waiting on a blocked run.

That sounds like management. In the good sense: someone who keeps the map while others run.

Context that lasts months, not a thread #

What I care about is not the subagent headcount in the announcement. It is the container.

Each Project keeps a set of shared files. They sync across the Project’s cloud machine and, when needed, yours. Plans, artifacts, how to test a service, how you like work done. If one agent learns something useful, the next one does not have to rediscover it.

Cursor says that context can live for months. Against a chat that goes stale after a couple of hours of useful context, that is a different category.

It keeps going when you close the laptop #

A Project runs on its own computer in the cloud. Close the laptop and the work does not stop. When something needs testing on your machine, the coordinator can spin up a local agent.

It can also hook into outside signals — they call them subscriptions: a Slack channel, a schedule, your pull requests. Act when work appears, without you opening the chat.

I do not need an epic use case. A Project that watches CI, or that walks a migration in chunks without re-explaining the plan every Monday, would already be enough.

Loose chat versus Project #

Chat still wins for the short stuff: a question, a patch, a “look at this file”.

A Project is for work that outlives a single thread: a feature with several PRs, a migration, the maintenance that never ends. On the blog Cursor names three internal patterns: feature work, migrations, and “gardening” (quality, regressions, the work that comes back).

The difference is not marketing. It is where memory lives and who assigns the work.

It fits the August board #

In August the SpaceX purchase of Cursor closed. The editor and Grok live in the same house. Projects is product from that editor: more compute in a fleet, more work than fits in one prompt.

I do not read the launch as a promise that “nobody has to program anymore”. I read a change of unit of work: from message to a body of work with a boss.

What I take away #

Yesterday I wrote about the model. Today about the harness.

If the bottleneck is no longer “does the context hold?” but “who remembers the project when I am not there?”, Projects answers that. A coordinator that does not write code. Agents that do. Shared files that do not vanish when you close the thread.

I will try it on something I already know goes stale in chat: work spread over several days, with preferences I do not want to paste again.

No hype: on 10 September Cursor put a boss on top of the agents. The rest will show up in PR review, not in the launch post.

Sources: Introducing Projects (Cursor), Projects changelog.