Cursor Projects Moves Coding Teams to Review Queues

Cursor Projects changes the unit of coding work from a prompt to a review queue. On September 10, 2026, Cursor put a coordinator, shared project context, and recurring triggers into beta, so teams can delegate without starting each task manually and move the bottleneck into scoping, checking, and deciding what merges.

This is an operating-level explainer for engineering leads, technical founders, and agency owners. The useful question isn't how many agents Cursor can start. It is whether your team can absorb the work they return without losing control of cost or quality.

What Cursor Projects actually is

A Cursor Project is a long-running container for a body of work, such as a feature, a migration, or a full app. It has a coordinator agent, which is the manager in this setup. The coordinator plans the work and delegates implementation, but it doesn't write the code itself.

Implementation agents do the coding on cloud machines. The coordinator can create several of them, run work in parallel, and bring the results back for you to check. If a test has to run on your own machine, the coordinator can start a local agent there.

The second piece is shared context. Each Project keeps files that sync across the cloud and local machines its agents use. Those files can collect research, artifacts, codebase knowledge, testing instructions, and notes about how the team wants work done.

That changes the handoff. A fresh agent no longer has to rediscover the test command or the service boundary every time, provided the Project's stored context is correct and current.

The third piece is subscriptions. You can tell a Project to watch a Slack channel, run on a schedule, or follow pull requests. A matching signal can start new delegated work without somebody writing a fresh prompt.

Recurring agents themselves are not new to Cursor. Its August 19 release already let Cloud Agents monitor pull requests, Slack threads, and schedules. Projects puts that recurring work under one coordinator with shared context that can last across a longer stream of tasks.

That is the real release. Cursor isn't just giving you another coding chat. It is giving delegated work a persistent home.

Why the review queue is the business consequence

Shared context can reduce repeated setup. Cursor has not published a speedup number, and this beta is too new to support one, so don't put saved hours into a budget yet.

The measurable change is where team time goes. A coordinator can create implementation work in several parallel lanes while one reviewer still reads changes serially. That mismatch can turn an empty backlog into a full pull-request queue.

The queue is useful when tasks are narrow, tests are reliable, and a reviewer can make quick decisions. It becomes expensive when agents return broad diffs, duplicate work, or changes whose intent isn't clear. Parallel output is still inventory until somebody accepts it.

This doesn't affect every Cursor user equally. A solo developer handling one bounded task at a time may get little from a coordinator. A team with weak tests or no named reviewer can create more uncertainty than throughput. A team already running recurring Cloud Agent automations gains the most from shared Project context, not from the trigger itself.

Who can use it, and what changes for them

A SaaS engineering lead running a migration

Give one Project a bounded migration with explicit non-goals, test commands, rollout rules, and ownership boundaries. The coordinator can split mechanical changes across implementation agents while the lead reviews the sequence and the risky edges.

The payoff is continuity across several branches. The lead should measure accepted changes and review time, not agent activity.

An agency technical director managing client work

Keep one client's setup notes, coding conventions, test paths, and delivery rules in that client's shared Project context. Recurring maintenance tasks can start from the same operating instructions instead of a new onboarding prompt.

The payoff is less repeated briefing. The hard boundary is client separation: context and credentials for one account should never become a common pool for another.

A support engineering manager watching bug intake

Connect one public Slack bug-report channel and use a narrow qualification rule. A report with reproducible steps can enter the Project, while questions, duplicates, and account-specific incidents stay with a person.

The payoff is a prepared branch and evidence for review, not an automatic merge. Cursor's current Automations docs limit Slack triggers to public channels, and the Projects launch does not publish a separate channel support matrix.

A platform team with recurring maintenance

A Project can hold the testing instructions and service map for a repeated maintenance stream. The coordinator can follow pull requests or a schedule, then return implementation work to a named owner.

The payoff is a stable operating loop. A regulated team should wait until its security review covers the cloud runtime, synced context, secrets, and beta controls.

Run a bounded team pilot

Cursor has not published a Projects API or a detailed Projects setup guide. The honest pilot uses the visible beta surface and the related Cloud Agent controls that are documented today.

1. 1

   Confirm access and billing

   Look for Projects in Cursor's left-hand navigation. The launch says the beta is rolling out to all users, but Cloud Agents still require a paid plan. For a team pilot, verify the feature flag in the actual account, confirm the seat type, and set a team-wide spending limit before adding a recurring trigger.

2. 2

   Choose one repeatable job

   Use one repository and one class of low-risk work with a clear finish line. Good candidates have a known test command, a small diff boundary, and an owner who can judge the result. Keep migrations with unclear product decisions, authorization changes, and production incidents out of the first pass.

3. 3

   Write the shared operating context

   Give the Project the repository map, setup steps, test commands, definition of done, forbidden areas, and escalation rule. Treat these files as maintained operating documents. Wrong shared context repeats a mistake more efficiently.

4. 4

   Add one intake route

   Pick a schedule, pull-request subscription, or one Slack channel. State which signals qualify, what the coordinator may delegate, what evidence must come back, and when it must stop without changing code.

5. 5

   Own the review queue

   Assign one senior reviewer. Require the diff, test output, and relevant artifacts before a change can move forward. Keep merge authority outside the Project during the beta.

6. 6

   Measure the work that survives review

   Track work items started, changes accepted, review minutes, rework, escaped defects, and model usage. Compare those numbers with the same task class before the pilot. Do not convert agent count into productivity.

Price the pilot, including review time

The base plan is easy to see. Teams Standard costs $40 per user per month, so four new seats cost $160 for one billing cycle. Teams Premium costs $120 per user per month and carries five times Standard usage, but buying Premium before the pilot produces its own usage data skips the useful part of the test.

The variable line is harder. Cloud Agents are charged at the selected model's API pricing. Teams and Enterprise add a $0.25 per million token Cursor Token Rate to eligible third-party input, output, and cached tokens. On-demand usage is enabled by default for Teams, and team admins can set a monthly team-wide cap.

Here is a bounded model, with every workload number labeled as an assumption:

• Scope assumption: one repository, one trigger, and no more than 20 work items that reach review.
• Usage assumption: each complete work item, including coordinator and implementation-agent activity, consumes 100,000 uncached input tokens, 400,000 cache-read tokens, and 20,000 output tokens on Claude Sonnet 5, with no cache-write tokens.
• Review assumption: a senior reviewer reserves 20 minutes per returned item at a loaded cost of $100 per hour.

At Cursor's current Claude Sonnet 5 rates, the modeled work item costs $0.20 for input, $0.08 for cache reads, and $0.20 for output. The Team token rate adds $0.13 across 520,000 eligible tokens. That makes the modeled usage $0.61 per item, or $12.20 for 20 items.

Review is the larger line. Twenty items at 20 minutes each reserve 400 minutes, or 6 hours 40 minutes. At the assumed $100 hourly cost, that is $666.67 of reviewer time.

Add $160 for four new Standard seats and, counting the modeled usage whether or not it becomes overage, the gross planning total is $838.87 for the month. That is not an invoice forecast. Existing seats remove the $160 purchase, included usage may absorb the $12.20, and real Projects work may use more tokens because the coordinator can delegate to several agents.

The point of the model isn't that review always costs $666.67. It is that review needs its own budget line. Change the task count, minutes, and loaded rate to match your team before anyone calls the pilot cheap.

For the broader product and subscription decision, the main Cursor review covers the editor, Cloud Agents, pricing, and existing review gates.

The honest part

First, this is a beta rollout, not a settled operating standard. The launch names the left-hand navigation but gives no Projects-specific access matrix, usage breakdown, concurrency control, or service commitment. Availability can arrive before the documentation needed for procurement.

Second, shared context can carry stale instructions as easily as good ones. A testing note that was correct last month can mislead every future agent after the repository changes. Give context files owners, review dates, and deletion rules.

Third, the coordinator returns work for you to check. That is the product contract. It does not remove human review, executable tests, security checks, or merge ownership.

Fourth, the environment still decides whether an agent can prove its work. Cloud Agents need the repositories, dependencies, secrets, startup commands, and network access required by the task. A failed environment Build keeps the last successful Build active, but an incomplete environment can still produce plausible code without valid evidence.

Finally, every Project runs on a cloud computer, with local agents used when machine-specific testing is needed. Teams with private-network requirements should include that boundary in the review. Cursor Self-Hosted Machines can move tool execution onto customer-managed workers, but the Cursor agent loop and model processing remain in Cursor's cloud.

What to do now

Act this week if your team has repeated, testable work, a paid Cursor account with the beta visible, and a senior reviewer with room in the queue. Use Standard seats first, one repository, one trigger, and a hard spending cap.

Wait if Projects is not visible, the repository cannot run its checks in a Cloud Agent environment, or nobody owns review. Also wait if procurement needs a Projects-specific access or billing document that Cursor has not published.

You are mostly unaffected if your work is one-off, your agent sessions already carry enough context, or local execution is a hard requirement. The coordinator earns its place only when continuity across several delegated tasks is the bottleneck.

The Monday move is simple: choose one recurring task class, cap the pilot at 20 reviewable items, assign one reviewer, set the team spending limit, and record accepted changes, review minutes, rework, defects, and actual usage for one billing cycle. Keep Projects only if the reviewed output improves the workflow after counting both the model bill and the human queue.

Get the next operator-grade AI workflow breakdown in the newsletter.