How to Use Cursor Projects With a Coordinator, Subagents and Shared Context

01

Overview

Cursor Projects is built for software work that is larger than a normal one-off agent request. Instead of manually opening several coding-agent conversations and keeping each one aligned, you give a Project a durable objective and work through a coordinator that plans, delegates and retains shared context over time.

This guide focuses on the practical operating pattern rather than repeating the broad product overview. Cursor Projects entered beta on September 10, 2026, so exact controls and packaging can still change as the product evolves.

02

1. Confirm Projects is available on your account

Cursor says the beta began rolling out to all users on September 10. Projects appears in the left-hand navigation when access is available.

Because this is a beta rollout, do not assume that every account sees the feature at exactly the same moment. If it is not visible, check current Cursor release notes before trying to reproduce old screenshots or workarounds.

03

2. Create a Project around a durable outcome

A Project works best when the goal is bigger than a single code edit. Good examples include shipping a feature across multiple services, completing a framework migration, reducing a recurring class of regressions, cleaning up a design system or maintaining a long-running engineering program.

Give the coordinator a clear outcome, relevant repositories or systems, important constraints and the definition of done. Avoid treating the first prompt as a request to immediately rewrite everything. The coordinator is designed to research, plan and delegate.

A useful brief normally includes:

• the business or technical outcome;
• repositories or services in scope;
• boundaries that must not be crossed;
• testing expectations;
• review or approval requirements;
• any known dependencies or risky areas.

The stronger the boundaries are, the easier it is to review parallel agent work later.

04

3. Let the coordinator research before delegating

Cursor describes the coordinator as the planning layer. It is not simply another coding agent that writes every change itself. It can investigate the codebase, build a plan and create subagents for pieces of work that can be separated.

For a feature, that might mean one agent researches the data model, another studies the frontend integration and another maps the test surface. For a migration, the coordinator can identify recurring patterns before applying them across many pull requests.

Review the plan before accepting a large amount of parallel work. Cursor says Projects can use very large numbers of subagents, but “thousands of subagents” is a vendor capability claim, not a recommendation to maximize agent count on every project.

05

4. Build useful shared context

Projects maintain shared files that Cursor says can synchronize across the cloud and local machines used by agents. This is one of the most important parts of the workflow because future agents can reuse what earlier agents discovered.

Useful shared material can include:

• how a service is tested;
• architecture notes;
• research findings;
• migration rules;
• naming or design-system conventions;
• known failure modes;
• project-specific review expectations.

Treat this as explicit project memory rather than magical model memory. Important facts should be written clearly enough that another engineer could inspect them. Review what agents save, especially when it affects production behavior or security-sensitive systems.

06

5. Let the coordinator delegate bounded tasks

Once the plan and context are strong enough, the coordinator can create agents for separate tasks. The best candidates for parallelism are pieces of work that have clear boundaries and limited overlap.

Examples include independent package migrations, separate UI components, research tasks, tests for different services or repetitive code-quality fixes.

Work that touches the same files or architectural decision at the same time may be better sequenced. More parallel agents can increase merge conflicts and coordination cost, so use agent count as a means to complete the project rather than a score to maximize.

07

6. Use cloud agents for persistent work

Cursor says a Project runs on a cloud computer and can keep working after your laptop is closed. This is useful for research, multi-file implementation, long test runs and tasks that do not require a developer’s local-only environment.

Cloud execution also makes it possible for a Project to continue after an external event, such as a pull-request review or a scheduled timer.

That does not mean a Project should be left completely unsupervised. Review generated changes, test important behavior and preserve normal code-review controls.

08

7. Use a local agent when the work needs your machine

Cursor says the coordinator can start a local agent when a task specifically needs to run on the user’s machine.

This is useful when the required environment, credentials, hardware or development setup is not available in the cloud. A common pattern is to let cloud agents research and implement, then use a local agent for a test or validation step that depends on local resources.

Be deliberate about what local access an agent receives. A local agent may be able to interact with resources that are not available in a cloud sandbox, so normal credential and environment hygiene still matters.

09

8. Review pull requests and intermediate results

For large Projects, review should happen throughout the work rather than only at the end. Cursor’s own migration examples describe close human review early in a repeated pattern, followed by reduced oversight after the approach proves stable.

A practical review rhythm is:

1. inspect the initial research and plan;
2. review the first implementation of a repeated pattern;
3. confirm tests and CI behavior;
4. approve broader repetition only after the pattern is sound;
5. sample later changes and investigate exceptions.

This is especially important in migrations, where one incorrect assumption can otherwise be copied across many pull requests.

10

9. Add subscriptions when the Project should react to events

A Project can become more persistent by waiting for external events through Cursor’s subscription system. Cursor documents event sources including GitHub, Slack, Linear and timers.

You might use this after the core workflow is working reliably: continue after CI fails, react to review feedback, watch a Slack bug-report channel or run a recurring maintenance routine.

Subscriptions deserve their own configuration discipline because they can turn a Project from a manually supervised workflow into a recurring one. The separate Cursor Projects Subscriptions guide covers those event sources and limits in more detail.

11

Example: using Projects for a framework migration

Suppose a repository needs a dependency or framework migration across dozens of packages.

Start by asking the coordinator to inventory the affected code, find the recurring migration patterns and document the rules. Review that research. Then let one or a small number of agents implement representative cases.

After those examples pass review and CI, the coordinator can delegate the same pattern across more packages. Keep exceptions visible rather than forcing every case through the same transformation.

Cursor says it has used Projects internally for migrations spanning hundreds of pull requests. That is a first-party usage example, not an independent guarantee that the same scale will be efficient in another codebase.

12

Example: using Projects for a feature

For a feature spanning backend, frontend and tests, the coordinator can first map dependencies and record shared context. It can then delegate independent portions while preserving the overall plan.

When the feature is ready for environment-specific validation, a local agent can handle tasks that need the developer’s machine. After release, a subscription can watch for bug reports or pull-request activity if continued monitoring is useful.

13

What not to do

Do not begin by asking the coordinator to unleash the maximum possible number of agents. Do not assume shared context is automatically correct. Do not merge large batches of AI-generated pull requests without review. Do not invent a Projects-specific quota or price from general Cursor plan information.

Projects reduces orchestration overhead; it does not remove the engineering work of setting boundaries, reviewing decisions and validating software.

14

FAQ

Do I need to manage every Cursor subagent manually?

The purpose of the coordinator is to plan and manage delegated work for you. You still review the plan and results, but you do not have to manually coordinate every agent conversation.

Can a Cursor Project keep running when my laptop is closed?

Cursor says the Project runs on a cloud computer, so cloud work can continue after the laptop is closed.

Can Cursor Projects run something locally?

Yes. Cursor says the coordinator can start a local agent when a task needs to run on the user’s machine.

Does Cursor Projects remember previous agent work?

Projects maintain shared files that agents can add to and reuse. Treat that as explicit shared project context, not as a guarantee of perfect hidden memory.

How many agents should I use?

Cursor says Projects can delegate to very large numbers of subagents, but it does not publish one optimal number. Use only as much parallelism as the work can safely support.