Cursor ships always-on cloud agents for PRs, Slack, and CI

TL;DR: Cursor's latest release turns its cloud agent into an asynchronous worker, not just an in-editor assistant. The key change is a production loop for event-driven work: subscribe to PRs or Slack, wake on updates, run isolated subagents, hold a long-lived goal, and keep going without manual prompting every step.

Product release

Cursor's August 19 changelog is about one thing: reducing the amount of human babysitting required to ship code.

The update adds five core pieces: event subscriptions, custom modes, subagents on separate virtual machines, a /goal command for long-lived objectives, and better steering while an agent is already working. Taken together, that gives Cursor a stronger claim to "always-on" behavior than most coding agents currently in market.

The company's framing is direct: cloud agents should "operate as a system," not as a single chat loop that stalls whenever the user stops typing.

Event subscriptions

The most practical feature is subscriptions.

Cursor can now monitor pull requests, watch Slack threads, or run scheduled tasks. The model is simple: an agent subscribes to an event source, goes idle, then wakes up when something changes. For PRs, Cursor says cloud agents automatically subscribe to pull requests they create and continue driving them forward by fixing CI failures and responding to bot comments.

That matters because PR cleanup is exactly where current coding agents waste developer time. They can generate a decent first pass, but then a human has to keep nudging them through CI errors, review comments, formatting complaints, and dependency edge cases. Cursor is trying to remove that loop.

Slack support pushes this further into team workflows. The example in the changelog — "check back in an hour and keep going until that feedback is in" — shows the intended behavior clearly. This is less "pair programmer" and more "background worker attached to a conversation."

Right now, subscriptions are cloud-only. That is a sensible constraint. Long-running, event-driven jobs are hard to do reliably on a laptop that sleeps, disconnects, or closes the IDE.

Long-lived goals

The most important primitive here is /goal.

Instead of asking the agent to execute a bounded task, users can assign an objective that persists until complete. Cursor's example is "fix all flaky tests and make CI green in a new chat." That shifts the contract from action to outcome.

This is where the product starts to look different from a standard coding copilot. A task-based assistant completes one pass and waits. A goal-based agent keeps state, reevaluates progress, and continues after interruptions or new events.

That approach has been showing up across the coding-agent market recently. The difference in Cursor's release is that the runtime is vendor-managed and tied to production workflows like PRs and Slack. It is not just an SDK pattern or a terminal workflow for power users.

The catch: outcome-based systems are only as good as their stop conditions. "Make CI green" is measurable. "Improve architecture" is not. Builders should expect the best results on narrow, externally verifiable goals.

Isolated subagents

Cursor also now lets subagents run on their own virtual machines, each with an isolated copy of the project and clean context.

This solves a common failure mode in multi-agent coding setups: context collision. If multiple agents share state, they step on each other's changes, inherit stale assumptions, or waste cycles reconciling work. By giving each subagent its own environment, Cursor makes swarm-style testing and parallel bug fixing more plausible.

The changelog's example — testing an app for bugs with a swarm of subagents in separate environments — is credible because isolation is built in. This also gives parent agents a cleaner way to validate changes in fresh environments, which is closer to how real CI behaves.

The trade-off is cost. Separate VMs are operationally heavier than spawning more chat threads. Cursor did not provide pricing or performance details in the source material, so it is worth noting the public information here is thin on the economics.

Agent steering

A smaller but important change: you can now steer an agent while it is working without interrupting the current step.

Instead of cutting off execution mid-action, follow-up instructions wait for the next tool call. That sounds minor, but it fixes a major usability problem in long-running agents. Developers often notice a bad assumption halfway through a run; previously, correcting it could mean derailing progress. With queued steering, the system behaves more like a worker receiving updated instructions than a chat bot being interrupted.

Cursor also added custom modes, which pin a skill in chat as an "always on" behavior. In practice, that is a lightweight way to keep an agent following a playbook across a long session.

Market position

Cursor's claim is that this is the first major coding-agent IDE to ship the full always-on loop in production: subscribe, wake, swarm, hold goal, and steer.

That is directionally credible based on the source text, though it is still vendor framing. The broader trend is clear: coding agents are moving away from synchronous "prompt-response" use and toward persistent runtimes that own a result over time. Cursor's release is notable because it bundles that trend into one product surface inside an IDE developers already use.

Still, some caution is warranted. The source is a changelog, not an independent benchmark. There are no hard metrics here on completion rates, CI recovery success, cost per resolved PR, or how often human intervention is still required. The feature set is substantial; the proof will come from whether teams trust it on real repos with real review and deployment pressure.

For builders, the change is operational: stop treating coding agents as tools you invoke and start treating them as workers you assign. The best use cases are measurable, event-driven loops — keep this PR green, clear these bot comments, rerun until flaky tests stop failing, check Slack for approval and continue. If your workflow depends on repeated human nudges today, Cursor is betting that layer can now run in the background.