Background tasks

Some agent work takes longer than you want to sit and watch. An implementation that runs for forty minutes, a Flow stepping through plan to pull request, a research sweep across a dozen files. A background task is how that work proceeds on its own: it keeps running while you do something else, it tells you when it reaches a point that needs you, and it waits with its results in hand until you come back.

A background task is one of the kinds of work that show up as a session. This page is about the task itself: where one comes from, the states it moves through, how it holds its work for your review, how an agent can fan a task out into a batch of sub-agents, and how you act on a task once it is running.

Where a background task comes from

You do not submit work to a task queue. A background task is created out of work you are already doing, by one of three paths.

• Send a chat to the background. While the agent is working in a chat, you click the background button. The in-flight turn becomes a background task: the conversation's sandbox is re-keyed from the foreground chat to the background task, the agent keeps running with its output flowing to the task instead of the open panel, and the panel is free for your next thing. This is the most common way a task is born.
• Run a Flow in the background. Starting a Flow run in background mode creates a task that carries the run: it aggregates the turn count and the cost across the Flow's steps, and it parks in review when the Flow pauses at a checkpoint. Unlike a backgrounded chat, which runs and then waits in review, a background Flow can run all the way to Merged, because its final step has somewhere to land: the pull request it opens.
• Fan out into sub-agents. An agent working on a problem can spawn a batch of sub-agents to work parts of it in parallel, each one a task that reports back. Fan-out is covered in its own section below.

In every case the work was already underway; sending it to the background is a choice about how much of it you watch, not a different kind of work.

Background or interactive

Keep work interactive when you want to steer it turn by turn, or when the next decision is one only you can make. Send it to the background when the work is long, the path is clear, and you would rather come back to a finished result than watch it form. The choice is not permanent: a backgrounded task you resume reopens as a live conversation, right where it left off, so you can hand a long stretch to the background and take the wheel again the moment you want to.

The states a task moves through

A task carries a status that tells you exactly where it stands, with a matching color so you can read a panel of them at a glance.

Once a task has settled, you can clear it from the panel, which removes the task and tears down its sandbox. The states a task actually reaches are driven by the work itself: a backgrounded chat agent runs and then waits in review when it is done; a background Flow runs, parks in review at each checkpoint, and merges when it finishes cleanly.

Review before the work lands

The point of the review state is that the work waits for you before it goes anywhere. When a task reaches review, it holds what you need to judge it: a summary of what the agent did, the list of files it changed, and the turn count and cost it took to get there. You read that, and then you act: resume the task to carry it forward, or leave it parked while you decide.

This is the background counterpart to the checkpoints you approve inside an interactive run. An interactive run pauses and waits for you in the moment; a background task does the work first and then waits for you with the result in hand. Either way, the change does not land without a person seeing it. The task's Flow checkpoints, if it is carrying a Flow, still gate the run: a background run parks in review at a checkpoint rather than slipping past it, unless that specific checkpoint was authored to auto-approve in the background, in which case the approval is recorded on the step so the record still shows what advanced.

How you see and act on a task

A running task is never out of reach. It surfaces in three places, each suited to a different moment.

• The Background tasks panel is a drawer that slides in from the right with a floating button that appears the moment you have a task running. It shows a card per task with the status, a live elapsed timer, the file count, and an expandable detail with the flow steps, the summary, and the turns and cost. It opens itself when a new task appears, so you can see the work the moment it starts.
• The Command Center lists your tasks alongside your chats and Flow runs in the live hub, so the task sits next to the rest of what you have in motion.
• The task detail page is the full view: the timeline of what happened, the parameters it ran with, and a transcript tab, reached by clicking the task anywhere it appears.

From any of these, a task card carries the actions that fit its state. Continue in Chat picks a task back up, reopening the conversation from where it left off with its sandbox re-attached. Cancel stops a running task, holding the sandbox so you can pick it up again. And once a task has settled, a single control clears it for good, removing the task and tearing down its sandbox when you are truly done with it. (On the task's own detail page these read Resume and Delete; same actions, fuller-width labels.)

A task reports what it is doing the whole time it is doing it. The card and the detail page update live: the status changes, the file-changed list grows, the agent's running summary fills in, the flow steps tick over, and the turn count and dollar cost climb. When the task settles, the final turns and cost are on the card and on the task's detail page. You never have to wonder whether a backgrounded task is still working; it is telling you all along.

When a task reaches you

You do not have to keep the panel open to know where a task stands. When a task finishes its work, its owner gets a notification, Task completed: "Implement CSV download button," that opens straight to your planning area. When a task fails, the notification says so and carries the reason it stopped, so you learn what broke without opening it first. Both sit in the Tasks category of your notifications alongside everything else the platform tells you about, and they flow through the same email and Microsoft Teams channels you have configured. Between the panel that opens itself when a task starts and the notification that arrives when one finishes, you are told at both ends without watching the middle.

Fan-out: one agent, a batch of sub-agents

When a problem splits naturally into parts, an agent does not have to work them one at a time. It can fan out: spawn a batch of sub-agents, hand each one a piece, let them work in parallel, and gather their results back. A research question across a dozen files, a refactor that touches several modules, a set of independent checks: fan-out turns these from a long single thread into a short parallel one.

The shape is deliberately flat and bounded.

• An agent spawns up to twenty sub-agents in a batch.
• The sub-agents run co-located on the same sandbox as the agent that spawned them, so they share the workspace without each paying to clone it.
• The structure is two levels, never more: a sub-agent does its piece and reports back; it cannot fan out again. The platform rejects a recursive spawn, so a fan-out can never sprawl into an unbounded tree.
• The spawning agent waits for the batch and gathers the results, then continues with everything its sub-agents found.

Fan-out is available to a working agent in a project chat and to a Flow step, through the same mechanism and the same twenty-per-batch ceiling.

The shape is the point. A single task becomes a burst of parallel work and comes back as one result, and the bounds above are what keep that burst from turning into an unbounded tree of agents spawning agents. The parallelism is an implementation detail the platform handles; what reaches you is still one task with one result to review. Fan-out makes agent work faster without making it harder to oversee.

To see it in motion: Sarah's agent is asked to check the CSV export against the team's customer fixtures. The work splits cleanly, one fixture per check, none depending on the others, so the agent fans out a sub-agent per fixture on the sandbox it already has. They run at once instead of in series, each reports its result, and the agent gathers them back and tells Sarah which fixtures passed and which need a fix, as one answer. A sweep that would have been a long single thread comes back in the time of its slowest check.

A worked example

Sarah is in a chat on the CSV download button plan. The agent is forty minutes into the implementation, and she has a meeting. She clicks the cloud-arrow-up Background button: the in-flight turn becomes a background task, the conversation's sandbox re-keys from the chat to the task, and the chat panel frees up. The Background tasks floating button appears bottom-right with a running badge, and she goes to her meeting while the agent keeps working.

When she comes back, the task has flipped to review. She opens it: the summary reads "Added a CSV download button to the Reporting page and wired it to the export endpoint," two files are listed as changed, and the card shows it took 23 turns and $0.84. She reads the summary and the changed files, sees it is what she asked for, and clicks Continue in Chat: the task reopens as a live conversation right where it left off, and she carries it forward from there. The work happened while she was in her meeting, but it did not land until she saw it. That is the whole contract of a background task in one sitting.

Permissions

tasks.read ships on every content-facing role, so everyone sees their own background work; tasks.read.any is the elevated read that lets a lead or admin watch the team's. chat.background.manage is separate from the everyday chat.use, so a workspace can decide who runs work unattended. A task started by one person and a task started by another are kept apart by these scopes: asking for a task you do not own and cannot read returns nothing rather than leaking that it exists. Background work is visible to the people who should see it and private from the people who should not, by the same scope model that governs the rest of the platform.

Why background work waits for you

Long-running agent work poses the same question every other piece of agent autonomy does: how do you let it run without watching it, and still stay in control of what it does? The two easy answers both fail. Watch every turn and you have automated nothing. Let it run and merge on its own and you have an agent changing your work while no one is looking.

A background task is the third path. It runs without you, but it waits in review with its results in hand before anything lands. The states are honest about where the work is (provisioning, running, review, merged, failed), the review state holds the full evidence before you decide, and the work proceeds on its own schedule while the decision to accept it stays yours.

For a senior PM, that is the answer to "how much do I have to watch this?" None of it, until the moment it asks for you. For an engineer, the summary and the changed files in the review state are the receipt, not a claim that the work got done. For a lead, other people's tasks are an elevated read scope, so a team's unattended work stays visible to the people accountable for it. For a new hire, a single task read from its review state to its resume is the whole operating model in one card: the agent did the work, and a person signed off before it counted. Background tasks are how Disco Parrot lets the agent work while you are away without ever letting the work land while you are not looking.