Cursor's Cloud Agents can now subscribe to pull requests, Slack threads and scheduled tasks and act when those events fire, with no new prompt from a person. A /goal command keeps an agent pointed at an open-ended objective across sessions rather than one bounded task.
That is a genuine capability upgrade, and it is also a quiet change to an assumption most review processes were built on: that every change started because a person decided to start it.
The assumption that just broke
A prompted agent is bounded by your attention. You ask, it works, it stops. Nothing happens that you did not personally initiate, so "who started this" has always had a one-word answer: whoever typed the prompt.
A subscribed agent is bounded by its subscriptions instead — a much larger, less visible set of triggers. A bot comment on a pull request, a message in a Slack thread, a scheduled time: any of these can now be the thing that starts a change, and none of them is a person sitting down to make a decision.
Most review processes, written or unwritten, assume the first model. "Who approved this change" and "who started this change" used to be nearly the same question. They are not anymore.
Three scenarios worth thinking through before you enable it
Not hypotheticals — the direct, intended use of the feature, examined for what happens at the edges.
- An agent subscribed to its own pull request pushes a fix at 3am in response to a CI failure. Is that commit reviewed the same way a human's would be, or does "the agent already handled it" quietly lower the bar?
- A bot comment on an open PR triggers an agent to push a change. If that comment came from a compromised or misconfigured integration rather than a person, what stops the agent from acting on it exactly as it would on a legitimate one?
- A /goal-driven agent keeps working "fix all flaky tests" for a week, across many small commits. At what point does an evolving goal need a fresh look from a human, rather than accumulating changes under an authorization nobody has revisited?
What to decide before you turn it on
Four questions, and the honest answer to each is more useful than a fast yes.
- Which events are allowed to trigger unattended action, and which require a person to look first? Not every subscription needs the same trust level
- Does a commit that arrived from a subscription get the same review as one from a person, or a lighter one? If lighter, say why out loud — "the agent is trustworthy" is a claim, not a policy
- Who is notified when a subscribed agent acts, and how quickly? A change nobody sees until the weekly standup is a change that ran unsupervised for days
- What is the kill switch? Not "can we disable subscriptions" in the abstract — can a specific person do it in under a minute when something is going wrong right now
The audit trail is the actual safety mechanism
Confirmation-before-every-step does not scale to an agent meant to run for a week on an open goal — that is the entire point of the feature. What scales instead is a clear record: which event fired, what the agent did in response, and whether a human has looked at it since.
Before enabling subscriptions for real work, confirm you can answer those three questions for any commit a subscribed agent produces, without asking the agent. If the honest answer is "we would have to reconstruct it from the pull request history," that is worth fixing first.
A reasonable starting posture
Start narrow and let evidence widen it, rather than the reverse.
- Enable subscriptions on pull requests the agent itself opened, where it already has full context, before extending it to PRs opened by others
- Route bot-triggered actions through a lighter but real check — a status label, a required reaction — before trusting them at the same level as a scheduled task
- Give /goal a stated end condition and a review checkpoint, not just a target state, so an open-ended objective does not become an indefinite one
- Revisit the policy after a month based on what actually happened, not on what you assumed going in