For most of the past two years, interacting with AI coding tools meant having one active conversation. You started a session, did some work, finished, and moved on. The mental model was conversation-shaped — one agent, one task, one thread. That model worked while the tools were fast assistants. It started breaking down once the tools became agentic operators that could run for tens of minutes on a single goal.

Claude Code's background sessions — launchable with claude --bg, visible alongside interactive sessions in the agent view, marked clearly as bg — formally end the one-conversation-at-a-time pattern. They turn a single engineer's workflow into a small fleet of parallel agents working on different problems simultaneously. That sounds like a workflow tweak. It is actually a meaningful change in what an individual engineer can produce in a day.

Why One-Agent-at-a-Time Was Always Going to Break

The single-session model was a holdover from chat interfaces. It made sense when AI responses were fast and the agent was passive. It made less sense as agents started doing real, long-running work.

Long-running tasks idle the engineer. A goal-directed agent working on a refactor for fifteen minutes leaves the engineer with two options — wait for the agent to finish, or context-switch to something else and lose the thread. Neither is good. The engineer is either underutilized or fragmented across too much in-flight work.

Many engineering tasks are parallelizable. A bug investigation in one service, a feature implementation in another, a documentation update on the side — these are independent threads of work that do not need each other's context. A single agent can only do one at a time. The engineer's actual problem set is wider.

Cognitive load piles up inside a single conversation. When one session is handling everything an engineer is doing, the session's context gets long, the agent's focus diffuses, and the relevant state for any specific task gets buried. The opposite — many short, focused sessions — produces better agent behavior at the cost of more interaction overhead.

Background sessions resolve the trade-off. The agent runs in parallel without occupying the engineer's attention. The engineer spawns work, checks in when results are ready, and stays in flow on whatever they are personally doing.

The Fleet Operator Mental Model

Operating multiple agents in parallel requires a different mental model than operating one. The engineers who adapt fastest treat themselves as fleet operators rather than conversation partners.

The unit of attention shifts from "current task" to "current fleet status." An engineer running five background sessions checks the agent view to see what is running, what is blocked, and what is done. Attention moves to the agent that needs human input rather than to whichever agent was most recent. The skill is triage, not focus.

The cost of starting a new agent goes down. When sessions can run in background, the friction of "should I bother delegating this to an agent?" drops. Tasks that would have been done manually because they were not worth a full conversation now get delegated. The throughput effect is cumulative across many small delegations.

Coordination becomes a primary skill. Spawning five agents to work on related changes requires thinking about whether they will conflict, what order their work should land in, and how to merge their outputs. The engineering skill that matters is coordination of parallel work, not execution of any single piece.

Where This Changes Daily Engineering Practice

The shift to fleet-operator workflow does not affect all engineering work equally. Some patterns benefit immediately; others require restructuring to take advantage.

Multi-repo changes. A change that touches three repositories used to require sequential context-switching between each one. With background sessions, an engineer can spawn an agent in each repo, coordinate the changes across them, and review the results in parallel. The end-to-end time on multi-repo work compresses substantially.

Investigation in parallel. When debugging a production issue, an engineer often has multiple hypotheses to test. Background sessions let each hypothesis get investigated in parallel rather than serially. The investigation finishes faster, and the engineer can prune dead-end hypotheses without spending equal time on each.

Build-and-verify cycles. While one background agent runs a long build or test suite, the engineer can have other agents working on the next set of changes. The natural waiting time inherent to engineering work gets reclaimed.

Documentation as a parallel stream. Writing documentation for a change you just shipped is exactly the kind of work that benefits from being delegated to a background agent. The agent can read the diff, draft the documentation, and produce a result while the engineer is moving on to the next problem.

Routine maintenance work. Dependency updates, lint cleanups, small refactors — the background of engineering work that always exists and rarely gets prioritized — can be delegated to background agents that handle them while the engineer focuses on higher-leverage work.

How to Use Background Sessions Without Losing the Plot

Running multiple agents in parallel is powerful and also creates new failure modes. The engineers who get this right do so deliberately.

Cap the active fleet. There is a limit to how many parallel agents a single engineer can productively supervise. The limit is usually lower than the technical ceiling — three to five active agents is a realistic working set for most engineers, beyond which review quality drops and surprises accumulate. Pick the cap deliberately and respect it.

Make each session goal-specific. Background sessions work best when each has a clear, contained goal. A vague "work on the API" session running in the background produces vague results. A specific "implement the /v2/users endpoint, run the contract tests, open a PR" session produces a reviewable artifact. Specificity matters more in background than in interactive sessions.

Schedule check-ins, do not interrupt yourself. The temptation is to keep checking the agent view to see if anything is done. Resist it. Schedule explicit check-ins — every thirty minutes, or when you finish your current task — and use the time between for focused work. Constant fleet checking defeats the productivity benefit.

Treat agent output as drafts, not final work. Background agents will produce work that needs review. The fleet pattern fails when engineers start trusting outputs without inspection because they have too much in-flight to review carefully. Every background session's output is a draft until it has been reviewed.

Build the rollback habit. Background agents make changes you did not personally watch. The first time a background agent's change goes wrong, you will need fast, clean rollback. Set up the branch hygiene, the commit discipline, and the revert workflow before you need them, not after.

The Strategic Pattern Inside the Feature

The single-engineer fleet model is going to be the new baseline for senior engineering productivity. Background sessions are the primitive that makes it tractable. The companies and individuals that adopt this pattern early will have an obvious productivity gap over those still operating one conversation at a time.

The deeper shift is what it implies about engineering roles. An engineer operating a fleet of agents is doing different work than an engineer typing code or even an engineer in a turn-by-turn conversation with one agent. The work is coordination, review, judgment, and goal-setting. The actual code production is increasingly delegated. That is a different job description, and the engineers who recognize it and develop the skills early will be the senior engineers of the next several years.

Background sessions look like a workflow feature in a release note. They are actually the small primitive that makes a different scale of individual engineering productivity possible. The engineers who pick them up now and develop the fleet operator discipline will produce work at a rate that surprises their peers and their managers. The engineers who keep operating in single-session mode will increasingly look like skilled craftspeople in a world that has industrialized around them. That gap will widen quickly.