On 2026-09-10, Cursor’s Projects entered beta, rolling out to all users (official launch blog). With this feature, developers can delegate multi-month engineering tasks to a persistent agent system: the coordinator itself does not write code, focusing exclusively on planning and orchestrating collaboration among multiple agents. The system drives ongoing work forward without humans waiting nearby to prompt it. Examining what Cursor built and the engineering costs it paid reveals the bets Cursor is placing on the future shape of software development.
Inside Projects, the primary counterpart shifts to the coordinator. The coordinator never touches code. It focuses entirely on planning, delegating specific tasks to individual agents, and aggregating finished work for human review. The official changelog explains that the coordinator replaces the user in creating and managing agents, spinning up executors in parallel on demand. According to the official launch blog, the coordinator remains responsive in the interface at all times; even while massive blocks of code stream underneath, user input is never blocked.
The feature lives in the Projects section of the left navigation in the Agents Window. When creating a new project, you enter a name, specify a code repository, and select a dedicated coordinator model (official documentation). Once configured, the entire system relies on three core mechanisms to operate.
The first mechanism is cloud-by-default execution. The official changelog notes that each Project runs on an isolated cloud computer, continuing uninterrupted even when a laptop lid is closed. The underlying execution units are Cloud Agents—Cursor agents running in isolated cloud VMs that clone the repository, perform the work, and deliver merge-ready PRs. For cloud agents to run builds and tests successfully, the runtime environment must first be initialized. A third-party review by eesel.ai quotes the official documentation’s analogy: not provisioning a dev environment for a cloud agent is like hiring an engineer without giving them a computer. If a task requires local validation, the coordinator spins up a local agent on the developer’s machine to assist, while core development stays in the cloud.
The second mechanism is cross-machine context synchronization. According to the official launch blog, each Project maintains a set of files synced in real time between cloud machines and local devices. Agents write research findings, intermediate artifacts, code understandings, and working preferences into these files, allowing shared context to accumulate continuously as the project progresses. While accumulating experience across machines via files, the coordinator also enforces strict context isolation during horizontal task delegation: complex tasks are divided among multiple subagents, each maintaining an isolated context window and returning only a summary of its results upon completion.
The third mechanism is trigger-by-external-signal. The official changelog explains that users can set the coordinator to monitor Slack channels, run on a recurring schedule, or track all PRs. As long as the system detects an external signal, it acts autonomously, without waiting idly for human prompts.
This setup is not for every developer. In a third-party review by flaviocopes, independent tech writer Flavio Copes pointed out that Projects is built around cloud agents, whereas he personally prefers not using cloud agents. Furthermore, the coordinator can fan out hundreds of subagents at once, consuming an immense volume of tokens. For developers used to controlling everything locally, or who are especially sensitive to token spending, this architecture clearly misses the mark.
The capabilities Projects offers today stem from a year and a half of continuous evolution. In 2025-05, Cursor launched Background Agent (forum update post), allowing engineering tasks to detach from active sessions and run in the cloud background for the first time, continuing even after closing the laptop. In 2026-01, Subagents arrived (2.4 changelog): a single agent could now spawn multiple subagents with isolated context windows, splitting large tasks and progressing in parallel. On 2026-02-24, background agents were upgraded to Cloud Agents (02-24 changelog): each agent runs inside its own isolated VM with a full development environment, capable of testing the software it builds and delivering finished PRs complete with videos, screenshots, and logs.
Version 3.0, released on 2026-04-02, shifted the interface focus: the Agents Window enabled agents to run in parallel across local machines, worktrees, the cloud, and remote SSH (3.0 changelog). On 2026-04-24, version 3.2 added /multitask (04-24 changelog): consecutive requests no longer queued sequentially, but were handed to a pool of asynchronous subagents for concurrent execution, with larger tasks automatically chunked. Concurrent orchestration evolved from an internal agent mechanism into a primary interaction model in the product.
On 2026-08-19, external subscriptions went live, and subagents moved into their own isolated VMs (08-19-26 changelog), completing the foundation of event-driven unattended operation and clean execution environments. On 2026-09-10, Projects officially debuted, unifying the coordinator, parallel subagent clusters, and shared context files into a persistently running engineering body. Every step in this evolution resolved the bottleneck of the previous phase: first running individual tasks in the background, then leveraging isolated VMs for concurrency, then introducing external signals for unattended execution, and finally consolidating everything into an engineering entity capable of spanning months.
Pushing deeper into these design choices reveals five core beliefs Cursor is betting on. Each aligns with a critical decision axis in the product: the unit of work, the position of humans, the trigger mechanism, the vehicle for experience, and the form of the workspace.
According to the official launch blog, Projects allows developers to take on larger engineering initiatives, such as landing an entire feature, completing a technical migration, or building a whole application from scratch. The system can maintain context over months, dispatch tasks to thousands of subagents, and execute recurring work without human prompting. Cursor shared a set of internal engineering metrics (all self-reported by Cursor): the team is using Projects to drive a codebase migration spanning hundreds of PRs, alongside a long-running Project maintaining design system compliance, which touches an estimated 20 to 100 PRs per day.
The baseline scale of software engineering delivery is shifting from local snippets altered by a single prompt into an engineering entity that persists autonomously and evolves across months. But shifting toward long-lifecycle engineering accumulation comes at a price: giving up the agility and disposable simplicity of starting fresh sessions without historical baggage.
Traditional AI-assisted coding requires developers to sit before screens inspecting generated diffs line by line, correcting variable names and function calls in real time. Under the Projects architecture, developers only need to define business objectives and acceptance criteria, reviewing delivered PRs at the end. The developer’s focus retreats from microscopic execution to upstream goal definition and downstream acceptance review.
Cursor placed this bet on itself first. The official blog post third-era, published on 2026-02-26, disclosed that 35% of merged PRs internally (self-reported by Cursor) were generated by agents running autonomously in cloud VMs. Cursor shifted its positioning from a coding assistant to a software production factory for developers. The coordinator touches no business code, focusing entirely on planning, delegating, and returning results—turning this philosophy into a tangible product.
In practice, however, acceptance costs remain substantial. On 2026-09-19, forum user golfingmoney posted in a forum handoff discussion thread that they had to establish strict rules requiring the coordinator to re-examine the output of each agent, discovering errors in roughly 50% of cases. A Cursor staff member explained that each agent only receives a task brief and shared project context, making it easy to drop details during handoffs. Lost details do not simply evaporate; they land squarely on human review, leaving verification costs unreduced.
An engineer’s core value is decoupling from writing code line by line, consolidating at the two ends: defining problems and accepting deliverables. This path also severs the developer’s immediate, real-time control over every incoming line of code.
External signal subscriptions debuted more than three weeks ahead of Projects. The 2026-08-19 changelog noted support for monitoring PRs, tracking Slack threads, or executing scheduled tasks, though subscriptions were initially limited to cloud agents. Cursor team member Andrew Milich highlighted this model in a public post: with event subscriptions, a shared filesystem, and persistent memory, a single agent can work across multiple PRs over long stretches of time.
The trigger for generating software is shifting from a person sitting at a keyboard starting an isolated chat to autonomous loops driven by external events and scheduled routines. Moving to signal-driven triggers eliminates manual kickoff; even when developers close their laptops and step away, agents react instantly upon catching a signal. Asynchronous automation brings immense convenience, but the trade-off is relinquishing human gating at task origination: occasional misinterpretations or spurious signals translate directly into spinning agents and mounting bills.
In recent years, the software engineering industry has converged on a consensus: for agents, context is the most critical asset. Whether it can accumulate across tasks over time dictates the complexity of work an agent can handle. Translating that consensus into a product immediately forces an answer to one question: where does experience live?
The official launch blog gives a direct answer: each Project maintains a set of files synced across machines, where agents write research findings, code understandings, and workflow preferences. Once one agent figures out how to test a service, subsequent agents reuse those patterns directly, and shared context expands as the project matures. Among the project’s shared files is notes.md, dedicated to logging engineering progress—a detail confirmed by forum staff member deanrie in an official forum reply. Beyond accumulating long-term experience in shared files, individual task execution must filter out short-term noise: the official documentation on subagents explains that running 5 subagents concurrently consumes roughly 5x the tokens of a single agent. This design purchases context isolation rather than raw speed; noisy intermediate steps remain contained inside subagents, while the parent coordinator receives only a final summary. Long-term experience settles into files; single-task context stays inside windows. A piece I wrote in March, Context Infrastructure, explored how agent engineering experience relies on filesystems to take root; the design of Projects brings this concept into a mainstream engineering platform.
The hard-won experience accumulated by agents over extended collaboration must land in a version-controlled filesystem that both humans and programs can read and write, without relying on black-box vector databases. Cursor avoided two common traps: it did not wrap long-term memory behind fuzzy retrieval interfaces, nor did it let a single context window balloon endlessly trying to hold all history.
Where is an agent’s primary workspace located? The official changelog states plainly that a Project runs on an isolated computer in the cloud, continuing without interruption even when a laptop is closed. When forum staff member Colin explained the technical trade-offs on 2026-09-14 in a cloud-first discussion thread, his original remarks specifically highlighted the word deliberately (meaning “deliberately, on purpose”): Projects is currently deliberately cloud-first to ensure task planning and delegation continue with laptop lids closed, and to allow the same project to be followed seamlessly across desktop, web, and mobile.
Placing the primary workspace entirely in the cloud creates real friction with local development setups. In the same discussion thread, forum user ZLH voiced the practical need for local workspaces on 2026-09-12: cloud sandboxes cannot invoke private MCP servers or proprietary tools configured on a developer’s local machine, and cloud-cloned repositories have no visibility into these local tools. This adds friction and cost while raising concerns over code exposure.
Cost pressures surfaced quickly. In a cost discussion thread on the Cursor forum, Anmol Arora lamented on 2026-09-22 that entering a single prompt inside Projects exhausted their token quota in an instant, complaining “it consumed all my tokens in no time” and asking why a basic task consumed nearly 500 million tokens. A Cursor staff member confirmed that the coordinator splits tasks across multiple concurrent agents, with each agent billed independently; against large codebases, costs can surge exponentially.
An agent’s baseline work environment is an isolated, full-fledged VM in the cloud, with the local machine serving merely as a peripheral node. This choice incurs two costs: projects relying on private local toolchains struggle to onboard, and during unattended autonomous execution, token bills multiply alongside concurrent agents, leaving no human in the loop to slam the brakes if things spiral out of hand. Among the five beliefs, this is the only one explicitly endorsed by official statements; evidence for the other four is written directly into what the product has built.
Across the four months between 2026-04-30 and 2026-09-08, three separate teams independently established persistent personal cloud computers as their system default. Together with Cursor, these three span general-purpose agents, account-level Bots, and personal assistants.
On 2026-04-30, Manus released Cloud Computer, abandoning the ephemeral paradigm where each session resets to blank; agents gained a persistent runtime environment where generated files and installed tools persist indefinitely, and multiple tasks share the same virtual disk (Manus launch blog). On 2026-08-11, xAI launched Grok Bot, where all Bots under the same account share a persistent cloud computer and browser session, powered by skills and routines for daily operations (Grok Bot FAQ; Grok Bot skills and routines documentation). On 2026-09-08, Meta rolled out its personal agent product Muse, pairing users and agents with a dedicated cloud VM serving as the system of record for all actions—handling code compilation, skill development, concurrent subagents, and scheduled tasks (Meta Muse launch blog).
Placing agents inside cloud VMs equipped with persistent filesystems is not an idiosyncratic choice by a single team, but an architecture multiple teams independently converged upon while pursuing long-horizon tasks. Grounding engineering experience in real files ensures humans can read, edit, and version-track it at any time, leaving clear audit trails whenever something goes wrong.
When choosing or using agent tooling, consider running your actual tasks through three questions:
First, evaluate the scope of your work units: which tasks actually require a multi-month engineering entity? If your day-to-day work consists of writing standalone scripts or fixing localized bugs, introducing a long-lived coordination layer only adds operational friction and concurrent token consumption; an isolated single-session chat remains far leaner and faster.
Next, assess the automation of your acceptance criteria: can acceptance criteria be clearly specified as tests that run automatically? If your team still reviews diffs manually line by line, floods of changes generated by concurrent agents will quickly drown developers in review fatigue. Stepping humans out of the execution loop only yields genuine productivity gains when automated testing, type checking, and linting drive verification costs down.
Finally, consider where experience is stored: does context accumulated across long collaborations land in editable, version-controlled files, or does it scatter across ephemeral chat transcripts? Without a transparent filesystem as a foundation, engineering knowledge turns into an untraceable hidden tax during handoffs and troubleshooting.
Choosing an agent tool ultimately defines the division of labor in your future team. Cursor has laid out its hand. Whether this blueprint succeeds will ultimately come down to two metrics: the acceptance quality of PRs merged into trunk, and the token bill when invoices arrive at the end of the month.