What are cloud agents?

A cloud agent is an AI coding agent that runs on remote infrastructure instead of your laptop. You give it a task, it gets its own isolated environment with a copy of your repository, and it writes code, runs tests and returns a branch or pull request for someone to review. Because the work happens in the cloud, it keeps going when you close your laptop, and you can run many agents at once.

Cursor, OpenAI Codex, GitHub Copilot and Claude Code all offer cloud agents today. This guide explains how cloud agents work, how they compare with local and background agents, what to watch for, and how teams use them.

A note on the name: in IT operations, "cloud agent" can also mean a small monitoring program installed on a cloud server. This article is about AI coding agents.

What is a cloud agent?

A cloud agent is a coding agent with its own computer. Cursor's documentation describes cloud agents as agents that "run in isolated VMs in the cloud with full development environments instead of on your local machine," with cloned repos, installed dependencies, secrets, startup commands and network access.

The agent itself works like a local coding agent: a model that reads code, plans, edits files and runs commands. What changes is where those commands run, how many can run at once, and who can see the work.

How cloud agents work

Most cloud agent products follow the same loop.

1. A task comes in. Someone writes a prompt, assigns an issue, mentions the agent in a pull request or Slack thread, or a schedule starts a run.
2. An environment starts. The product spins up an isolated virtual machine or container, clones the repository and runs setup steps like installing dependencies.
3. The agent works. It reads the code, makes a plan, edits files, and runs tests, linters and the app itself to check its work.
4. It hands back a result. The agent pushes a branch or opens a pull request. Some products attach screenshots, videos or logs, and some give you a live preview of the running app.
5. A person reviews. Someone checks the change, asks for follow-ups in the same session, and decides whether it merges.

The environment is the part that matters most. As Cursor puts it, "An agent that can write code but can't run tests, query services, or reach APIs cannot close the loop on its work."

Cloud agents vs local agents

A local agent runs in your editor or terminal and uses your machine. A cloud agent runs somewhere else and uses an environment set up for the task.

	Local agent	Cloud agent
Where it runs	Your laptop, in an editor or terminal	A remote VM or container, usually managed by the vendor
What it can reach	Whatever your machine and its settings allow	The repo, secrets and network access the environment grants
Keeps working when your laptop is closed	No	Yes
Parallel runs	Limited by your machine	Many at once, each in its own environment
Typical output	Edits in your working tree	A branch or pull request
Who can see the work	Usually only you	Anyone with access to the session or pull request

Local agents are better when you need tight back-and-forth, your exact local setup, or a quick experiment. Cloud agents fit tasks with a clear scope that can run on their own, like bug fixes, small features, test coverage, and copy or UI changes.

Neither location is safe by default. Vercel's guide notes that a local agent uses whatever access its configuration permits, while a cloud agent uses its own repository access, secrets and network policy. Check the permissions either way.

We make the case that most agent work is moving to the cloud in Why local development is going away.

Cloud agents vs background agents

The two terms overlap. A background agent keeps working outside your active session. Cursor defines background agents as coding agents that run for a long time, moving the task from your device to the cloud, and adds: "In Cursor, we call these Cloud Agents."

Vercel draws a finer line. A background agent can run locally or in the cloud, and where an agent runs, how much it does on its own, and what needs approval are separate choices. In practice, when people talk about background coding agents, they usually mean cloud agents.

Examples of cloud agents

• Cursor Cloud Agents. Each agent runs on its own VM with your repo, dependencies and secrets. Cursor says you can run as many as you want in parallel, and agents attach videos, screenshots and logs to the pull request. (Cursor)
• OpenAI Codex cloud. Codex Cloud runs coding tasks on OpenAI-managed computers. Each task starts from a prepared environment in its own isolated workspace and can continue while your computer is asleep. (OpenAI)
• GitHub Copilot cloud agent. Copilot works in an ephemeral environment powered by GitHub Actions and can open a pull request when it's done. Each session works in one repository and has a 59-minute maximum run time. (GitHub)
• Claude Code in the cloud. Cloud sessions run in an isolated, Anthropic-managed VM by default, clone your GitHub repo and push a branch for review. Git credentials stay outside the sandbox behind a proxy. (Anthropic)

These products change quickly, so check each vendor's docs for current limits.

Why teams use cloud agents

• Parallel work. One person can hand off several tasks at once instead of waiting on one agent at a time.
• Work that keeps going. Tasks finish while you're in a meeting, asleep or away from your desk.
• Isolation. Each run gets a clean environment, so agents don't collide with each other or touch your laptop.
• Visible work. A shared session or pull request shows the plan, the changes and the test results, so review isn't blind.
• Start from anywhere. Many products let you start a task from Slack, an issue tracker, a browser or your phone.

What to watch for

• Environment setup. An agent without your real dependencies, test data and services can't check its own work. Expect to spend time here first.
• Access and secrets. Decide which repos, secrets and network destinations each environment gets. Prefer products that keep credentials outside the sandbox.
• Review load. More agents means more pull requests. Clear plans, live previews and automated checks make each review faster.
• Vague tasks. Cloud agents do best with a clear definition of done. A fuzzy request comes back as a fuzzy pull request.
• Limits and cost. Session time limits, usage caps and compute pricing vary by product.

Cloud agents for the whole product team

Most cloud agent products are built for one engineer handing off tasks. But once agents run in the cloud, the person starting a task doesn't need a local development setup at all. That opens the door for PMs, designers and ops to make real changes, as long as engineering still controls what merges.

That's what LightSprint does. Anyone on the team can start a change from LightSprint, Slack, Linear or Jira and shape a plan grounded in your codebase. Each change runs in an isolated cloud sandbox with a live preview, using Claude, Codex or your own model subscription, with no markup on inference. Builders can propose changes and view previews but can't merge. Approvers, usually engineers or leads, review and merge through your existing GitHub rules.

See our engineering page for setup and guardrails, and What is a software factory? for how cloud agents fit into a team's delivery process.

FAQ

What are cloud agents?

Cloud agents are AI coding agents that run on remote infrastructure instead of a developer's laptop. Each task gets an isolated environment with the repository and its dependencies, and the agent writes code, runs tests and returns a branch or pull request for review.

What is the difference between a cloud agent and a local agent?

A local agent runs in your editor or terminal and uses your machine's files, credentials and compute. A cloud agent runs in a remote VM or container with only the access its environment grants, keeps working when your laptop is closed, and can run in parallel with other agents.

Are background agents the same as cloud agents?

Usually, but not always. A background agent keeps working outside your active session. Cursor calls its background agents Cloud Agents, but a background agent can also run on your own machine.

Are cloud agents secure?

They can be, depending on setup. Cloud agents run in isolated environments, and good products limit network access and keep credentials outside the sandbox. You still need to control which repos and secrets each environment can reach, and keep human review before merge.

Which tools offer cloud agents?

Cursor Cloud Agents, OpenAI Codex cloud, GitHub Copilot cloud agent and Claude Code in the cloud all run coding agents on remote infrastructure. LightSprint runs cloud agents for the whole product team, with live previews and engineering approval before merge.

Can non-engineers use cloud agents?

Yes, with the right guardrails. Because the agent's environment lives in the cloud, the person starting a task doesn't need a local setup. In LightSprint, PMs, designers and ops propose changes and check live previews, while engineers approve and merge.

Start for free