Cursor Cloud Agents Guide

Cursor's June 2026 Cloud AgentsAgents that run in a Cursor-managed virtual machine, check out the repo, do the work and open a pull request, then shut down, with no load on your laptop. Press Enter for the full definition. update added guided setup for cloud environments, reusable snapshots and .cursor/environment.json. It also added /in-cloud subagents, /babysit (now /autopilot) for supervising pull requests and a more reliable handoff between local and cloud.

Cursor's release notes and announcements say what changed. They don't say how a team should act on it. The steps below are our suggested order, and the next section lists what to watch out for along the way.

1. 1Use local Agent or Plan Mode for ambiguous work that needs close supervision.
2. 2Set up a cloud environment with install, start and verification commands before you delegate long work.
3. 3Launch /in-cloud only for tasks with separate branch boundaries and low conflict risk.
4. 4Pull the result back locally and rerun the checks a human reviewer would trust.

Each item below is either a fact about the release, such as its beta status or plan access, or our advice for using it safely. Plan around each one, and recheck the facts when Cursor ships an update.

• Don't send work to the cloud until its environment can install, start and test the repo.
• Give parallel agents separate branches, and review one output at a time.
• Keep sensitive or high-blast-radius work local until the data flow and secret boundary are approved.
• Cloud agents need a plan that includes them: Premium and higher, Teams, Enterprise or a legacy paid plan. Free and Plus don't include them.

A cloud agent's VM has its own desktop and terminal, and one run can check out several repos in a multi-repo environment. It uses none of your laptop's RAM or disk, and Cursor's docs say you can run as many as you want in parallel, even with your computer offline.

Artifacts: proof of work

The agent can drive its own virtual desktop, so it can check its work the way a person would. It makes a change, opens a browser, tests the change, records video and screenshots, and fixes console errors it finds. When it finishes, it returns the walk-through video with screenshots, type-check and test results, and it can upload the video to the PR.

Grind mode

In one Cursor webinar, a presenter showed Grind until done, a toggle that lets a cloud agent work on its own for hours on the longest jobs, such as big migrations or building something from scratch. Cursor's current cloud agent docs don't describe it, so check before you plan around it. Most tasks don't need it, because turning on cloud and asking for the feature already works well.

Cursor's Cloud Run worker-pool guide was a reference setup for Self-Hosted Cloud AgentsAgents that run in a Cursor-managed virtual machine, check out the repo, do the work and open a pull request, then shut down, with no load on your laptop. Press Enter for the full definition. on Google Cloud. It described a deployment pattern, not a second product: worker containers and build artifacts run in your own cloud and connect back to Cursor's fleet management API.

As of October 28, 2026, Cursor's docs index no longer lists that guide, and its address opens the general Team Pools page. The table shows what the guide described, with the prerequisites brought up to date from the Team Pools page.

Picture a cloud agent as an engineer with a laptop in the cloud. Slack, Linear and the IDE are different ways to direct that engineer. You hand off a task to run in the background and work on something else. For people outside engineering, this is one of the most useful things to set up early.

You can start a run from any device at cursor.com/agents. One presenter started a run from a phone on the Bay Bridge. Pick a repository and branch, write the instruction, choose a model, link any MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition. servers the task needs (Slack, for example), and start it. The run boots a new VM that mirrors your GitHub repo, the rules and system prompts in the repo, your MCP servers and your skills. Repo-specific slash commandsSaved multi-step prompts you trigger from the / menu, such as run tests, fix CI or open a pull request. Press Enter for the full definition. work inside the cloud run too.

• Each parallel run works on its own branch.
• The presenter put a typical run at about 10 to 15 minutes at minimum, end to end.
• Link an MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition. server, such as Slack, at launch so the run can reach the tools the task needs.

Yes. The Slack integration, one of Cursor's first, starts a cloud agent from the thread where the conversation is already happening, with a person in the loop the whole way. Ask a question in a thread and Cursor launches a cloud agent that answers it. Tell it to implement the change and it starts a VM and makes an attempt. The Slack conversation copies over to cursor.com, where you can follow the diff line by line.

Yes. One growth engineer wired a webhook to every inbound message to enterprise@. Each one starts a cloud agent that drafts a tailored reply grounded in the docs and the user table, so it can tell an existing customer who wants to expand from a new demo request. The agent drew on Databricks for user data, Slack for release chatter and Notion for internal docs. Front handled the inbox, and a Zap passed the conversation ID to the agent's trigger.

A cloud run returns artifacts: screenshots and screen recordings of what it built, so you can judge the behavior without running anything yourself. In one demo, an Opus cloud run was told to build a bot, use a repo skill and "give me a demo". It handed back a video of the bot fighting and winning. You watch the recording, then open the PR and merge it if the behavior is right.