Dora NodaClose your laptop, and the work keeps going. That's the pitch behind two of 2026's biggest AI-IDE releases: Cursor's Cloud Agents, which spin up an isolated VM per task and hand you back a pull request, and Windsurf 2.0's one-click handoff to Cognition's Devin, which does the same thing from inside an "Agent Command Center." Both vendors are now provisioning the compute an agent's work runs on, not just the model that writes the diff.
That's a real shift, and it's worth being precise about what it actually buys you: an agent that opens a pull request in a sandbox is not the same event as an agent that ships a running service. The two launches make that boundary concrete rather than theoretical — and the gap between them is exactly the seam a deploy-authority API, not a chat window, is built to close.
What Cursor's Cloud Agents Actually Deliver
Cursor's Background Agents — rebranded Cloud Agents after the February 2026 "computer use" update — clone your repository into an isolated Ubuntu VM, create a branch, and get to work: reading files, running tests, installing packages, fixing lint errors, even browsing the web for context. Each task gets its own VM with no shared state between agents, and since the February update each one also gets a full desktop and browser it can drive directly, plus video recording of the session for review. Close the laptop, check back in an hour, and the agent is either still working or waiting with a finished PR.
That's a genuinely capable sandbox. It is not a deploy pipeline, and Cursor's own integration documentation says so directly. Wiring a Cloud Agent to a platform like DeployHQ is what makes "every PR Cursor merges into your deployment branch ships automatically" — the phrasing itself concedes that shipping isn't native to the agent; it's a separate product you bolt on afterward. The agent's authority ends at the PR. Whatever turns a merged PR into a running service is a different system, configured separately, with its own credentials and its own failure modes.
What Windsurf 2.0 and Devin Actually Deliver
Cognition's Windsurf 2.0 landed April 15, 2026, and drew the same line from the other direction. Its Agent Command Center is a Kanban board of every agent session in flight — local Cascade sessions running in your editor next to cloud Devin sessions running on their own VMs, each with a full desktop and computer-use access. Plan the work locally with Cascade, then hand it off with one click; Devin picks up debugging, testing, and other long-running work on its own machine, and the result comes back as a PR through the same review flow. By June, Cognition had folded the whole product line under the Devin name — Windsurf effectively became "Devin Desktop," with Devin as the cloud execution layer underneath.
Devin's own documentation draws the deploy boundary just as explicitly as Cursor's does. It operates in a sandbox — a "Devbox" — connected back to a stateless cloud "Brain," and the standing guidance is not to give it production database credentials: run it against staging, provide production access explicitly and sparingly if at all. That's not a hypothetical caution; it's the documented default posture of the most autonomous coding agent shipping today. The vendor that markets Devin as capable of writing, testing, and fixing an entire feature end to end is the same vendor telling you, in its own docs, to keep it away from production by default.
The Receipt
Neither vendor is hiding this — a third party building the layer these tools are missing said it plainly. Qovery's May 2026 write-up on Cursor's Cloud Agents put it in one sentence: "After merge, deployment, staging, production, and rollback are entirely your responsibility." No deployment pipeline, no managed databases, no multi-service environment provisioning — the agent's job stops at a reviewable diff.
Generalize that past one vendor's blog post and it's a clean checklist of what "the agent runs in the cloud now" doesn't include:
- A deploy pipeline that takes a merged commit to a running revision, with no separate platform bolted on to do it.
- Rollback as an operation, not a manual
kubectl rollout undoor a click through a dashboard someone has to remember exists. - An audit trail that distinguishes who acted — an agent's identity and scope are not a human's, and "the deploy happened" is a very different incident-review starting point from "the deploy happened, triggered by which actor, with which permissions, and here's the rollback path."
Every one of those is a control-plane property, not a coding capability. No amount of a better model inside the sandbox produces them, because they don't live in the sandbox.
This Isn't a Cursor-or-Devin Quirk
It's tempting to read the deploy boundary as a gap specific to these two products — as if a future release just adds a "deploy" button next to "open PR" and the problem goes away. The broader 2026 data says otherwise. Industry surveys of enterprise agent rollouts put the pilot-to-production failure rate at 88%, and for coding agents specifically, the blocker by April 2026 wasn't model quality — Claude Code, Codex, Jules, Cursor, Kiro, and Windsurf were all already producing strong code by then. The obstacles named most often were operational: missing SSO, audit logs not wired to a SIEM, no enforced PR gates, no sandbox isolation for what the agent touches, and — when something does go wrong — no documented process for who gets paged, how the agent's access gets revoked, and how the change gets rolled back.
That list is the same checklist from the Qovery quote above, just measured across an entire industry instead of one vendor's blog post. A better sandbox VM doesn't move any of those numbers, because none of them are sandbox problems. They're control-plane problems, and they show up the same way whether the agent in question is Devin, Cursor's Cloud Agents, or the next entrant that ships an isolated-VM-plus-PR workflow next quarter.
Why the IDE Vendors Won't Close This Themselves
This isn't a roadmap gap the next release quietly fixes — it's the reason the sandbox model works at all. A disposable VM with no production credentials is precisely what makes it safe to let an agent run autonomously for hours: if it goes sideways, you delete the VM and nothing outside it was ever at risk. That containment is the whole safety argument. Wiring the same agent standing deploy authority into your production infrastructure is a different, harder trust model — scoped permissions, an identity distinct from the humans on the team, an audit trail a compliance review can actually read — and it sits outside what a code-authoring product is built to sell.
CNCF's July 2026 piece on platform engineering for the agentic enterprise names the requirement directly: a platform serving both humans and AI agents as first-class consumers has to give each "distinct identity, scoped permissions, and clear audit trails," with an AI-native control plane exposing MCP gateways as part of that surface — not a chatbot layered on top of a human-first dashboard afterward. That's a control-plane job. It was never Cursor's or Cognition's job to begin with, and there's no product reason for either to start now.
What Actually Closes the Gap
The interface that fills this seam is worth naming specifically, because it isn't just "an API" in the abstract. Cursor's own agent harness already reaches for tools through MCP servers — codebase indexing, skills, and hooks are all wired in that way today. An agent calling deploy and rollback the same way it already calls every other tool is a smaller step than building a bespoke deploy integration per platform, and it's the interface CNCF's framing points at directly: scoped permissions and a distinct identity per caller, discoverable by an agent without a human pre-configuring it by hand.
Concretely, the missing middle looks like this: a merged PR triggers a call — human-initiated or agent-initiated, through the same interface either way — to a deploy endpoint on a platform that owns the git-push-to-running-service path end to end. A new revision goes live. Rollback is a named, callable operation, not a support ticket. The audit log records which identity called it: a human through a dashboard, or an agent through the same MCP surface, with its own scope and its own trail. Nothing about "the agent opened a PR from a sandboxed VM" needs to change for this to work — what changes is what happens on the other side of the merge, and that's infrastructure, not editor tooling.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with an MCP surface built for exactly this seam: an agent's merged PR becoming a deployed, rollback-able revision through the same API a human would use. Star the repo on GitHub or deploy your first app today.
What This Actually Signals
Two of the most-watched AI-IDE releases of the year both landed on the same architecture — agent writes and tests in a disposable cloud sandbox, hands a human a PR to review — and both vendors' own documentation confirms where that architecture stops. That's not a shortcoming to wait out; it's a sign the industry has settled, correctly, on keeping code-authoring and deploy-authority as separate trust boundaries. As more IDE vendors provision cloud compute for agents, "who owns the deploy step" is going to keep showing up as the same open question, and the platforms positioned to answer it will be the ones that already expose deploy and rollback as something an agent can call — not something a human still has to do by hand once the PR lands.
