Cursor Projects: what the new coordinator-agent feature actually does

What Cursor Projects actually is

A Project is a container for a big job. Cursor's own framing: it lets you "take on larger bodies of work, such as a feature, a migration, or a full app." Where a chat forgets everything the moment you close it, a Project holds context over months, can delegate to many agents, and can even act on recurring work without being prompted.

You start one from the left-hand nav, describe what you want built, and the coordinator takes it from there. It is in beta and rolling out to all users as of the launch date.

If you have used Cursor as an autocomplete-plus-chat tool, this is a bigger leap than the changelog makes it sound. The unit of work moves from "a message" to "a project," and the thing you manage moves from "the code" to "the agents."

The real shift: from one agent to a coordinator

Cursor has been building toward this for a while. Back in February 2026 it described a "third era" where "fleets of agents take on entire bodies of work" and the developer directs the work rather than each agent. Projects is that vision shipped.

Here is the trajectory, because it is the clearest way to see what changed:

In era one, you wrote the code and AI suggested the next line. In era two (where most agentic coding tools still live), you prompt one agent per task and watch it work. Projects is a bet on era three: you direct a coordinator, and the coordinator runs the fleet. The coordinator does not write code itself; because it delegates rather than executes, "it is never blocked and is always responsive to direction."

That last detail matters more than it looks. The reason a single agent feels frustrating is that it goes heads-down and you wait. A coordinator stays free to talk to you while its subagents grind, which is what makes "direct, do not babysit" actually feel different in practice.

How a Project works under the hood

Under the marketing, Projects is a thin orchestration layer over four things Cursor already had: the coordinator, subagents, cloud execution, and automation triggers. Here is how they fit together.

The coordinator plans and delegates

You oversee a Project by chatting with its coordinator agent. It "plans the work, delegates it to agents that implement it, and brings the finished work back to you to check," creating and managing agents on your behalf and running as many in parallel as the work needs. Underneath, each subagent works in its own context window, runs autonomously, and returns its result to the parent. Since Cursor 2.5, subagents can even launch their own child subagents, though the tree stops at one level deep.

One honest caveat the docs are upfront about: parallelism is not free speed. Running five subagents in parallel uses roughly five times the tokens of a single agent, and they can even be slower on simple tasks because each starts from a clean context. The win is isolation and scale, not raw pace.

Cloud by default, local when needed

Projects run on Cloud Agents (the isolated cloud VMs formerly called Background Agents). A Project "runs on its own computer, so closing your laptop doesn't stop it," which is what lets it run far more subagents in parallel than your machine could. When something needs to run on your box, the coordinator spins up a local agent for it.

The setup that actually matters here is the environment. As Cursor puts it, "not setting up a development environment for your cloud agents is like not giving your engineers a computer." You define it via agent-led setup, a saved snapshot, or a Dockerfile, and cloud agents clone from GitHub, GitLab, Azure DevOps, or Bitbucket and push to a branch for handoff. If you have wired up Claude Code's GitHub integration or similar, the shape will feel familiar.

Shared context that compounds

This is the piece I find most underrated. Cursor's line is "you shouldn't have to onboard an agent every time you start a task." Each Project keeps a set of files that sync across every cloud and local machine its agents use, and agents write research, artifacts, and what they learn about your codebase into it. The example: "if one agent figures out how to test a service, every future agent can use those instructions."

The result is that context grows with the Project and the coordinator gets more effective over time. It is the same principle behind giving an AI support agent a real knowledge base instead of re-explaining your product every session, just pointed at a codebase.

Subscriptions run it without a prompt

The coordinator can watch a Slack channel, run on a schedule, or follow all your PRs, fixing CI and acting when they open or merge. Cursor markets this as "subscriptions"; in the docs it is the Automations system, which fires cloud agents on schedules or on events from GitHub, GitLab, Slack, webhooks, Linear, Sentry, and PagerDuty. Point it at a bug-report channel and it starts delegating each time a bug comes in. This is the automation layer that turns Projects from a tool you open into a thing that runs, the same trigger-driven idea behind a Slack AI chatbot or an AI helpdesk chatbot that acts on new messages.

The three kinds of work Projects is built for

Cursor is refreshingly specific about where this fits, and it maps to three patterns. This is the part worth internalizing, because Projects is genuinely not for a five-minute fix.

• Feature work. Agents research the system and record what they learn as shared context, the coordinator plans it, and subagents build and test parts in parallel. After shipping, the same Project can monitor logs and handle bug reports with the full context behind the original decisions.
• Migrations. Cursor's phrase is work that is "easy to start and difficult to finish." You agree a safe approach with the coordinator, then it applies that approach incrementally across the codebase. You review each PR closely early on, then ease off as the pattern holds.
• Gardening. Work that never really ends, like code quality and regressions. Cursor's own example is a design-system Project whose coordinator scans every new PR, extracts components, and adds a lint rule whenever it sees the same mistake twice, on track to touch 20 to 100 PRs a day.

The common thread: this pays off when the work "will outlive a single chat." For a quick bug fix, a plain agent is faster and cheaper.

Not sure which bucket your work is in? Here is a quick way to check before you spin up a Project.

What Cursor Projects costs

There is no sticker price for Projects, and that is the honest headline. Projects run on Cloud Agents, and Cloud Agents are charged at API pricing for the model you select. A paid Cursor plan is required to run cloud agents at all, and an admin has to connect source control first. Here is the cost picture in plain terms.

A worked example makes it concrete. The design-system "gardening" Project Cursor describes is on track to touch 20 to 100 PRs a day. Every one of those runs is a cloud agent (often several subagents) billing at model API rates, all day, whether or not you are watching. That can be a fantastic deal versus an engineer's time, or a surprising bill, depending entirely on your spend limit and how chatty the models are. This is why the full Cursor pricing picture matters more than ever with Projects, and why usage-based cost worries are the recurring theme in community reactions, which brings us to the interesting part.

Is a "cockpit for agent fleets" what developers actually want?

This is where I want to be fair, because the launch-day reaction was not all applause. The launch post pulled 5,861 likes, but the loudest early reply was fatigue, not awe:

"can you pls just merge the subscriptions instead of just adding extra features?"

Gokul Bala (@GokulsVision), X

That is the top comment on the announcement itself. It captures a real worry: Projects stacks another paid, cloud-metered surface on top of an already busy product. And in April 2026, product writer Aakash Gupta framed the strategic bet cleanly (writing about Cursor's direction, not this exact launch):

"Cursor's move is to go vertical on the orchestration layer... They're saying: the model is a commodity, the workflow is the moat. The question is whether developers want a dedicated cockpit for managing agent fleets, or whether the terminal where the model lives is enough."

Aakash Gupta (@aakashgupta), X

That is the whole debate in two sentences. Some developers love the reviewable, structured surface. Elliot Arledge, writing in July 2026, put the pro case well:

"for most important dev and contracts I've been doing, cursor is my go-to and its not even close... being able to inspect code and ensure that production systems don't get slopified is super important to me."

Elliot Arledge (@elliotarledge), X

The counter-anxiety, in a reply under that same thread, is the one I think is most worth taking seriously: "I really fear losing control over my codebase." The more the coordinator delegates, the fewer lines any single reviewer actually read. That is not a reason to avoid Projects. It is a reason to keep your review discipline exactly where it was on day one, especially as the pattern "holds up" and you are tempted to skim. If you are weighing this against other tools, our Cursor alternatives and Cursor vs Windsurf rundowns cover where each lands.

What this "direct the fleet" model looks like beyond code

Here is the thing that struck me most, building agent systems at eesel: Cursor Projects is a coding-specific instance of a pattern that is showing up everywhere. A coordinator that plans and delegates, subagents that do the work, shared context that compounds, triggers that run it without a prompt. Swap "codebase" for "support queue" or "content pipeline" and the architecture is the same.

That is exactly how eesel is built, just pointed at different jobs. eesel is an AI teammate platform, and you hire ready-to-work teammates for a specific role rather than an all-purpose bot. The current roster is an AI helpdesk teammate and an AI blog writer, each arriving with the skills, integrations, and company context for its job. The helpdesk teammate joins your existing queue and drafts or resolves tickets; the blog writer researches and writes long-form content the way this post was built. Same "you direct, the agent does the work" shift Cursor is selling, aimed at customer service automation and SEO content teams instead of pull requests.

And because this post is really about agentic, terminal-driven workflows, the CLI parallel is worth spelling out. Cursor lets you drive cloud subagents from your editor with commands like /in-cloud and /autopilot. eesel exposes the same kind of programmable surface for its teammates: the eesel CLI (@eesel/cli) is a real npm binary whose docs literally say "everything on this site can be done from the terminal." You can eesel integrations connect, edit the agent's standing rules with eesel instructions, gate risky actions with eesel approvals, and watch every run newest-first with eesel activity. Every command prints JSON and supports --dry-run, so it slots straight into CI, and each workspace is also an MCP server, wired up like any other MCP integration, which means a coding agent like Cursor, Claude Code, or Codex can operate your support or content teammate directly. That eesel activity observability view maps almost one-to-one onto Cursor's "bring the finished work back to you to check."

The one place a support or content teammate has to go further than a coding coordinator: you cannot "review each PR" when the agent is talking to a live customer. That is why eesel lets you simulate a teammate against your real historical tickets before it ever replies, and hold actions behind approvals until you trust it. It is the same lesson the Cursor skeptics are pointing at, applied to work that ships straight to a person.

Try eesel

If Cursor Projects sold you on the "direct a fleet of agents, do not babysit them" model and you run a support or content team, that is exactly what eesel does for those jobs. You plug an AI helpdesk teammate into Zendesk, Freshdesk, Gorgias, or Slack, it learns your history and help center, and it starts drafting and resolving tickets, or point the AI blog writer at your content pipeline instead of stitching together separate AI writing tools. It is driveable from the dashboard or entirely from the terminal via the eesel CLI and MCP server, and you can simulate it on real data before it goes live. It is free to try.