Cursor Projects puts a coordinator agent in charge of the work
The agent that plans and delegates never writes the code. Cursor says it can keep a project's context for months.
Cursor’s September 10 release of Projects, in beta and rolling out to all users per its changelog , is built on a specific idea: the agent in charge shouldn’t be the one writing the code.
Cursor describes the coordinator as a project manager. It plans the work, delegates implementation to other agents, and brings finished work back to you to check. It can start and supervise several agents at once as the workload requires, and those agents can hand work to subagents of their own. Cursor says that can reach thousands of subagents.
What’s different from a normal agent session
Three things stand out in the announcement.
It runs on its own cloud computers, so the work continues when your laptop is closed. When something needs local testing, Cursor says the coordinator starts a local agent to run it there.
It keeps shared context. Each Project has files synchronized across every cloud and local machine its agents use. The agents accumulate research, artifacts, codebase notes and workflow preferences there, and Cursor’s claim is that this makes later agents more effective over time. Its headline pitch is a project that stays coherent across months.
It can be triggered by events, not prompts. Coordinators can watch a Slack channel, run scheduled tasks, or track all pull requests, and respond to what they see.
Why a coordinator
Splitting planning from implementation addresses a real problem with long agent runs. An agent that does everything fills its context with file contents and command output until it forgets the plan. A coordinator holds the plan and the status, while each worker gets a bounded task and a clean window. It’s the same shape as the multi-agent setup in our look at parallel agents building a C compiler , where the harness, not the agents, held the structure.
The cost is that the plan becomes a single point of failure. If the coordinator misreads the goal, thousands of subagents can implement the wrong thing very efficiently.
What the changelog doesn’t say
The entry gives no limits and no configuration details. There’s nothing on cost, which matters when a coordinator can fan out widely, and nothing on how you review the work at scale. “Brings finished work back to you to check” leaves a human to read all of it. The review burden for a month-long project is the part to test.
It also doesn’t say how the shared context is managed. Accumulated notes help until they’re wrong, and stale or incorrect context that agents trust is hard to spot from outside.
Who should try it
It’s a beta aimed at substantial initiatives: features, migrations or whole applications. If you have a bounded migration with a clear definition of done and good tests, it’s a reasonable pilot. Without tests, you’d be asking a coordinator to verify its own team’s work. Start on something you could do by hand, so you can tell whether the result is right.