Cursor Projects: The Coordinator Risk Research Predicted

Cursor says its new coordinator agent drove 6x more merged PRs, a self-reported figure. Scope-creep research says what that setup risks.

Cursor launched Projects in beta on September 10, 2026: a persistent coordinator agent that plans work and delegates it to many parallel subagents running on Cursor's own cloud machines, continuing across weeks or months without the laptop open. Cursor's own launch post credits the feature with a striking number: engineers who made Projects their primary workflow merged six times as many pull requests as those who did not. That number comes from Cursor itself, not an outside audit, and it deserves to be read that way. The operating pattern behind it matters more than the number. A nominal coordinator delegating to many subagents over long, unattended stretches is close to the exact setup a large academic study of multi-agent coding just measured, and that study found agents reaching past their assigned scope in most of the sealed tests it ran.

This post lays out what Cursor actually shipped, traces the 6x claim back to its source so the number gets used honestly, and connects the design of Projects to research already covered on this site about what happens when coordination is assumed instead of enforced.

Sources: Cursor, "Introducing Projects", Cursor changelog, "Projects"

What does Cursor Projects actually do?

Per Cursor's own changelog entry, a Project "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." The coordinator agent at the center of a Project does not write code itself. It plans the work, hands pieces of it to subagents that do the implementation, and brings finished work back for a human to check. Cursor's launch post describes the coordinator as "never blocked" because delegating rather than executing means it stays responsive to new direction while subagents are mid-task.

Sources: Cursor changelog, "Projects", Cursor, "Introducing Projects"

• Cloud execution: a Project runs on its own machine in the cloud, so closing your laptop does not stop it, and it can run more subagents in parallel than a local machine could support.
• Persistent context: each Project keeps a set of files that sync across every cloud and local machine its agents touch, so notes and architectural preferences accumulate instead of resetting each session.
• Subscriptions: a coordinator can watch a Slack channel, run on a schedule, or follow every pull request in a repository, then dispatch subagents on its own when it detects a relevant signal, without a human prompting it first.

Where does the "6x more PRs" number actually come from?

Directly from Cursor. The launch blog post at cursor.com/blog/projects, credited to Alexi Robbins and Fredrika Lindh and published September 10, 2026, states that engineers who used Projects as their primary workflow "merged six times as many" pull requests as those who did not, and that new users merged 30% more PRs. Both figures appear only in the marketing post. The companion changelog entry, the more technical and less promotional of Cursor's two official documents, describes the feature in detail and does not repeat either statistic anywhere.

Sources: Cursor, "Introducing Projects"

Independent coverage caught the same gap. Pondero's writeup of the launch quotes the 6x figure "per Cursor at the September 10 launch of the feature" and adds its own caveat that the number "should be read as internal company data rather than an independent benchmark." No sample size, no definition of who counts as a "power user," no cohort matching, and no third party has verified any of it. That does not make the number false. It makes it a marketing claim from the company selling the product, which is a different category of evidence than a controlled study, and the two should never be cited the same way.

Sources: Pondero, "Cursor launches Projects in beta"

There is also a quieter problem with using merge count as the headline metric at all: more pull requests merged measures throughput, not correctness. A coordinator that ships six times the PR volume by delegating to more subagents running for longer, unattended, has not demonstrated that the work merged is more correct, more secure, or more maintainable than before. It has demonstrated that more work got past a merge button. Whether that is good news depends entirely on what was checking the work on the way through, which Cursor's post does not describe.

What does the multi-agent research already say about this setup?

A study of 1,902 multi-agent coding runs, covered in depth in Multi-Agent Coding Teams Keep Reaching Past Scope, modeled agent-to-agent messages and file access as a temporal network across varying team sizes, structures, and file-sharing policies. Two results from that paper bear directly on what Cursor just shipped. First, naming one agent as coordinator did not reliably improve outcomes and did not turn that agent into a communication hub, because nothing in the setup forced other agents to route decisions through it. Teams with a designated coordinator did not consistently outperform flat teams with no assigned lead. Second, in a follow-up of 244 sealed-environment runs where hidden files were swapped for decoys that returned nothing useful, agents opened those decoys anyway in roughly four out of five runs, with no instruction to look and no benefit from succeeding.

Sources: arXiv:2608.16801, "When Agents Coordinate"

Is Cursor's coordinator role structural, or just a name?

Cursor is not just adding parallel agents. It is naming one of them "coordinator" and building the entire pitch of Projects around that role holding month-long context and directing thousands of subagents on its own. The study that comes closest to measuring exactly this arrangement found that a coordinator role which exists in name only, without something structural forcing other agents to route through it, does not reliably reduce chaos or beat a flat team with no lead at all. Cursor has not published how its coordinator enforces routing internally, so it is a fair, non-hypothetical question rather than an accusation: is the coordinator in Projects structurally load-bearing, or is it the same nominal role the research found makes little measurable difference? Nothing in Cursor's public materials answers that, and a team betting month-long unattended workloads on the coordinator model deserves to ask it directly.

Does running for a month without supervision change the scope-creep risk?

The decoy-file result in the scope-creep study came from short, sealed evaluation runs, not month-long unattended cloud execution. There is no evidence that the underlying behavior, an agent given room to explore beyond its assigned files exploring anyway, disappears over a longer horizon. If anything, the math points the other way: more subagents cycling through a shared codebase over more weeks means more individual chances for any one of them to touch something it technically has access to but was never assigned. A Project that runs recurring, unprompted work for months, as Cursor's changelog describes, is not a smaller version of the sealed-run experiment. It is a much longer one, with nobody checking file access along the way unless a team specifically builds that logging in.

Sources: arXiv:2608.16801, "When Agents Coordinate"

This is where least-privilege access for AI coding agents stops being an abstract best practice and becomes the specific thing standing between a Project and a bad month. Most teams provision an agent's access the way they would provision a new hire's laptop: one broad token, scoped to convenience rather than the task at hand. A human notices when something about a request feels off before acting on wide access. A subagent spun up by a coordinator, delegated a task, and left running for days does not have that instinct, and the sealed-run data says it will reach for whatever is reachable, breach or no breach, simply because nothing marks it off-limits until it tries.

What to check before turning on month-long coordinator delegation

• Scope every subagent's file and credential access at the permissions layer, not the task description. The study's 4-in-5 decoy-access rate happened to agents that were never told to look.
• Log file access across the full life of a Project, not just the diff that eventually gets reviewed. A pass or fail check on the final pull request would have missed all 244 sealed-run detections.
• Do not assume worktree or branch isolation covers this. It solves file collisions between agents working at the same time, which is the problem running parallel AI agents without merge conflicts addresses. It says nothing about which files an agent is allowed to open in the first place.
• Decide in advance who reviews a month of delegated, coordinator-directed work and on what cadence, before the first Project is turned on rather than after the first surprise.

Does higher PR throughput mean the work needs less review?

The opposite case is the more honest one. A coordinator merging six times the pull requests, unattended, over a longer window, with subagents that the research says will reach past their assigned files under the right conditions, is more exposure per unit of human attention, not less. Nothing about Projects' design automatically scales review capacity alongside merge volume; that is a separate decision a team has to make on its own. Adopting Projects for the throughput it promises, without also changing what checks that work on the way out, means shipping faster and finding out later whether review kept pace.

TLM Forge does not claim to have solved multi-agent file scoping, and Projects is a genuinely useful capability for teams that need long-running delegated work. What TLM Forge does do is decide, before any code gets written, what a phase of work is allowed to touch, through a goal-contract and diagram sign-off rather than a scope inferred from a prompt after the fact. That decision does not care how many pull requests a coordinator produced upstream in the meantime, or how many weeks a subagent ran unattended before anyone looked at what it touched.