What is Background coding agent?
An agent that takes a whole task, completes it in its own isolated environment, and delivers a pull request for later review — while you do something else.
The work continues unattended, so trust moves from watching to reviewing: the hard engineering is everything between the task and the PR.
On this page
A background coding agent is a coding agent that receives a task and completes it autonomously in its own isolated environment — producing a branch and a pull request — while the person who assigned the work is doing something else. Both halves of the definition carry weight: the agent works in an environment separate from your machine, and the result is reviewed after the fact rather than watched as it happens.
The category went from demo to product through 2025, as model capability crossed the threshold where whole tasks became practical. METR's 2025 research found the length of task an AI completes unattended with 50% success has doubled roughly every seven months since 2019 — and by 2025 every major coding tool shipped a background mode.
Background vs the rest of the spectrum
| Kind of tool | Where it runs | Where you are | What you get |
|---|---|---|---|
| IDE assistant | In your editor | Watching, accepting diffs | Edits approved as they are proposed |
| Interactive terminal agent | A local terminal session | Present, approving commands | Local edits, runs you trigger |
| Background coding agent | An isolated environment — usually a cloud container or VM | Away | A branch and a pull request, reviewed later |
The distinguishing property is separation in time. Assignment and acceptance drift apart — minutes, or a whole night — and whatever sits between them has to make the result trustworthy without a human watching.
What happens between the task and the pull request
Every background agent implements roughly the same pipeline, and every stage is a place unattended work can go wrong.
| Stage | What happens | Typical implementations |
|---|---|---|
| Intake | The task enters the queue | Copilot: issue assignment and PR comments; Devin: Linear, Jira, Slack; Jules: GitHub issues |
| Environment | An isolated workspace, repository cloned | Copilot: isolated container, network firewall on by default; Codex: cloud sandbox VMs; Devin: cloud workspace with shell, IDE and browser |
| Work | Branch, edits, tests | Dedicated branches, never the default branch |
| Delivery | A reviewable artefact | Pull requests, typically drafts |
| Recovery | CI failures or review comments come back | Claude Code's cloud sessions can auto-fix CI failures and review comments; Copilot follows up on PR comments |
| Human gate | Someone accepts or requests changes | Copilot requires approval before workflows run on agent PRs |
Two stages decide most outcomes. Environment isolation is what makes leaving the work safe — an agent with its own container, branch and network firewall cannot break a machine or push to a protected branch while nobody watches. Delivery as a pull request is what makes the work governable — a diff, a comment thread, and a gate that someone must pass before anything merges.
The tools, briefly
All facts from the vendors' own documentation: GitHub Copilot's coding agent works from issue assignment in an isolated container; OpenAI Codex runs tasks in cloud sandboxes with read-only, workspace-write and full-access modes; Devin provisions a cloud workspace and takes tickets from Linear, Jira and Slack; Google's Jules is an asynchronous coding agent powered by Gemini 2.5 Pro, launched to everyone in August 2025; Claude Code's cloud sessions run in a VM that keeps working after the laptop closes and can be steered from a phone. The differences between them are less about model quality than about operating model — who holds the queue, what the agent may touch without asking, and who sees the result first.
Best practices for unattended work
1. Scope work as a ticket, not a message
The brief carries all the context the agent will ever get. Goal, acceptance criteria, scope, how to verify — written for a competent contractor on their first day, not a colleague who can ask.
2. Default to isolation
Own container or machine, own branch, network restricted, secrets out of reach. This is the vendors' default and should be yours; see sandbox.
3. Keep review independent of authorship
The same misreading that produced the change can produce tests and self-assessment that are confidently wrong in the same direction. Review must come from something that did not share the author's reading — a separate reviewing agent or a human.
4. Budget for bounces
Unattended work does not go task-to-merge in one pass: review sends changes back, CI fails, and branches rot into merge conflicts while queued. A mature setup treats bounces as normal — the ticket returns to a queue, a fresh run picks it up, and the loop repeats until review passes. What matters is whether bounces resolve, not whether they happen.
5. Require evidence at hand-off
Requests run, output, test counts and screenshots, attached to the work. Evidence that states its own limits is what lets the reviewing side audit the claim instead of re-deriving it.
6. Escalate instead of looping
Cap retries. An agent that fails the same step five times has learned nothing by attempt five; stop it and hand a human the failure history.
Background coding agents in YATFA
YATFA runs background agents as an organisation rather than a session: a dispatch queue that re-dispatches on failure, work in isolated environments on dedicated branches, review by agents that did not write the change, QA with evidence attached to every ticket, and autonomy settings deciding per project how far unattended work may go. When a run cannot resolve something, it stops into escalations rather than looping — the difference between a colleague and a zombie.
Frequently asked questions
Is a background coding agent the same as an autonomous agent?
"Background" describes where and when it works — unattended, in its own environment. "Autonomous" describes how much it may decide. A background agent can be tightly bounded (docs and tests only, always stops before merge) or widely trusted; the degree is an autonomy decision, not a property of the architecture.
Are background coding agents safe to leave running?
As safe as their boundaries. The risk pattern to avoid — private data, untrusted content, and an outbound channel combined without isolation — is what Simon Willison calls the lethal trifecta. Isolation, least privilege, branch-only writes and server-enforced review are what make unattended work boring.
How is this different from just leaving a terminal agent running?
A terminal agent runs in your environment with your permissions and dies when the session dies. A background agent runs in an isolated environment with its own scoping, holds a place in a queue, survives your laptop closing, and returns its work as a reviewable artefact. The differences are organisational: queue, isolation, review.