What is a background coding agent?
A background coding agent works away from your editor: triggered from an issue, run in a sandbox, delivered as a pull request. Definition and checklist.
A background coding agent is an AI coding agent that works away from your editor. You trigger it from your issue tracker or your repository (assign it an issue, say, or add a label), it checks out your code into an isolated sandbox, makes the change, runs the tests, and comes back with a pull request. You review the finished work instead of watching the work happen.
The same category sometimes goes by async coding agent, and the async part is the definition. An IDE agent (Cursor, Copilot in your editor) is synchronous: it edits your working copy while you watch every step. A CLI agent like Claude Code in a terminal is still attended, because it runs where you are and waits on your input. A background agent is detached. Once you hand over the issue, your attention is free until the PR arrives.
What makes a coding agent a background agent
Four properties separate the category from AI coding tools generally.
The trigger lives outside the editor. Work starts from the places work already lives: an issue in your tracker, or a label or comment on the repo. Nobody opens an IDE to start the task, and the person who triggers it doesn't need the repo cloned. (For the Linear version step by step, there's an end-to-end walkthrough.)
Execution is detached from your machine. The agent runs on infrastructure that isn't your laptop, in a session that survives you closing the lid. Its progress reports go to the issue, not to a pane you have to keep open.
The work happens in an isolated sandbox. The agent gets a checkout of the repo in an environment that is created for the run and shut down after it. Your working copy and your production systems are not part of its workspace.
The deliverable is a pull request. The agent's output is a branch and a PR with a description, a diff, and test results. Review is the interface: you merge it, or you leave comments and it revises. This is the property that makes the whole model safe, because nothing lands without a person approving it.
If a tool has all four, it's a background agent, whatever the vendor calls it. If it's missing the sandbox or the PR gate, be suspicious.
Background vs IDE vs CLI agents
| Background agent | IDE agent | CLI agent | |
|---|---|---|---|
| Where it runs | Isolated sandbox on remote infrastructure | Your editor, your working copy | Your terminal, your working copy |
| How it starts | Issue assigned, label added, comment mention | You prompt it in the editor | You prompt it in the shell |
| Who watches | Nobody; progress posts to the issue | You, continuously | You, mostly continuously |
| Unit of feedback | A finished pull request | Each edit as it happens | Each step or tool call |
| Your cost while it works | Near zero | Your full attention | Your attention, minus tab-switching |
| Tests | Runs them in its sandbox as part of the task | You run them | It runs them, you watch |
| Good for | Well-specified tickets, backlog work | Exploration, design, unfamiliar code | Larger attended tasks, scripted work |
The rows that matter most are attention and feedback. IDE and CLI agents multiply what you can do while present. Background agents produce work while you're absent. Those are different products, which is why the comparison "is Cursor better than a background agent" doesn't resolve: it's asking whether a faster keyboard is better than a colleague.
When to go async, and when not to
Exploratory or ambiguous work stays interactive. If you don't yet know what you want, you need the tight feedback loop of an editor or terminal; the task is really thinking, and the agent is a thinking aid. Well-specified tickets go async: when the issue says what done looks like, and the repo plus the issue text is everything the change requires, watching an agent do it is paying attention for nothing. Most teams use both and route per task rather than picking a side.
In practice the routing question is: could a competent contractor who has never met your team do this from the ticket alone? Reproducible bugs, small bounded features, missing tests, and mechanical refactors pass that test. Architecture choices and "make it feel faster" fail it, and so does anything that needs production access.
What to look for in a background coding agent
If you're evaluating background agents, these five questions separate them faster than feature lists.
| Question | Why it matters |
|---|---|
| What can trigger it? | The value is starting work from where work lives. Check it supports your tracker and your repo host; a separate web app you have to visit puts the context switch back in. |
| How is the sandbox isolated? | The agent runs code from your repo. You want per-run sandboxes that are never reused, restricted egress, and no path to production. |
| Does it run your tests? | An agent that opens PRs without running the test suite is delegating verification to you, which defeats the point. |
| What does the review loop look like? | The good ones treat your PR comments as instructions and push revisions to the same branch. The bad ones make you start over. |
| Who controls the model? | Model quality moves fast. Per-repo model choice, and bring-your-own-key pricing so you pay your provider directly, keep you off a vendor's fixed menu and markup. |
A worked example, and the one we know best because we build it: Sinatra triggers from Linear or a GitHub issue label. Each task gets an isolated short-lived sandbox, where Sinatra runs the test command you configure. It reviews its own diff before requesting yours and treats your PR comments as revision requests. You bring your own Anthropic or OpenRouter key (or a ChatGPT subscription) and pay no markup on tokens. The full loop is written up in turning Linear tickets into GitHub PRs, and the roundup of alternatives in every way to turn a GitHub issue into a PR.
Common questions
Is GitHub Copilot a background coding agent?
Its coding agent mode is; its editor mode isn't. Assign an issue to Copilot and it works in an ephemeral GitHub Actions environment and opens a pull request for review, which meets the definition; GitHub's docs now call it the Copilot cloud agent. Copilot's autocomplete and chat inside the editor are IDE-agent features: synchronous and attended.
Do background agents replace IDE assistants?
No. They handle different work. An IDE assistant makes you faster at the work that needs you present: exploring a design, or debugging something you don't understand yet. A background agent removes you from work that doesn't: well-specified tickets that only cost a context switch. Teams that adopt one usually keep the other.
Is "async coding agent" the same thing?
Yes. Both labels (and sometimes "autonomous coding agent") describe the same category: triggered from the tracker or repo, detached from your machine, sandboxed, and delivered as a PR. "Autonomous" is the loosest of the three, since IDE agents market themselves with it too.
Does a background coding agent need access to production?
No, and it shouldn't have any. The sandbox contains a checkout of your repo and whatever your setup commands install. Tasks that can only be done against production data are a bad fit for the category, and a vendor that offers production access as a feature is answering the isolation question wrong.
If you want to see the category concretely, the fastest route is one well-specified ticket from your own backlog. You can start for free, or read the docs first to see how a repo is wired up.