# What are background coding agents?

A background coding agent works on a task without the developer watching, often in a cloud environment, and returns a branch or pull request at the end.

Last updated September 29, 2026, 8 min read

## Learning objectives

After reading this article you will be able to:

-   Define background coding agents
-   Explain where they run and what they return
-   Identify the checks their output needs

## Related content

-   [What is a coding agent?](https://specstory.com/learning/ai-coding/coding-agent)
-   [What are parallel coding agents?](https://specstory.com/learning/ai-coding/parallel-coding-agents)
-   [What is human-in-the-loop for coding agents?](https://specstory.com/learning/ai-coding/human-in-the-loop)
-   [What is plan mode in a coding agent?](https://specstory.com/learning/ai-coding/plan-mode)

## What are background coding agents?

Background coding agents are [coding agents](https://specstory.com/learning/ai-coding/coding-agent) that work through a task while nobody watches, then hand back a branch or [pull request](https://specstory.com/learning/code-review/pull-request). They are also called asynchronous coding agents. The ones that run on a remote machine are often called cloud agents, and they keep working after the developer's laptop closes.

A developer hands over the task, e.g. by assigning an issue to Copilot cloud agent from GitHub, and turns to other work. Nobody approves the agent's steps while it runs, so a reviewer is often the first person to see its changes.

[Ramp says](https://builders.ramp.com/post/why-we-built-our-background-agent) its background agent writes about 30% of the pull requests merged to its frontend and backend repositories.

[Cursor says](https://cursor.com/blog/cloud-agent-lessons) more than 40% of its own internal pull requests now come from cloud agents (June 2026). Both figures describe each company's own engineering teams, not software teams in general.

## How does a background coding agent work?

A background agent runs the same agent loop as any coding agent, inside an environment that a service prepares for the task. One task usually moves through these steps:

1.  A person or a schedule starts the task, e.g. a developer sends it from a team chat.
2.  The service creates an isolated environment, which can be a virtual machine or a container, and clones the repository into it.
3.  A setup script installs the project's dependencies, so the agent can build the code and run its tests.
4.  The agent edits files, runs commands, and reads the output, usually with no person approving each step.
5.  The agent commits its changes to its own branch. Some services push it as the agent works, and others push it when a person opens the pull request.
6.  The agent, or the person, opens a pull request with the agent's summary of the work.
7.  A reviewer reads the pull request and can ask the agent for changes on the same branch.

Diagram: Where a background agent works and where the checks happen

No person watches the agent until it opens a pull request. Failures that the checks find go back to the agent, which pushes fixes to the same branch.

A [sandbox](https://specstory.com/learning/environments/ai-sandbox) limits the agent's commands to the task's files and approved network hosts. When the environment is a [microVM](https://specstory.com/learning/environments/microvm), each task also gets its own kernel. [GitHub's documentation](https://docs.github.com/en/copilot/concepts/agents/cloud-agent/about-cloud-agent) says Copilot cloud agent has "its own ephemeral development environment, powered by GitHub Actions."

Some tools run a background agent on the developer's own machine, e.g. Claude Code. Its `--bg` flag starts a [background session](https://code.claude.com/docs/en/agent-view) that keeps working after the terminal closes. Shutting the machine down stops the session, while a remote environment keeps running.

## What is an example of a background coding agent?

Here is an illustrative example. Acme Co. sells furniture online. In the evening, a developer at Acme assigns a GitHub issue to a cloud agent. The issue says "Let customers edit their delivery address during checkout." The task then runs overnight:

1.  The service starts a virtual machine, clones Acme's repository, and runs `npm ci`.
2.  The agent edits `checkout/AddressForm.tsx` and adds an `updateAddress` handler.
3.  The agent runs `npm test`, and the run reports `42 passed`.
4.  The agent pushes the branch `agent/delivery-address` and opens pull request #1042. Its summary ends "Address editing is done."
5.  Acme's [continuous integration](https://specstory.com/learning/ci-cd/continuous-integration) (CI) pipeline runs the tests on the pull request, and they pass.
6.  In the morning, a reviewer starts the app from the branch in an [ephemeral environment](https://specstory.com/learning/environments/ephemeral-environments), adds 2 items to the cart, and changes the address. The address saved, but the cart emptied.
7.  The reviewer posts those steps on the pull request, and the agent pushes a fix to the same branch.

No test checked the cart after an address change, so the agent's run and the CI run both passed. Nobody watched the agent work, so the reviewer was the first person to use the changed feature.

This example is simplified. A real project would also add a test that checks the cart after an address change.

## What checks does a background agent's work need?

A background agent's summary says "done," but a [false completion claim](https://specstory.com/learning/verification/coding-agent-done-claims) reads the same as a true one. Its pull request needs these checks, in this order, so a failing change goes back to the agent before a full review of its diff:

1.  **Continuous integration.** The team's CI pipeline builds the branch and runs the tests on the pull request. On some platforms a person has to approve the run first. [GitHub's security guidance](https://docs.github.com/en/copilot/concepts/security-governance-and-network-settings/risks-and-mitigations) says that, by default, workflows do not run on Copilot cloud agent's pull requests until the code is reviewed and someone with write access approves them.
2.  **A run of the changed workflow.** Someone starts the app from the branch and tries what the task describes, e.g. in a preview environment. When the agent's code misses a case, its own tests often miss the same case.
3.  **A review of the diff.** A reviewer checks that the change matches the task and that no test was weakened or deleted. The full routine for [reviewing agent pull requests](https://specstory.com/learning/code-review/reviewing-agent-pull-requests) also traces the riskiest path through the code.
4.  **A decision on the result.** A failure goes back to the agent as steps it can repeat, and the agent pushes a fix to the same branch. A pull request that missed the task is often cheaper to close than to fix by hand. The next attempt can start from a clearer task, e.g. a plan reviewed in [plan mode](https://specstory.com/learning/ai-coding/plan-mode).

## What are the limits of background agents?

Working with no person watching has these limits:

-   **A wrong start runs to the end.** If the agent builds the wrong thing, nothing stops it unless someone opens its session, so the mistake often shows up only at review.
-   **The environment caps what the agent can check.** An agent whose environment cannot start the database or open a browser cannot run the workflow it changed. A run with gaps does not establish that the whole app works.
-   **Output can outgrow review.** One developer can start several [parallel coding agents](https://specstory.com/learning/ai-coding/parallel-coding-agents), and each one opens a pull request. Their pull requests lengthen the [review bottleneck](https://specstory.com/learning/code-review/review-bottleneck), and their pushes add to the [CI bottleneck](https://specstory.com/learning/ci-cd/ci-for-coding-agents).
-   **Large diffs get skimmed.** A broad task produces a long diff, and [pull request size](https://specstory.com/learning/code-review/pull-request-size) sets how closely a reviewer can read it. Smaller tasks keep each diff short enough to read.
-   **Access is narrow on purpose.** The environment often limits which hosts the agent can reach and which secrets it holds, so tasks that need production services may not run there.

## How is a background agent different from an interactive agent?

An interactive agent works while the developer watches. The developer answers the agent's questions and approves its commands. A background agent takes the whole task and reports back at the end, so its first [human-in-the-loop](https://specstory.com/learning/ai-coding/human-in-the-loop) approval point is often the pull request. The two differ in these ways:

| Aspect | Interactive agent | Background agent |
| --- | --- | --- |
| Where it usually runs | The developer's editor or terminal | A remote environment |
| Who approves each step | The developer, at permission prompts | Nobody, within the environment's limits |
| When a person sees the work | While the agent works | When the pull request opens |

One tool often works both ways, e.g. Claude Code runs in a terminal and in cloud sessions. Either way, the developer who started the task stays accountable for the change.

## How does RunStory help with background coding agents?

Work that a background agent finishes can arrive with passing tests while nobody has run the workflow the agent changed. RunStory runs your software against the change. It sends reproducible failures back to your coding agent.

Your coding agent receives the actions RunStory took and evidence of the unexpected result. RunStory is in private alpha for CLIs and web apps. The alpha tests your software in isolated sandboxes.

[Join the RunStory alpha →](https://specstory.com/runstory#alpha)

## FAQs

### Do background coding agents need CI/CD to run?

Background coding agents do not need a CI/CD pipeline to run, because the agent service sets up an environment for each task. Some services build that environment on a CI platform, e.g. GitHub Actions. The pipeline's main job is to test the pull request that the agent opens.

### Can coding agents run in the background on a laptop?

Coding agents can run in the background on a laptop when the tool offers a background session that keeps working after the terminal closes, e.g. in Claude Code. Shutting the laptop down stops that session, while an agent in a remote environment keeps running.

### Do background agents replace developers?

Background agents do not replace developers, because a person still chooses the task, reviews the pull request, and decides whether it merges. The developer who started the agent stays accountable for the change. The agent's summary reports what it did, not whether the software works.

### What do you do with pull requests agents open overnight?

Pull requests that agents open overnight need the same checks as any other change, in a set order. Let CI finish, run the changed workflow on the branch, and then review the diff in full. Send failures back to the agent as steps it can repeat, and close any pull request that missed the task.

---

Source: [What is a background coding agent? | SpecStory](https://specstory.com/learning/ai-coding/background-coding-agents)