When to Use Background Agents vs Interactive Copilots
Match routing to task structure, not preference—copilots steer, agents act alone.
The choice between an interactive copilot and a background agent is determined by the structure of the task, not by team preference, tool loyalty, or philosophy. The field has already settled the vocabulary: a copilot suggests and the engineer applies it. An agent does the task and reports back. The gap between advice and action is structural, not stylistic. A team that picks its tool by habit or availability will systematically misroute work.
This piece argues that a small set of task properties reliably predict which mode fits, turning what is often a judgment call into a repeatable routing decision. The VS Code multi-agent framework makes the stakes concrete: for each moment, an engineer must pick the right tool, a local session when steering is needed, a background or cloud agent when isolated changes are the goal, parallel subagents when multiple processes must run. The question is never which tool is better. It is which task properties determine the right tool.
How the four task properties map onto the two modes
Four properties reliably separate what belongs in an interactive copilot session from what belongs with a background agent. They are duration, reversibility, context dependency, and steering need. Each property adds a dimension the previous one did not cover, and together they form a coherent decision lens rather than a checklist.
Duration is the single strongest predictor of which mode fits. Background and cloud agents are designed for longer-running, unattended execution. Interactive copilots are optimized for fast, turn-by-turn iteration inside an open editor session. Short tasks, such as a line fix, a quick rename, or a single-function stub, close so fast that the overhead of delegating to a background agent adds no value. The copilot's real-time suggestion is already at the engineer's fingertips. As task duration grows, the cost of keeping a human in the loop the whole time grows with it. A background agent absorbs that wait time and returns a result asynchronously.
Reversibility measures whether the output can be inspected, rejected, or rolled back before it touches anything that matters. Background agents that return a pull request create a natural review gate. The work is isolated, visible, and reversible before merge, and the engineer inspects the diff rather than watching every keystroke. If the agent is wrong, a task whose output goes straight into the working file is harder to reverse. A live refactor or an inline suggestion accepted with Tab leaves no review step between the agent's output and the working tree. A copilot keeps the engineer's finger on the undo key throughout. Isolation matters here as well: background agents run in worktrees or remote infrastructure, so a bad run doesn't contaminate the engineer's local state.
Context dependency captures how much implicit, in-the-moment knowledge the task requires that only the engineer currently holds. If completing the task requires understanding a design decision the engineer is still forming, or depends on context that lives only in the engineer's head and hasn't been written down, a copilot keeps that context in the loop continuously. If the task's scope can be fully specified upfront, such as a clear issue, a test suite to write, or a dependency to upgrade, a background agent can proceed without further input. The context travels with the prompt and the codebase. Agents maintain long-running context through dedicated files, notably CLAUDE.md for Claude Code and AGENTS.md as a cross-tool convention read by Codex, Cursor, and others, that carry project conventions across sessions. Well-documented codebases therefore have lower context dependency than undocumented ones, and cloud agent platforms that maintain workspace state across runs let teams codify the implicit knowledge that would otherwise force a human back into the loop mid-task.
Steering need is how often you must redirect, correct, or extend the work while it runs. Local interactive agents are for when fast, interactive help is required. Cloud agents delegate asynchronously for longer-running tasks. The distinction is precisely about whether mid-flight intervention is expected. Exploratory or ambiguous tasks, where the right approach is discovered through iteration, demand continuous steering and belong in the interactive mode where the engineer can redirect after every response. If success criteria are clear, you don't need steering mid-run. Sending them to a background agent lets the engineer do other work while the task executes.
What the routing looks like on real task types
Apply the same framework to common engineering tasks and you get routing decisions that match how capable teams already use these tools. It also reveals the misrouting patterns that waste time. Several task categories route clearly to background agents. Adding or expanding a test suite for existing code takes moderate-to-long duration, comes back as a reviewable pull request, gets its context fully from the code under test, and needs no mid-flight steering. Dependency upgrades, lint fixes, mechanical refactors, and doc synchronization share the same profile: bounded, testable, and reversible. These are the canonical background-agent tasks.
Other tasks route just as clearly to interactive copilots. With exploratory architecture decisions, the engineer is still forming the approach, so context dependency is high, steering need is continuous, and each exchange is short. Debugging a subtle production issue, where each observation changes what to try next, keeps the copilot's pace aligned with the engineer's evolving mental model. A background agent would run to completion on a stale hypothesis. Writing novel business logic with implicit domain constraints not captured anywhere in the codebase is similarly interactive: the context lives in the engineer's head and needs to flow into each exchange.
The misrouting patterns that actually cost teams time are predictable. Sending an exploratory or ambiguous task to a background agent produces a plausible but wrong result that requires more rework than doing it interactively would have needed. The agent has run confidently in the wrong direction. Using an interactive copilot for a long, mechanical task keeps the engineer tethered to a session that doesn't need them. The most common misrouting is treating all agent use as interactive, asking the agent for suggestions rather than delegating the task. That approach caps throughput at the engineer's available attention and forfeits the asynchronous advantage entirely.
Some tasks sit on a gradient between the two poles. An engineer might use a copilot to sketch an approach, then hand the implementation to a background agent once the scope is clear. The same engineer might kick off a cloud agent for a well-defined refactor while jumping into a local session for something more exploratory. This two-phase pattern, interactive to define and background to execute, is the correct routing for tasks that start context-heavy and become bounded as the work clarifies.
Why background agents only work when the environment matches the task
A background agent routed correctly but running in an inadequate environment will fail on tasks an interactive copilot would have completed. The environment is as important as the routing decision itself. Background agents need to install packages, run services, execute tests, and verify their own outputs. None of that is possible in a shared or constrained execution environment. The agent needs a real, isolated computer, not a sandboxed suggestion box.
Cloud agents run in remote infrastructure with isolation, and the isolation is what makes the agent's work safe to review before it touches anything that matters. It is also what prevents a failed run from affecting other work in progress. The agent's ability to verify its own work, by running the test suite and checking that the build passes, is what makes the pull-request output trustworthy enough to review efficiently. Without that capability, the engineer is still doing the verification manually, which defeats the purpose of delegation.
Persistent state is another requirement for longer tasks. If an agent needs to preserve context, cached dependencies, or intermediate results across a multi-step run, the environment has to maintain state, not reset between steps. The environment also determines what the agent can access, including credentials, internal services, and the dependency graph, which sets the ceiling on how complex a task the agent can handle autonomously.
Replicas runs each agent in its own isolated VM, configured with the team's dependencies and tooling. The result is an environment where agents can install packages, run services, drive a browser, and verify their own work, making the environment functionally equivalent to a local developer machine without the risks of a shared one. The architectural point stands independent of any particular platform: environment quality is a routing input, and a team that ignores it will misattribute failures to the agent or the task when the true failure is the execution substrate.
How the routing decision changes when work is delegated at the team level rather than individually
When background agents are integrated into the places where work is discussed, such as issue trackers, Slack, and Linear, the routing decision shifts from a private, per-engineer judgment to a shared, observable team practice. The workflow change is structural: instead of a developer privately delegating inside an IDE, the team collectively delegates from the place where work is assigned. The path shortens from bug report or meeting decision to an actionable pull request, and no individual engineer has to manage the delegation.
At team scale, the four task properties become a triage protocol. Issues filed with clear acceptance criteria route automatically to background agents. Anything flagged as exploratory or context-heavy stays in the interactive queue. Visibility is the structural advantage of team-level delegation. Cloud agents produce pull requests and issues the team can see, but local interactive sessions have no team visibility by default. Background agent work is auditable by default, and interactive work is not.
The integration surface determines how naturally this team-level routing operates. Replicas connects agent delegation to Slack, Linear, GitHub, and GitLab, so the trigger for a background agent run can come from wherever the team already discusses work, and the output, whether a pull request, a recording, or a reply, returns to the same channel without changing the team's existing workflow. The analytics dimension compounds this advantage. When every agent run is attributable by source, harness, model, and credential, teams can measure which task types agents complete reliably and which they fail on, turning routing intuition into data-backed policy over time.
The strongest objection to team-level delegation is that it creates a review bottleneck as agent output volume grows faster than human review capacity. The answer is that the review burden is structurally different. Inspecting a diff from an agent that ran its own tests is faster than reviewing code written line-by-line without self-verification. The bottleneck is real but manageable if the environment ensures agents verify their own work before returning it. The deeper fix is routing discipline: tasks that are ambiguous or high-stakes enough to require close human review belong in interactive mode, not in the background agent queue. Routing correctly keeps the review load on background agents proportionate to what a team can absorb.
Applying the framework: a routing guide for the tasks teams encounter most
The four task properties combine into a routing guide you can apply without relitigating the framework every time. The decision turns on four questions: How long will this take? Can the output be reviewed before it merges? Is the scope fully specifiable upfront? Will the approach change mid-run?
Route to a background agent when the task takes longer than a single focused work session, the output can be reviewed as a diff before it merges, the scope is fully specifiable in a prompt or issue, and no mid-run correction is expected. Test coverage expansion, dependency upgrades, lint and formatting passes, doc sync, mechanical refactors, and small well-scoped bug fixes all meet this bar. Route to an interactive copilot when the task is exploratory or ambiguous, the approach is discovered through iteration, the context lives in the engineer's current working memory, or mid-flight steering is expected after each response. Architecture exploration, debugging a novel production issue, writing domain-specific business logic, and reviewing or explaining unfamiliar code all belong in this category.
The two-phase pattern applies when a task starts ambiguous but becomes well-defined. Use an interactive copilot to clarify scope and approach, then hand the bounded implementation to a background agent. A team might run an exploratory session to resolve a design question, then kick off a cloud agent for the refactor once the design is settled. Background-agent platforms triggered from Slack, Linear, or GitHub that return pull requests for review make this routing framework practical at scale by embedding the routing decision into the workflow rather than making it ad hoc each time.
The harness question is secondary to the routing question. Claude Code, Codex, Cursor, and Opencode each support both interactive and background modes to varying degrees. Decide on the mode first, then the agent. Staying harness-agnostic preserves the ability to send the same category of task to whichever agent handles it best as models improve, rather than being locked into the routing patterns of a single tool.
What teams should measure to improve routing over time is straightforward. Track which task types background agents complete without rework, and track where interactive sessions produce faster results than delegated runs. That data reveals where the team's routing intuitions are wrong, and it converts a framework into a feedback loop.
