Cursor Runs the Fleet Now

Cursor just promoted the chat box to a manager.

On 10 September 2026 the company shipped Projects, a beta for work that outlives a single thread: a feature, a migration, a full app. You talk to a coordinator. The coordinator does not write the code. It plans, spins up subagents for research, implementation, and tests, and stays free to take your next instruction while those agents run.

That is the product translation of Cursor's third-era pitch from February: autocomplete, then synchronous agents, then fleets that keep going after you close the laptop. Projects is the fleet object.

Image: Cursor, Introducing Projects, 10 September 2026.

Three pieces of machinery

Cloud by default. Each Project gets its own computer, so parallelism is not capped by your laptop. When something has to run against a local setup, the coordinator starts an agent on your machine.

Shared context. Project files sync across every cloud and local box those agents touch. Agents dump research, artifacts, test recipes, and the lore of how you like the repo. If one agent figures out how to test a service, the next one does not get onboarded from zero.

Subscriptions. The coordinator can watch Slack, follow pull requests, fix CI, or run on a schedule. Work starts from a signal, not a prompt. That is the line between a coding assistant and an operating loop.

What Cursor claims it already does internally

Cursor says it used Projects for months before the public beta: migrations of a few hundred PRs, design-system consistency, and shipping Projects itself. The in-house numbers they published: new users merge 30 percent more PRs; people who primarily use Projects merge six times as many. Treat those as vendor metrics until you see them on your own repo.

Three patterns they describe:

• Feature work: agents research, write shared notes, the coordinator parallelizes implementation and tests, then a local agent runs the thing on your box. After ship, the same Project can watch logs with the original decision context.
• Migrations: you lock a safe approach, then it walks the codebase. Review is tight at first, looser as the diffs hold. The unfinished migration is the failure mode this product exists to survive.
• Gardening: work that never ends. One Cursor engineer runs a design-system Project that scans new PRs, extracts components, and adds a lint rule when it sees the same mistake twice. Target load: 20 to 100 PRs a day, with the human checking in where attention is needed.

What this means for a team that already has agents

The useful question is not whether it can write a function. It is who owns the merge queue when a coordinator is subscribed to CI. A fleet that opens PRs from Slack is a new identity in your org: it needs least privilege, an audit trail, and a human who can kill the subscription.

Cursor did not publish account limits or the compute bill for thousands of subagents. Until those numbers are in the product, treat the upper bound as marketing. The architecture is still the story: a persistent coordinator, shared memory, and event-driven work.

Beta is rolling out to all users from the left-hand nav. Use it on work that will still be true next month. A one-off chat is the old product.

Sources

Cursor, Introducing Projects, 10 September 2026. https://cursor.com/blog/projects

Cursor changelog, Projects. https://cursor.com/changelog/projects