Cursor launches Projects, delegates tasks to thousands of subagents, and runs recurring work for months without prompting

Cursor has launched Projects to take on larger chunks of work—a feature, a migration, or an entire application. It retains context across months of work, delegates tasks to thousands of subagents, and runs recurring work without prompting. The feature is currently in beta and rolling out gradually to all users.

In the launch video, Cursor employee Fredrika Lindh noted that previously her work was scattered across multiple threads, whereas now there is only this single conversation, with the coordinator agent managing it all. Another employee remarked that it moves beyond question-and-answer dialogue, eliminating the need to micromanage each agent individually, feeling more like collaborating with an autonomous coworker.

The coordinator agent only plans and delegates, writing no code itself

Projects can be opened directly from the left sidebar, where the main interface is a single conversation with the coordinator agent. The coordinator agent writes no code itself; instead, it is responsible for planning the work, delegating it to implementation agents, and handing completed work back to you for review. It creates and manages agents on your behalf, running as many in parallel as needed. Fredrika mentioned that some of her Projects have thousands of agents, spun up on demand without real constraints.

Cursor previously shared a multi-agent experiment: having a swarm of agents rewrite the SQLite database from scratch using only an 835-page manual. In the group using the Grok 4.5 model, the legacy setup ran for two hours with a test pass rate lingering near 0 until it was halted manually. Given the exact same problem with the new division of labor—where the planning agent only breaks down tasks and writes no code—it passed about 80% of the tests in four hours (both the experiment and figures were designed and tracked internally by Cursor).

The delegation process can be seen in this screen recording: the user creates a new Projects called 'Tabs' and asks it to figure out how tabs are implemented in a desktop app (Grok) and how their architecture could be modified. The coordinator agent outlines its plan, then dispatches a subagent to read the Projects specification and examine the codebase. The demo ends while the subagent is still reviewing code.

How the coordinator agent hands work back to you is demonstrated in another Projects shown during the launch talk: the dashboard lists 64 PRs (pull requests—proposed changes awaiting merge into the main codebase, typically requiring review and checks beforehand). When the user asks which changes are small and already safe to merge, the coordinator agent lists a few of the closest candidates before explaining that none are ready just yet—some lag too far behind main and need updating first, while others haven't verified pre-merge checks—and suggests addressing the closest one first. When the user sends a screenshot showing all icons missing, it confirms the issue, states it will investigate, routes the fix to the responsible change, and holds off marking it merge-ready until repaired.

Who makes the final merge call: the original page states that the coordinator agent hands completed work back to you for review; in another demo Projects named Browser, notes state that PR merges were executed after verification by Fredrika herself. Another screen indicates that certain approvals had already passed automatically—Security checks and codeowners sign-off—while the system was still awaiting CI (the automated tests and builds run on each change) and Bugbot (Cursor's automated code review tool). The demo also features scenes where it waits for a 'go' from you before merging a PR; whether it can merge on its own without confirmation or be configured for auto-merging is not mentioned in either the original page or the video.

Running in the cloud, with testing on your local machine

Projects runs via Cloud Agents: each Projects has its own dedicated computer in the cloud, so it keeps running even when you close your laptop. The original page also notes that agents within Projects may utilize multiple cloud machines as well as your local computer, with shared files synced across the machines they use; as for which specific machines subagents run on, the original page does not elaborate. Signs of multi-machine coordination are also visible in the video: around the 88-second mark, a response mentions that one virtual machine failed to push code, so it assigned the same fix to another machine that had already pushed successfully.

When a task requires testing on your machine, the coordinator agent launches a local agent to execute on your computer. In the launch video, the user asks it to run the application locally to test a merged UI change ('Align More with titles', aligning the element named More with item titles); the coordinator agent replies that it will launch Glass (which appears on screen to be the application they are developing) on her machine so she can verify the positioning of More against the titles.

Shared context synced across machines: no more onboarding from scratch each time

Cursor's rationale is that you shouldn't have to onboard an agent from scratch every time a new task begins. Projects handles this by maintaining a set of shared context files synced across every cloud and local machine its agents use.

This set of files holds three categories of content:

• Architecture and proposal artifacts: For instance, under the documentation directory (Project/docs) of the 'Browser' Projects, documents written by agents are stored, including design proposals like electron-concepts.md;
• Reusable troubleshooting and testing instructions: If an agent figures out how to test a given service, every subsequent agent can reference those instructions directly;
• Preference and habit memory: The coordinator agent remembers your working preferences. When creating the Tabs Projects, the coordinator agent's opening line notes, 'tell me to do things differently at any point and I will remember'; during the launch talk, Fredrika mentioned that as soon as a PR opens, it has already run two skills on its own: one for code simplification, and another called Thermos (which appears on screen to produce review comments). 'Skills' here refer to predefined, reusable sets of operating instructions; it ran them automatically because Fredrika had requested them previously. In the Subscriptions setup demo below, the interface also shows it editing preferences.md.

Cursor states that shared context accumulates alongside Projects, making the coordinator agent increasingly efficient the more it is used.

Subscriptions: set it up once, and it starts working based on signals and schedules

Once you tell the coordinator agent what to monitor, it gets to work on detected signals or according to schedule without requiring you to prompt it each time. The original page highlights three types of signals:

• Slack channels: The original page gives the example that after connecting Slack and pointing it to a bug-reporting channel, it automatically begins dispatching tasks whenever a new bug is reported;
• Schedules (cron jobs): Executing recurring work on schedule. For example, the aforementioned Browser Projects configured an overnight task (merge-readiness watch) that checks every hour to see which PRs are ready to merge, resolving code conflicts, CI failures, or Bugbot issues as they arise;
• Repository PR statuses: Tracking all of your PRs, including those on GitHub and Cursor's proprietary code hosting platform Origin.

How are these subscriptions and listeners configured? When asked in the launch talk, employees noted that there is no onboarding flow or step-by-step setup wizard; interacting with it feels just like an ordinary conversation, yet it scales significantly.

In the screen recording above, the user types a single prompt in natural language within the 'Design System' Projects: listen for all incoming merged PRs and check for design system violations—such as whether an existing component should be used, a variant created, style overrides stripped, or a new component added. The coordinator agent replies that it will monitor merges and flag these issues, the UI shows it editing preferences.md, and a subscription named 'Design system merge watch' appears, configured to run every hour.

Internal numbers and what remains unclear

In the launch video, Cursor employees mentioned some internal metrics: internally, they observed that people using Projects merged about 6x more PRs per week; during the first week of adoption, merge rates rose by roughly 30%. These figures reflect spoken remarks by employees in the video and do not appear in the text of the original page; the video did not specify the comparison baseline, statistical methodology, what 'merge rate' specifically measures, or whether 30% denotes a relative increase or percentage points.

Neither the text of the original page nor the video mentioned pricing models or usage limits.

Fredrika remarked that this has been their way of working for months, and Projects is the first time it has been packaged so that others can easily use it as well.