Background Agents: Work That Advances While You Do Something Else
A background agent works without blocking your session and tells you when it finishes. Which limits to set before leaving it alone and how to review it.
What changes compared to a normal agent?
A normal agent occupies your session: you write, you wait, you read the result, you decide the next step. A background agent leaves that cycle. You launch the task, continue with another one, and the result arrives later.
The difference is not only convenience. It changes how much attention the person needs and when they have to decide. A background agent can be running while the person reviews a pull request or writes a document.
According to the Claude Code documentation, background subagents “return their result via a completion notification on a later turn”. In other words, the result does not appear in the middle of your work: it arrives as a notification.
Often the background work is a subagent that the main agent launches. Each pass of its own cycle is a turn of the agent loop.
What kind of task suits it?
Tasks that do not need your decision at each step:
- Exploring a repository and returning a list of findings.
- Reviewing many files against a fixed rule.
- Generating drafts you will review later.
- Running a test suite and reporting failures.
It is not a good fit for tasks where each step depends on your decision, or for irreversible actions without review. A background agent keeps advancing while you look at something else. In Claude Code, anything that needs a permission you did not grant beforehand is either asked in the main session or denied, depending on the version. That is why the design of the task has to anticipate the points where it should stop.
What controls should you set first?
Before you leave it alone, define five things:
- Permissions. Which tools it can use. For exploration, reading is enough.
- Scope. Which files or folders it can touch.
- Turn limit. How many cycles it can run before stopping.
- Budget. The maximum spend you allow. The Agent SDK offers a dollar limit, and the spend of subagents counts toward that total.
- Review point. What result gets reviewed before changes are applied.
These limits are not a formality. They are what turns an unsupervised agent into one with deferred supervision. Keep in mind that the turn limit counts only the turns where the agent uses tools, not every message.
How do you stop one?
According to the Claude Code documentation, the shortcut Ctrl+X Ctrl+K stops all background subagents in the session, and asks for confirmation with a second press within three seconds. To see what is running, use the /tasks command. If a subagent is in the foreground and in your way, Ctrl+B sends it to the background. With the Agent SDK, a budget limit ends the run with a budget error instead of letting the spend continue. Learn the shortcut before you need it.
Why does it matter to a designer?
Because it defines the design of the notification and the moment of review. If an agent finishes while the person is concentrating, the notification interrupts. If it finishes and nobody sees it, the work is lost. Some design questions:
- Does the person learn the result without looking at the screen?
- Is the result presented as something to review or as something already applied?
- What happens if the agent fails halfway through?
- How long can a pending result stay before it stops being useful?
The answers decide whether the agent is useful or just noise. The criteria for interrupting are worked out in agent notifications.
When is it NOT a good idea?
- When the task is short. Launching a background process has a coordination cost.
- When the result is urgent and you cannot wait for the notification.
- When the agent touches production systems without an approval point.
- When you will not review the result. Work nobody looks at is wasted spending.
Example
Illustrative example: a designer asks a background agent to review the 40 screens of a checkout flow against the contrast guide. She grants read-only permission, a limit of 30 turns and a budget of two dollars. Meanwhile she writes the script for an interview. When the notification arrives, the agent has delivered a table with six findings and their evidence. She reviews the six, approves three and dismisses the rest, and the agent changed nothing without her approval.
How do you review a result that arrived on its own?
When the notification arrives, the result is not approved: it is a proposal. Review it with the same care as a pull request. Ask for evidence: files and lines, screenshots or the test output. Compare what the agent says it did with what actually changed, especially if it had write permissions. If the result is a list of findings, verify at least the first two before trusting the rest. Record in the team log which task was delegated, with which permissions and what was accepted. That traceability is what lets you repeat a good workflow and avoid a bad one.
What you can do tomorrow
Before you launch your next background task, write in one line the turn limit, the budget and the list of allowed tools. Also note when you will review the result. If you do not know what you will do with the result, do not launch the task. And practice the shortcut that stops subagents in Claude Code once, so you do not have to look for it in a hurry when you need it.
Common mistakes
- Granting write permissions to a task that only needed reading.
- Launching several background agents on the same file.
- Forgetting the result exists and never reviewing it.
- Not setting budget or turn limits.
- Trusting that the agent will stop by itself once it has finished what you asked.
- Assuming
Ctrl+X Ctrl+Kalso stops terminal commands left running: the documentation describes it for subagents only.