Synchronous or Background: Choosing How Agents Work

Synchronous versus background agent workflows is now a real work-design decision, because the major coding agents ship both modes side by side: Claude Code's agent view dispatches full sessions that run without an attached terminal, and Grok Build's Agent Dashboard puts every session on one screen to be stepped into only when input is needed. The question is no longer whether you can run agents unattended — it is which tasks should be.

The stakes are easy to misread in either direction. Send everything to the background and you trade steady context for a queue of large diffs reviewed cold, which the code-review literature suggests is where human defect-finding is least effective. Keep everything synchronous and you cap throughput at the speed of your own attention while the tooling for parallel dispatch sits unused.

This guide treats the choice as a tradeoff, not a verdict. It walks through what the two vendors actually ship, the independent evidence on diff size and review effectiveness — the strongest data this decision can borrow — and four selection criteria you can apply per task: reversibility, review cost at the plausible diff size, latency sensitivity, and how precisely done can be specified before dispatch.

The pitch for background agents is throughput: dispatch several focused sessions, close the laptop lid on none of them, and come back to completed branches. The pitch for synchronous work is fidelity: you watch the approach form, redirect early, and review in small increments while the intent is still fresh in your head. Both pitches are true. The cost of each is the other's benefit.

The background mode's hidden line item is the handback. A session that ran unattended for an hour returns its work as a finished artifact — a branch, a draft PR, a transcript — and the human reviewing it starts from zero context. There is no live narration of the reasoning that produced the diff unless you scroll back through the transcript after the fact. The synchronous mode's hidden line item is concurrency: one attended loop at a time, at the speed of your own attention.

What makes this worth a framework rather than a preference is that the two costs are not symmetric across tasks. A mechanical dependency bump loses almost nothing to a cold review; an ambiguous product change loses almost everything. The rest of this guide is about telling those apart before you dispatch, not after.

Claude Code's agent view — labelled a research preview at the time of writing — dispatches and monitors multiple full Claude Code sessions from one screen, each running without an attached terminal. You can start a background agent from the dashboard (claude agents), from a shell (claude --bg with a prompt), by moving the current session to the background (/bg), or by forking it (/fork) so a copy continues in the background while the original stays attached.

The monitoring model is built around states, not streams. Sessions group under “Needs input”, “Working”, and “Completed”, with one-line activity summaries generated by a smaller model. You peek at output without attaching, or attach for a full interactive session when something needs steering. Two documented behaviors matter most for the workflow decision:

• Blocked means blocked. Background sessions use the same permission model as interactive ones. A session waiting on a permission, sandbox, or MCP prompt moves under “Needs input” and waits until answered — it does not silently proceed. Fully unattended bypass requires an explicit flag plus an interactive disclaimer acceptance, and the docs describe that mode as “not suitable for unwatched sessions.”
• Isolation by default. Before editing files, background sessions move into isolated git worktrees, auto-commit and push branches on completion — never directly to main or master without explicit approval — and can open draft PRs. The review artifact is the PR or the transcript: this is the concrete mechanism behind reviewing a large diff cold.

Agent view is one point on a documented spectrum, not the whole story. The same docs position the interactive terminal for tight-loop work, the Agent SDK for custom orchestration, and routines — cloud-scheduled recurring runs that continue with your machine off — for unattended recurring work. Background agents are also distinct from subagents, the nested child sessions inside one conversation (default maximum nesting depth of three in the current docs, tunable). If the persistent-teammate end of that spectrum is the part you are weighing, we compared the two operating models in AI teammate vs AI agent: what delegation changes.

Grok Build's asynchronous story splits into two mechanisms that operate at different levels, and conflating them muddles the workflow decision. The first is background tasks at the shell-process level: dev servers, builds, and test suites can be explicitly backgrounded, or converted mid-run with a keystroke, and monitored from a dedicated tasks pane. For continuous log watching, the agent can attach a monitor to a script so each printed line becomes a notification — with a documented caution that monitors should remain selective, since every output line interrupts the conversation.

The second mechanism — the actual analogue to Claude Code's agent view — is the Agent Dashboard, launched in June 2026, which operates at the session level.

The documented mechanics rhyme closely with Claude Code's: sessions sort by state with anything waiting for input pulled to the top; approval prompts surface inline with keyboard answers; selecting a row peeks at the latest output without leaving the dashboard, and replies queue until an active session's current turn ends. Sessions can be grouped by working directory for multi-repo work, and closing the dashboard leaves every session running. One deliberate design choice stands out: subagents — Grok Build's independent child sessions, with read-only and plan-only built-in types alongside the general-purpose one — roll up under the parent session that launched them, so the dashboard shows dispatched work rather than the full fan-out beneath it.

Notably, Grok Build's documentation also describes reading a subset of Claude Code's managed settings for mixed-fleet interop, and its session picker resuming Claude Code, Codex, and Cursor sessions. At least one vendor, in other words, treats the sync-versus-background decision as portable across harnesses — a work-design question rather than a product-lock-in question, which is exactly how this guide treats it.

The strongest evidence this decision can borrow is not about AI at all. It is the code-review-effectiveness literature, and two independent bodies of it converge on the same shape: human review quality degrades as the amount reviewed in one sitting grows.

The first body is an older, oft-cited SmartBear/Cisco study of peer code review, as summarized on SmartBear's own best-practices page. Its recommendations are specific: review no more than 200–400 lines of code per sitting, and keep inspection pace under roughly 500 lines per hour — the study reports a significant drop in the density of defects found at faster rates.

The second body is Google's own published engineering practice — not a controlled experiment with an effect size, but the stated review culture of one of the largest codebases in the world, and independently written from the SmartBear lineage. Google's small-changelists guidance puts numbers on it: around 100 lines is usually a reasonable changelist, around 1,000 lines is usually too large, and context matters — “A 200-line change in one file might be okay, but spread across 50 files it would usually be too large.” Reviewers are explicitly empowered to reject a change for size alone.

The book-length treatment, Software Engineering at Google (chapter 9), adds cultural texture: “small” changes there are typically around 200 lines, and roughly 35% of changes at Google touch a single file — as a share of all changes, per the book's own account. Google also targets review feedback within about one business day, but that is a responsiveness norm, a different axis from size; keep the two separate when you borrow the numbers.

One distinction has to be stated plainly: every study and guideline above is about review of human-authored code. None of them measured AI-generated diffs. What connects them to this post's question is structural, and it is our own analysis: a background agent that runs unattended for longer produces a larger single diff at handback, and the human reviewing it is — structurally — doing exactly the kind of single large-changelist, long-sitting review that both Google's guidance and the SmartBear/Cisco data associate with lower defect-finding effectiveness. The literature does not prove the mapping; it prices the review shape the mapping produces.

Put the vendor mechanics next to the review evidence and a usable decision rule falls out. The four criteria below are our own synthesis — no vendor or study bundles them this way — but each one is anchored to something documented or measured above. Score a task on all four before dispatching it; a task that fails any one criterion leans synchronous, or needs splitting until it passes.

Two of the four deserve a second look because they are commonly misjudged. Reversibility is about the landing zone, not the tooling: Claude Code's worktree isolation controls where changes land, but it is neutral on how large the resulting diff is when you review it — an isolated 2,000-line branch is still a 2,000-line review. And review cost should be estimated at the diff size the task will plausibly produce, not the size you hope for. A task that will plausibly come back inside the 200–400-line sweet spot is a materially safer background candidate than one that will plausibly return 1,500 lines in one shot — independent of how good the agent is.

The vendors' own best-practice guidance for background dispatch reads like a checklist for the fourth criterion. Claude Code's documented advice: be specific and task-focused rather than open-ended; include concrete context — file paths, PR numbers, URLs; break large asks into several focused agents rather than one broad one; peek in the first minute to catch early permission prompts; and use plan mode for agents you intend to review, reserving auto-approval modes for trusted, well-scoped tasks. Writing that checkable definition of done is its own craft — the companion guide published alongside this one, defining done in agent prompts, goes deep on exactly that.

Applied to common task shapes, the criteria sort cleanly:

The other operational habit worth stealing is triage order. Review the background queue the way both dashboards sort it: blocked sessions first — they are wasting wall-clock time and quota — then completed ones while your memory of the dispatch is freshest. And if you are still deciding which work is safe to hand over at all, the ops-side companion, what to hand an AI teammate first, applies the same reversible-and-verifiable logic one level up from the code.

The trend worth reading is convergence. Google's Jules, the cloud-execution platforms in OpenAI's orbit, Cursor's automations, Claude Code's agent view, Grok Build's dashboard — every serious harness on that list now ships an unattended tier, and at least one vendor builds explicitly for mixed fleets. That tells you the async capability is table stakes; it does not tell you it is the right default. The interesting divergence is in the guardrails: state sorting, needs-input blocking, worktree isolation, and quota metering all exist because the vendors themselves are engineering around the same two failure modes — unattended sessions that guess and handbacks too large to review well. The product surfaces are, in effect, agreeing with the review literature.

Looking forward, we expect the review side to become the differentiator. Dispatch is largely solved — one keystroke, one prompt box. What is not solved is making a cold diff cheap to review: the transcript is the only narration, and nothing in either vendor's documentation reviewed for this guide shrinks the diff after the fact. Teams that thrive with background agents will be the ones that constrain diff size at dispatch time — scoping asks so the handback lands inside the review sweet spot — rather than the ones that dispatch the most sessions. For the product-by-product view of the async tier, see our guides to Google's Jules, OpenAI's Ona acquisition and long-running agents, and Cursor's always-on automations. And if you are designing this operating model for a real team — which tasks go where, who reviews what, how quota gets budgeted — that is precisely the kind of engagement our AI transformation practice runs.