Cursor introduced Projects on 10 September 2026, bringing an ongoing workspace to software development with AI. In its launch announcement, the company describes a coordinator that delegates implementation to subagents, maintains shared context and responds to recurring triggers. The beta is rolling out to all users. Projects run in the cloud, with local agents available when work needs a developer's machine.
The significance is the change in the unit of work. A development team can organise around an outcome that takes many revisions, rather than treating every prompt as a fresh assignment. That is an appealing direction, but it also moves more responsibility into scoping, verification and deciding when a change is ready.
Persistent work needs a dependable environment
Cursor's separate Cloud Agents documentation explains the underlying development model: isolated virtual machines with repositories, dependencies and the tools required to run software. Agents work on branches and hand changes back through source control. They can produce screenshots, videos and logs that show how a result was tested. The documentation also describes network restrictions, environment configuration and model-based usage charges.
Those details matter because writing a plausible patch and proving it works are different activities. An agent that cannot start a service may miss an integration failure. One that can run a unit test but cannot access a representative dataset may leave a different gap. A persistent workspace should make those limitations visible, not allow them to disappear into a long conversation.
For a first evaluation, a team could choose a modest internal change with a known test suite and a named owner. The acceptance criteria should describe observable behaviour: which screen should change, which migration must succeed, or which tests must remain green. That gives the coordinator a measurable destination and gives the reviewer something firmer than a reassuring completion message.
Context is useful only when it stays accurate
In its existing operating guidance, Cursor recommends configuring environments before running agents, documenting testing procedures and making required tools reachable. It describes repository, team and user rules as different places to establish conventions. These are supporting practices, not separate features newly announced on 10 September.
Our assessment is that the main maintenance challenge will be deciding which accumulated knowledge remains authoritative. A service name can change. A temporary workaround can become obsolete. A test command that succeeded last month can stop covering the relevant behaviour. Saving instructions is valuable, but retaining a wrong instruction indefinitely can multiply the same mistake across subsequent work.
Teams should therefore treat reusable context as an engineering asset. Give important instructions an owner, keep them close to the code they describe and review them when the underlying system changes. When two sources disagree, make the resolution explicit. A concise, current explanation of how to test a service is worth more than a large archive of unexamined notes.
The review queue becomes the next constraint
Cursor already documents PR Routing & Approval, a separate capability that assigns reviewers and can approve lower-risk changes under configured criteria. Its documentation says the system considers risk, policy files and findings from other review agents. It also states that this does not replace a full code review. Teams should not assume that launching Projects automatically establishes an appropriate approval policy.
Producing more proposed changes is useful only when reviewers can understand and safely accept them. An engineering team could ask for small, clearly named pull requests, a description of the evidence behind each change and a list of remaining uncertainties. Changes to access controls, billing calculations or destructive migrations warrant different scrutiny from a straightforward documentation correction.
Review capacity should also shape concurrency. If a team can confidently assess three changes a day, generating thirty may simply move the backlog from implementation to inspection. Track how long reviews take, how often work is sent back and whether automated tests catch the same issues humans find. Those measurements reveal more about practical value than counting agent sessions.
Measure outcomes before expanding the remit
A useful pilot would compare similar work before and after adoption: elapsed time to an accepted change, reviewer effort, escaped defects and total compute expenditure. Keep the scope stable enough that the comparison means something. A large increase in activity can otherwise look like progress while the amount of usable software stays much the same.
The beta also deserves explicit stopping conditions. A project should pause when requirements conflict, when testing cannot be completed, or when its spending allowance is exhausted. Those are proposed operating controls for adopters, not claims about defaults in the release. Set them out before assigning a broad migration or an unattended maintenance job.
Projects makes an important proposition: software agents should remember the work and continue it across sessions. Whether that becomes a reliable productivity gain will depend on the surrounding engineering discipline. The strongest early adoption will pair persistent execution with equally persistent ownership of tests, context, permissions and the final decision to merge.