A pull request used to carry, implicitly, the name of the person who wanted it. Cursor's Projects beta — shipped on 10 September — removes that field: the coordinator agent can watch a Slack channel, run on a schedule, or follow all your PRs and open work without waiting for anyone to ask. The fan-out to thousands of subagents is the headline. The unscoped standing grant underneath it is the part that will be discovered later, by someone in an incident review.
At a glance
Three things changed at once, and only two of them are about scale.
| Axis | Background agents (2025–26) | Projects (10 Sep 2026) | Why it matters |
|---|---|---|---|
| Who starts the work | A human, per task | A trigger: Slack, a schedule, or a PR event | The request disappears from the record |
| Unit of work | One task, one branch | A persistent thread with a coordinator that delegates | Arrival rate is no longer set by you |
| Lifetime | Minutes to hours | Months of retained context, in the cloud | The context is an input nobody reviews |
What actually shipped
Cursor released Projects in beta on 10 September 2026. A Project is a single persistent thread in which you work with a coordinator agent. The coordinator does not write code. It plans the work, delegates implementation to agents it creates and manages on your behalf — running as many in parallel as the work needs — and brings finished work back for you to check. The Project runs on its own computer in the cloud, so closing the laptop does not stop it, and it keeps context across months of work rather than across a session.
Then the line that is easy to skim past: you can tell the coordinator to watch a Slack channel, to run on a schedule, or to follow all your PRs, so that it takes action on signals it detects without waiting for your prompt.
Cursor's own numbers give the shape. On one internal design-system Project, the company says the work is on track to touch 20 to 100 pull requests a day, with the coordinator organising it and the engineer checking in where attention is needed; Cursor reports a 6× multiplier on PRs merged.
Worth separating two claims. "An agent can open a PR unattended" has been true since background agents, and it is a productivity question. "An agent decides which work to open a PR about, from a signal you did not read" is a different claim, and it is an authority question.
A trigger list is a grant, and it is missing four fields
When a human asks an agent to do something, four facts come along free: who asked, what they asked for, when, and for what purpose. Every control the field has built quietly depends on at least one of them. Approval-by-consequence needs to know whose authority is being exercised. Audit trails need a principal. Delegated-access records exist precisely because a token does not tell you who consented to what. The whole argument in an account toggle is not a power of attorney is that enabling a capability is not the same act as authorizing a use of it.
"Watch #eng-alerts and act on what you find" is an authorization. It has an implied scope (whatever appears in that channel, indefinitely), an implied grantee (a coordinator whose plan you have not read), and an implied duration (until someone remembers to turn it off). It is stored in a product settings pane, and it is reviewed by nobody, because it does not look like a grant — it looks like a feature.
This is not a Cursor complaint. The same shape arrives with every scheduled-and-triggered agent, and the wiki's operations page on the pattern has been making the mechanical version of this point for a while. What is new is the combination: a trigger that can originate work, a planner that decides what the work is, and a fan-out that makes the output faster to produce than to read.
The arithmetic nobody puts on the slide
Generation parallelises; review does not. Twenty minutes of genuine review — read the diff, run it in your head, check the test actually fails without the fix — is not a pessimistic number, and at 100 PRs a day it is four people doing nothing else. Cursor's design-system example is a favourable case: mechanical, repetitive, verifiable changes, which is exactly the class where a coordinator should be pointed first.
The failure is not that teams will hire four reviewers. It is that they will not, and review will silently become sampling — which is a defensible policy if you choose it, and a very bad accident if you do not. The background-agent playbook already puts it plainly: the review queue is the throughput limit, so cap the input. A trigger list is precisely a mechanism for uncapping the input.
And note where the coordinator sits relative to that queue. Because it plans rather than implements, the highest-leverage artefact in the system is the plan — one document, reviewable in minutes, that determines twenty diffs. Reviewing the plan before the fan-out is cheaper than reviewing the fan-out, by roughly the ratio of the fan-out itself. Almost nothing in the tooling encourages this, because the plan is a chat message and the diffs are what GitHub notifies you about.
What the months of context actually are
A Project keeps context across months. Read that as an asset and it is the headline feature; read it as an input and it is an unversioned document that shapes every delegated task and that no one will ever diff.
Two consequences follow. The first is ordinary drift: a decision made in week two, half-remembered by week nine, becomes the justification for work in week ten, and the failure mode is the one goal drift describes — competent execution of an objective that quietly substituted itself. The second is sharper. If the coordinator ingests a Slack channel, then text written by anyone who can post in that channel is now an input to a planner with repository write access. That is the standing prompt injection surface, and it is the same argument as the block log is an injection channel: a feed you added for observability became a control channel because something started reading it.
The mitigations here are not exotic. Triggers that can originate work should read from sources with a known author set. The plan a trigger produces should be an artefact, not a chat turn. And the subagents' write access should be the coordinator's scope, not the human's — which today it generally is not.
What to do before you turn triggers on
Projects is a good product, and the coordinator-plans/subagents-implement split is the right shape — it is the supervisor-worker pattern, finally with an interface. The work is in treating the trigger configuration as what it is.
- Write the grant down. Who enabled this trigger, what it may originate work about, until when, and who reviews it. Four lines in your agent inventory, and the only ones that will exist if anyone asks.
- Give every standing trigger an expiry. Ninety days, then it must be re-enabled by a named person. Grants that never expire are how every access-review finding starts.
- Review the plan, not just the diffs. Require the coordinator to post a plan and wait for an acknowledgement before a fan-out above some size. This is the single highest-return control available and it costs one round trip.
- Cap in-flight delegated work at your actual review capacity. Not at the coordinator's capacity. If that number is embarrassing, it was embarrassing before the coordinator existed; you just could not see it.
- Stamp provenance on the PR. Which trigger fired, which signal, which plan, which coordinator context version. If your answer to "why was this opened" is a link to a Slack message, that is already better than most teams will have.
The interesting shift of the last month is that two vendors independently moved the same boundary. OpenAI's Agents API put the harness itself behind an API call; Cursor put the requester behind a trigger. Both are conveniences, and both quietly relocate something you used to own.
FAQ
Is this different from a scheduled CI job that opens PRs?
Yes, in one respect that matters: a CI job runs a fixed program, so its scope is whatever you wrote. A coordinator decides what the work is from a signal, so its scope is whatever the signal turns out to contain. The same trigger mechanism, a different amount of discretion downstream of it.
Does a 6× multiplier on merged PRs mean 6× the output?
It means 6× the merges. Whether that is output depends on what the review step was doing before and whether it is still doing it — which is why the material-error rate on merged changes, not the merge count, is the number worth tracking through a rollout.
What should a coordinator be pointed at first?
Work that is mechanical, repetitive, and verifiable by tests — design-system migrations, dependency upgrades, codemods. The property you want is that a reviewer can check a diff in seconds because correctness is machine-decidable, which keeps the review queue from becoming the bottleneck immediately.
Is the Slack trigger really a prompt-injection surface?
If the coordinator reads the channel and can act on what it reads, then yes, by definition — anyone who can post is writing to a planner with repository access. The mitigation is not cleverer filtering; it is restricting origination triggers to sources with a controlled author set, and keeping the plan as a reviewable artefact.
Further reading
On this wiki:
- Background coding agents — the review queue as throughput limit, and how to cap the input.
- Scheduled & triggered agents — the operational mechanics of work that starts itself.
- Delegated access & consent records — why a token is not a record of who authorized what.
- Supervisor-worker pattern — the shape Projects implements, and its ceiling.
- Ambient authority — the failure mode a standing grant produces.