Cursor cloud agents can wait for CI, Slack, and cron now

The hardest part of agentic shipping is not the first commit. It is everything that happens after.

CI fails at 2 a.m. A reviewer asks for a rename. Someone replies in Slack with "ship it but fix the migration first." Until now, each of those moments meant you reopening Cursor and re-prompting from scratch.

Cursor's August 19, 2026 changelog closes that gap. Cloud agents can subscribe to events, hold a goal across turns, and spawn subagents on their own machines. That is the shape of software that ships without a human babysitting every loop.

Event subscriptions turn agents into listeners

Most agent products are great at fire-and-forget tasks. Open a chat, get a diff, close the tab. Production work is asynchronous. The PR sits open. The thread waits. The cron fires on Monday.

Cursor's answer is subscriptions: the agent attaches to an event source, ends its turn, and wakes when something relevant happens. Events land as follow-ups in the same conversation, so the agent does not lose the thread.

Per the cloud agent capabilities docs, supported sources today include:

Bursts coalesce. If five CI events land in a minute, the agent may wake once and re-read the PR before acting. Subscriptions last up to 180 days, or the agent unsubscribes when the wait is over.

In practice I describe the wait in the prompt: "open a PR and keep it green until merge" or "ask in #releases and wait for approval." The built-in /subscribe skill does the same routing.

This is different from the token optimizations I covered in Cursor MCP and skills optimization. That post was about cost per turn. Subscriptions are about cost per shipped outcome. You pay for idle time differently, but you stop paying humans to re-type context.

Auto PR management is the default loop

Cloud agents that open a PR now automatically subscribe to that PR. They chase CI failures, respond to bot comments, and push toward completion without you pasting "CI is red again" every hour.

GitHub Actions is the supported CI path for automatic fixes. The docs list sensible guardrails: no autofix after you push a human commit, no autofix if you already sent a follow-up, caps after repeated failures. You can comment @cursor autofix off on a single PR or disable the feature in the Cloud Agents dashboard.

That pairs naturally with the governance story in Cursor Auto-review mode. Auto-review decides whether a shell command runs locally. Subscriptions decide whether the cloud agent comes back when the remote world changes. One is permission at execution time. The other is persistence across wall-clock time.

For teams already running cloud agents on every feature branch, this is the missing closure. The agent does not "finish" when it opens the PR. It finishes when the PR is mergeable.

Subagents on isolated VMs

Subagents used to share the parent's workspace. That works for quick lookups. It breaks when two agents edit the same files or when one agent's half-finished experiment poisons another's test run.

August's update gives each subagent its own VM with a clean project copy and fresh context. The parent can delegate "run the integration suite in a fresh env" while it keeps refactoring. You can swarm independent bug hunts without merge conflicts in /tmp.

I have been testing prompts like "run a swarm of subagents to test my app for bugs, each in its own environment." The isolation is the product feature. The swarm is just orchestration on top.

If you maintain custom MCP servers, remember HTTP MCPs keep credentials off the VM. Stdio MCPs run inside the agent environment. Subagent VMs multiply that surface area. I still prefer HTTP transports for anything that touches secrets.

/goal and Custom Modes for long arcs

/goal is the command I have wanted since the first cloud agent demo. You set an objective that persists until done, not until the model runs out of steps.

Example from the changelog: /goal fix all flaky tests and make CI green. The agent keeps steering toward that outcome across subscriptions, CI wakes, and follow-ups. Pair it with /loop when you want recurring check-ins on a schedule instead of a single finish line.

Custom Modes pin a skill to the chat so the agent stays on a playbook. From /, pick a skill and press Alt+Enter (or choose Use as Mode). Think of it as an always-on skill: security review mode, deploy mode, docs mode. /goal plus a Custom Mode is how I run "fix flaky tests using our test harness skill" without the agent drifting into unrelated refactors.

Steering without killing the run

The same release improves mid-run steering. You can queue a follow-up while the agent works. The message waits for the next tool boundary instead of aborting mid-command. Double-press Enter or hit Send now depending on urgency.

That matters when subscriptions fire fast. CI fails, you want to say "skip the flaky integration test file for now," and you do not want to corrupt a git push halfway through.

What I would configure first

If you are adopting this on a real repo, this is my order:

1. Enable PR subscriptions on a low-risk service first. Watch autofix limits and the 10-CI-follow-up cap before you trust it on a monolith.
2. Write one Custom Mode from an existing skill your team already trusts. Modes fail when the underlying skill is vague.
3. Use /goal for bounded outcomes ("make CI green on this branch") not vague goals ("improve the codebase").
4. Test subagent isolation on parallel test swarms before you parallelize writes. Reads are safe. Concurrent edits still need human merge discipline.
5. Keep HTTP MCPs for OAuth and secrets, especially with multiple VMs in play.

Risks I still watch

Event-driven agents are powerful and easy to over-automate.

• A subscription on a noisy Slack channel can wake agents on every message unless you scope the wait.
• Autofix loops can spam commits if CI is flaky for environmental reasons, not code reasons.
• More VMs means more egress and more places a stdio MCP might leak env vars.

Subscriptions do not replace code review. They reduce the coordination tax between review rounds.

Bottom line

Cursor's August 19 update moves cloud agents from "help me write code" to "stay on the ticket until it ships." Subscriptions handle the async world. Isolated subagent VMs handle parallel work without collisions. /goal and Custom Modes keep long tasks from dissolving into chat drift.

If your team already pays for cloud agents but still assigns a human to watch every PR, this is the release that changes the workflow math.

If you want help wiring event-driven agent loops into your repo (subscriptions, skills as modes, CI guardrails), book a free discovery call.