Background agents vs cloud agents: what's the difference?
Published July 10, 2026 · by the AQ team
Background agents and cloud agents are substantially the same idea under two names: an AI coding agent that runs asynchronously in an isolated environment, away from your editor, and comes back with a diff or a pull request. "Background agent" was the dominant term in 2025, and vendors have since renamed the concept: Cursor renamed Background Agents to Cloud Agents, with each agent running on a dedicated VM in Cursor's cloud, and most of the market has followed the same drift as of July 2026.
The pattern both terms describe
Strip away the branding and the workflow is identical. You hand the agent a task (a prompt, a Linear issue, a GitHub issue, a Slack message). The agent runs without supervision in an environment that is isolated from your working copy: its own checkout of the repository, its own installed dependencies, its own branch. When it finishes, it returns something reviewable, usually a pull request, and notifies you. The defining properties are asynchrony (you do other things while it runs) and isolation (its changes cannot touch your working tree until you accept them). This is the opposite of the in-editor, pair-programming interaction where you watch every edit as it happens.
What actually changed: from local processes to cloud VMs
"Background" originally described where the agent sat in your attention, and early implementations were literal: a background process on your own laptop, working in a separate directory while you kept coding. The execution model then moved to vendor-managed cloud VMs, for practical reasons. A cloud run survives your laptop closing. You can run ten agents in parallel without melting your own CPU and RAM. Environments are provisioned the same way every time. And triggers stop being editor-bound: as of July 2026, Cursor's Cloud Agents can be kicked off from the editor, Slack, Linear, or GitHub.
The rename to "cloud agent" is more accurate about where execution happens and less descriptive about the interaction model. In the attention sense, cloud agents are still background agents: you fire them off and review later. The vocabulary shifted because vendors wanted the name to advertise the infrastructure, not the workflow.
Trade-offs: local, vendor cloud, or your own cloud
The real decision is not between two names but between three places the agent can run:
| Local background process | Vendor cloud VM | Your own cloud | |
|---|---|---|---|
| Latency to start | Low: your environment already exists | Cold start while the VM and dependencies provision, unless the vendor keeps pools warm | Depends on your setup: warm pools and cached dependencies make it fast |
| Cost | Hardware you already own | Metered vendor pricing on top of model tokens | Your existing infrastructure bill |
| Secrets and compliance | Code and credentials never leave your machine | Code and secrets execute on vendor infrastructure; needs a compliance review | Everything stays inside your own boundary |
| Laptop lifetime | Runs die when the laptop sleeps or the process is killed | Runs survive independently of your machine | Runs survive independently of your machine |
| Team visibility | None: the run exists only on one person's machine | Usually run logs and diffs in a vendor dashboard, scoped to the person who started the run | Whatever you build or buy: can be fully shared across the team |
Where "asynchronous coding agents" fits
"Async coding agents" (or "asynchronous coding agents") is the neutral umbrella term, and it describes the interaction model rather than the infrastructure. A local background process, a vendor cloud agent, and a run on your own servers are all asynchronous coding agents: you delegate, you leave, you review. The community phrases "parallel coding agents" and "kanban for coding agents" live in the same space, emphasizing running many async agents at once and the board-style UI for managing them. Use "async" when you mean the workflow, "cloud agent" when you mean vendor-hosted execution, and "background agent" mostly when reading 2025-era documentation.
The third axis: who can see and join the run
Vendor framing debates two axes: where the agent runs (local versus cloud) and how you interact with it (synchronous pairing versus asynchronous delegation). There is a third axis most products ignore: who can observe and take over a run while it is in progress. Nearly every background or cloud agent product is single-player. The run belongs to the person who started it; teammates see a pull request at the end, if anything. That model breaks down exactly where teams need it: when the person who started a run is offline and the agent is stuck, when two engineers want to steer one session together, or when a new hire could learn fastest by watching a senior engineer drive an agent live.
Multiplayer agent sessions treat the run as a shared place instead of a personal process: any teammate can open the live terminal, watch the agent work, type into the same session, and take over the review. Combined with the your-own-cloud column above, this is the configuration the big vendors do not offer as of July 2026: durable cloud execution, inside your own infrastructure, visible to your whole team.
Where AQ fits
AQ is the multiplayer workspace where engineering teams run AI coding agents like Claude Code and Codex together: shared live terminals, a code editor, and app previews, in your own cloud. In the terms of this page, AQ runs cloud agents in the execution sense (isolated git worktrees on infrastructure you control, surviving any one laptop) and multiplayer in the access sense (every session can be opened, watched, and driven by teammates). If you want single-player, vendor-managed runs with zero setup, Cursor's Cloud Agents and similar platforms are the fastest path. AQ's territory is the third axis: teams that want the whole group inside the same agent sessions, on their own infrastructure.
Frequently asked questions
Are background agents and cloud agents the same thing?
Substantially, yes. Both mean an AI coding agent that runs asynchronously in an isolated environment and returns a diff or pull request. "Background agent" was the common 2025 term; vendors renamed it as execution moved to managed cloud VMs. Cursor's rename of Background Agents to Cloud Agents is the clearest example.
Why did Cursor rename Background Agents to Cloud Agents?
The new name describes the infrastructure rather than the workflow: each Cloud Agent runs on a dedicated VM in Cursor's cloud and, as of July 2026, can be triggered from the editor, Slack, Linear, or GitHub. The interaction model did not change; the runs were never really about being in the background of your editor once they left your machine.
What is an asynchronous coding agent?
An umbrella term for any coding agent you delegate to and review later, regardless of where it runs. Local background processes, vendor cloud agents, and self-hosted runs all qualify. It is the most durable of the three terms because it names the workflow instead of the infrastructure.
Can cloud agents run on my own infrastructure?
On most platforms, no: the VM lives in the vendor's cloud, which is the point of the product and the sticking point for compliance-sensitive teams. Alternatives exist as of July 2026: OpenHands positions as an open platform for cloud coding agents, and AQ runs agent sessions in your own cloud with team-wide access to each live session.