# Is that background agent still alive?

**Liveness comes from `TaskOutput`, never from diffs or commits.**

A diff measures work product, not aliveness. An agent that has been reading code
for eight minutes looks identical to one that died eight minutes ago, and one
that committed once and then hung looks alive. `TaskOutput` reads the agent's
actual transcript, so a quiet-but-thinking agent shows tool calls advancing while
a hung one shows nothing new.

A background agent is in exactly one of three states:

- **running and progressing** — `TaskOutput` advances between two checks.
- **running but stalled** — `TaskOutput` is frozen across two checks a few
  minutes apart. `TaskStop` it and respawn.
- **finished** — the completion notification arrives on its own. Never poll for
  this; it comes to you.

Commits answer a fourth, orthogonal question — *how much of the task is done* —
and are never evidence for any of the other three.

## Backgrounding

`run_in_background: true` is the default. Spawn, keep working (or fan out more),
and collect results when they land. Independent work goes out in ONE message so
the agents run concurrently instead of in series.

**A foreground spawn freezes the whole session.** While it runs I
cannot talk to you, interrupt, or answer a question — you have made yourself
non-interactive. That is a real cost, not a neutral default. It's justified only
when you literally cannot proceed *or* ask anything useful until the result
lands, and even then, prefer backgrounding and continuing to converse.

## Routing

Which agent type to use, and why `general-purpose` is the last resort, is
enforced at tool time by chook (`~/misc/chook/chook.mjs`) from two directions: it
blocks after 4+ consecutive inline exploration calls, injecting the routing table
at the moment the grinding happens, and it denies the turn's first spawn that
picks a catch-all agent, injecting the same table at the moment an agent is being
chosen. There is deliberately no per-prompt reminder for this — the tool-time
triggers replaced it.

`general-purpose` is the last resort because picking it is the absence of a
routing decision. If the work can be written down it belongs to `routine-coder`
(any edit, however large) or `routine-explorer` (any read-only lookup); if it
needs judgment about what is relevant, `Explore`. And a task specific enough to
route is already specific enough to brief tightly, which is the same problem
below.

## Brief size

One deliverable per spawn, sized to finish in a few minutes: the files and
symbols it touches named, and an explicit done-condition — what to return, and
the command that proves it works. Then review the result and spawn the next
piece with what that one taught.

A brief with several chained phases produces a 20-30 minute agent whose later
phases build on earlier ones nobody reviewed, so a network drop or one wrong turn
early throws away the whole run. Splitting is not about writing *less* — a long
brief is usually a well-specified one. It is about how many deliverables ride on
a single uninterrupted run.

Enforced at tool time by chook (`~/misc/chook/chook.mjs`), which denies the
turn's first spawn carrying four or more numbered steps or two or more
sequencing phrases.

## Related

- Parallel *writing* agents need their own worktrees: `worktrees.md`.