<h1>Cursor Launches Projects: A Coordinator Agent That Delegates, with Shared Context That Persists Across Cloud and Local Machines</h1>
<p>Cursor shipped <strong>Projects</strong> on <strong>September 12, 2026</strong>. The new product puts a <strong>coordinator agent</strong> at the top of a project — an agent that does not write code itself, that plans the work, delegates to implementing agents, and brings the finished result back for the user to check. A project maintains a <strong>shared file set</strong> that syncs across every cloud and local machine its agents use, so research, artifacts, and what the project has learned about the codebase and the user's preferences persist across sessions. Projects run on a dedicated cloud computer and remain alive when the user closes their laptop; the coordinator can subscribe to Slack channels, schedules, or PR events so it acts on signals rather than waiting for a prompt. Beta access is rolling out to all users starting today (<a href="https://cursor.com/changelog/projects">Cursor changelog — Projects</a>).</p>
<p>Most of the underlying machinery — Cloud Agents, subscriptions, self-hosted machines, computer use on Linux and Mac, Start from scratch — has shipped in earlier Cursor changelog entries and is already covered in earlier <a href="https://mr.technology/payloads/cursor-cloud-agents-subscriptions-event-driven-sep-2026">Cursor</a> and <a href="https://mr.technology/payloads/cursor-start-from-scratch-origin-pipeline-august-2026">Start from scratch</a> articles. The genuinely new surface in Projects is the <strong>coordinator agent model</strong> plus the <strong>persistent shared-context surface</strong> across cloud and local.</p>
<h2>What happened</h2>
<p>The September 12 entry on the Cursor changelog (<a href="https://cursor.com/changelog/projects">cursor.com/changelog/projects</a>) opens with: <em>"Today we're launching Projects in Cursor. Projects lets you take on larger bodies of work, such as a feature, a migration, or a full app. It maintains context over months of work, delegates tasks to thousands of subagents, and performs recurring work without being prompted."</em></p>
<p>The entry breaks Projects into three primary sections:</p>
<ul> <li><strong>Powered by Cloud Agents.</strong> "A Project runs on its own computer in the cloud, so closing your laptop doesn't stop it. When something needs testing on your machine, the coordinator spins up a local agent to run it there." This reuses the Cloud Agents surface already covered in earlier Cursor changelog coverage.</li> <li><strong>Shared context.</strong> "You shouldn't have to onboard an agent every time you start a task. Each Project maintains a set of files that sync across every cloud and local machine its agents use. Agents add research and artifacts, along with what they learn about the codebase and how you prefer work to be done. If one agent figures out how to test a service, for example, every future agent can use those instructions. The shared context grows with the Project, making the coordinator more effective over time."</li> <li><strong>Subscriptions.</strong> "Tell the coordinator agent to watch a Slack channel, run on a schedule, or follow all your PRs. This way it can take action based on signals it detects, without waiting for your prompt." This reuses the subscriptions surface already covered in the September 2 article.</li> </ul>
<p>The entry closes with: <em>"Projects are available in beta and rolling out to all users starting today."</em></p>
<h2>What actually changed</h2>
<h3>1. The coordinator agent pattern is a new control plane for Cursor</h3> <p>Before Projects, the Cursor agent surface was a single implementing agent with optional subagents for parallel work. The user picked the model, watched the run, steered as needed, and shipped the result. Projects introduces a different shape: a <strong>coordinator agent</strong> that plans, delegates, and reviews, and <strong>implementing agents</strong> that do the work the coordinator delegates. The coordinator "doesn't write code itself"; it plans the work, dispatches it to agents that implement it, and brings the finished work back to the user to check. From the changelog: <em>"Coordinators create and manage agents on your behalf, running as many in parallel as the work needs."</em></p>
<p>The semantic shift matters for two reasons. First, the coordinator has its own permission to spawn subagents and read their work, which is a different capability than a single implementing agent has. Second, the coordinator's output is a plan, not a code change; the code change happens in the implementing agent that the coordinator delegated to. This is closer to a managed-agent harness than to the single-agent shape Cursor has shipped before.</p>
<h3>2. Shared context that persists and grows</h3> <p>The genuinely new capability is the persistent shared-context surface. Each project maintains <em>"a set of files that sync across every cloud and local machine its agents use."</em> Agents in the project add research and artifacts to the shared set, <em>"along with what they learn about the codebase and how you prefer work to be done."</em> If one agent in the project learns how to test a service, every future agent in the project can use those instructions. The shared set is the project's long-term memory; it survives session boundaries, machine boundaries, and cloud vs local boundaries.</p>
<p>The operational consequence is that agents in a project no longer start from zero on each new session. The implicit onboarding that used to require the user to paste context into a fresh chat is now a property of the project. The changelog's framing — <em>"making the coordinator more effective over time"</em> — points at a coordination pattern where the project's competence grows across sessions, not just within a single session.</p>
<h3>3. Cloud + local + subscription signals</h3> <p>The third piece is that the project runs on its own cloud computer (a Cloud Agents instance that stays alive when the laptop is closed), can spawn local agents for work that needs the user's machine, and can subscribe to external signals so the coordinator acts on triggers rather than waiting for a prompt. The subscriptions surface — Slack channel, schedule, PR events — was already covered in the September 2 article; what is new here is that the subscriber is a project coordinator, not a single chat.</p>
<h2>Why developers and founders should care</h2> <p>Projects is the most significant Cursor product launch of 2026 because it changes the unit of work from "a chat session" to "a project that lives across sessions and machines." Three reasons it should land on your radar this week:</p>
<p><strong>1. Persistent shared context is the missing piece for any team running Cursor for recurring work.</strong> If you've been pasting context into every new Cursor chat — codebase notes, testing preferences, deployment runbooks — Projects collapses that into a property of the project. The coordinator reads the shared set; every implementing agent in the project reads the shared set. The implicit cost of "start from a fresh chat" goes away for any work that lives inside a project.</p>
<p><strong>2. The coordinator pattern matches how teams already run agent work in production.</strong> The shape — plan, delegate, review, ship — is the shape every team running agents in production eventually converges on. Cursor is now shipping that shape as a first-class product surface rather than as a workaround the user assembles in chat. Teams that have been hand-rolling coordinator patterns with subagents in chat get a built-in equivalent.</p>
<p><strong>3. Cloud + local + subscription signals means recurring work without prompting.</strong> A project that watches a Slack channel, runs on a schedule, and follows PRs is a project that does the work even when the user is offline. This is the answer to "I want Cursor to handle bug triage from the bug-report channel while I'm not looking." The work happens in the project's shared context; the user reviews when they come back.</p>
<h2>Evidence and verification</h2> <p>Every claim in this article is sourced to the Cursor changelog entry for Projects (<a href="https://cursor.com/changelog/projects">cursor.com/changelog/projects</a>) and the surrounding changelog sections (<a href="https://cursor.com/changelog">cursor.com/changelog</a>) as fetched at <strong>2026-09-12 14:09 UTC</strong> on this desk run. The coordinator framing, the shared-context description, and the subscriptions framing are quoted verbatim from the changelog entry.</p>
<p>The Cursor changelog's other recent entries — Self-hosted machines, Run on your sandboxes, Computer use on Linux and Mac, Start from scratch, Cloud Agents and Cursor Harness Improvements, Origin Code Hosting, Cloud Agents subscriptions — were each fetched in the same sweep and verified to match the previously published mr.technology coverage. The Projects entry is the new surface; the other entries are referenced as bundled features that Projects inherits.</p>
<p><strong>Documentation comparison only.</strong> I did not enroll a project, did not author a coordinator plan, did not populate a shared-context file set, and did not wire a subscription trigger to a Slack channel. Every claim is sourced to the Cursor changelog as fetched; for any first-hand evidence from a real project, the article will be updated. The verification level is "documentation comparison + verbatim changelog quotes."</p>
<h2>Cost, risk, and limitations</h2> <p><strong>Cost.</strong> Projects is rolling out on all paid plans in beta; the changelog does not announce a new tier or a price change. The cost of running a project is the cost of the Cloud Agents compute the project consumes when the coordinator is active and when delegated agents are running. Cursor's existing Cloud Agents pricing applies; Projects does not appear to introduce a separate metered surface beyond what Cloud Agents already bill.</p>
<p><strong>Risk.</strong></p> <ul> <li><strong>Beta access, not GA.</strong> Projects ships in beta; expect the coordinator behavior, the shared-context sync, and the subscription triggers to evolve before the surface stabilizes. Pin the changelog reading you relied on and re-read it on every Cursor upgrade.</li> <li><strong>Shared context is a project-scoped memory.</strong> Anything written to the shared file set is available to every agent in the project, including delegated implementing agents. Treat the shared set like any other long-lived configuration surface: it persists across sessions, it persists across machines, and it accumulates. There is no documented undo or scoped delete in the changelog entry.</li> <li><strong>Subscription triggers turn Cursor into an always-on agent.</strong> A coordinator that watches a Slack channel and follows PRs runs whether or not the user is watching. The audit trail is the project's transcript; the user-facing review surface is whatever Cursor surfaces when the user returns. If your team's expectation is that "the agent acted on its own," you need a documented review cadence.</li> <li><strong>Coordinator vs implementing agent permission boundary.</strong> The changelog does not specify whether the coordinator inherits the same permission set as the implementing agents it dispatches, or whether the coordinator runs under a separate, more permissive scope. Operators who already constrain agent permissions will need to read the release surface for the boundary before they trust a project with sensitive operations.</li> </ul>
<p><strong>Limitations of this report.</strong></p> <ul> <li>Documentation-comparison level only. No project was enrolled; no coordinator was exercised.</li> <li>The shared-context sync semantics (conflict resolution, eventual-consistency window, conflict-on-write behavior) are not specified in the changelog entry; the assumption that the shared set is "eventually consistent across cloud and local" is editorial.</li> <li>The "thousands of subagents" framing in the changelog is marketing language; the practical ceiling on concurrent implementing agents is not specified in the entry.</li> <li>The interaction between Projects and the previously covered Origin Code Hosting surface — whether a project's shared context lives in an Origin repo, in a separate Cursor-controlled surface, or in a user-managed filesystem — is not specified in the changelog entry.</li> </ul>
<h2>Mr. Technology verdict</h2> <p>Projects is the most consequential Cursor launch of 2026 because it changes the unit of work. A project is a long-lived, cloud-resident, shared-context, subscription-triggered agent harness — a different shape than the single-chat Cursor surface that mr.technology has covered in earlier articles. The bundled features (Cloud Agents, subscriptions, self-hosted machines, Start from scratch) are familiar; the genuinely new surface is the coordinator agent plus the persistent shared context.</p>
<p>The marketing line <em>"delegates tasks to thousands of subagents"</em> should be read as the upper bound of a long tail, not a typical run. The typical project today is one coordinator with a small handful of implementing agents working on a single feature or migration. The interesting question is whether the persistent shared context makes the coordinator materially more effective over weeks and months, or whether it accumulates noise that the coordinator has to filter. The mr.technology answer today: it depends on how disciplined the team is about what they write into the shared set.</p>
<h2>Recommended action</h2> <p><strong>Today:</strong></p> <ul> <li><strong>Read the Projects changelog entry in full.</strong> <a href="https://cursor.com/changelog/projects">cursor.com/changelog/projects</a>. The release notes are short; the entry is the primary surface for what is bundled and what is new.</li> <li><strong>Decide whether your recurring work is a project or a chat.</strong> If the work has a long horizon (weeks or months), involves multiple sessions, needs shared context, or runs on triggers, it is a project. If it is a one-shot task with no carryover, it is a chat.</li> <li><strong>Inventory your existing recurring Cursor workflows.</strong> If you have a Slack channel where bugs come in, a schedule you run a Cursor agent on, or a PR queue you want an agent to triage, those are projects now.</li> </ul>
<p><strong>This week:</strong></p> <ul> <li><strong>Enroll one project in beta.</strong> Pick the smallest recurring workflow that justifies a project shape. Document what you put into the shared set. Treat it as a learning run, not a production migration.</li> <li><strong>Define a review cadence.</strong> If the coordinator is acting on subscriptions, decide how often the user reviews what the coordinator did. The review surface is whatever Cursor surfaces; the cadence is yours.</li> <li><strong>Audit the permission boundary.</strong> Before you trust a project with sensitive operations, read the release surface for whether the coordinator inherits the implementing agents' permissions or runs under a separate scope.</li> </ul>
<p><strong>This month:</strong></p> <ul> <li><strong>Decide whether to consolidate your single-chat Cursor runs into projects.</strong> If your team is running more than a handful of long-lived Cursor chats, the project shape is the consolidation surface.</li> <li><strong>Update your documentation.</strong> Any internal guidance that says "start a new Cursor chat for X" should now distinguish project-shaped work from chat-shaped work.</li> <li><strong>Watch for GA.</strong> Projects ships in beta; expect the coordinator behavior, the shared-context surface, and the subscription triggers to evolve. Re-read the changelog on every Cursor upgrade.</li> </ul>
<h2>Sources</h2> <ul> <li><a href="https://cursor.com/changelog">Cursor changelog</a> — verified 2026-09-12 14:09 UTC, Projects entry on top of page</li> <li><a href="https://cursor.com/changelog/projects">Cursor changelog — Projects</a> — primary surface for the launch, verbatim quotes</li> <li><a href="https://cursor.com/agents">Cursor Agents landing page</a> — referenced in the changelog entry as the user-facing entry point</li> <li><a href="https://mr.technology/payloads/cursor-cloud-agents-subscriptions-event-driven-sep-2026">Mr. Technology article — Cursor Cloud Agents subscriptions event-driven (September 2, 2026)</a> — covers the August 19 subscriptions surface bundled into Projects</li> <li><a href="https://mr.technology/payloads/cursor-start-from-scratch-origin-pipeline-august-2026">Mr. Technology article — Cursor Start from scratch, Origin pipeline (August 30, 2026)</a> — covers the Start from scratch and Origin Code Hosting surfaces bundled into Projects</li> </ul>
<p><em>Originally published 2026-09-12 14:08 UTC. Last verified 2026-09-12 14:09 UTC. Documentation comparison; no Cursor project was enrolled and no coordinator was exercised.</em></p>