Watching the Work

You dispatched five background agents and went to make coffee. Which one is blocked on a question right now — and how would you know without opening five transcripts?

Why this, for you: the moment you run more than one agent at a time, your bottleneck stops being writing and becomes watching. A blocked agent emits no tokens, so it is invisible until you go looking. This lesson gives you two surfaces — agent view and the Monitor tool — that turn polling N sessions into an O(1) glance.

Last lesson you learned to fan work out to sub-agents and teams. Fan-out creates a new problem: operator attention is a serial resource, and parallel async agents create two coordination problems a chat panel cannot solve. Watching the work is how you stay the orchestrator instead of flying blind.

1 Agent view: one screen, grouped by what needs you

claude agents opens a full-terminal list of every background session, grouped not alphabetically but by the attention each one needs: Pinned → Ready for review → Needs input → Working → Completed. A dispatch input sits at the bottom; a peek panel (Space) shows the most recent output for the selected row.

The state vocabulary is the load-bearing design choice. Without Needs input as a first-class state, a parallel-session screen collapses to "running vs done" — and you are back to scanning transcripts to find the one row that is blocked on you.

Each row carries a Haiku-generated one-line summary, refreshed at most every 15 seconds, so polling tells you what a session is doing without opening its transcript. The six states:

State	Signal	Meaning
Working	Animated	Tools running or response generating
Needs input	Yellow	Waiting on a question or permission decision
Idle	Dimmed	Nothing to do; ready for the next prompt
Completed	Green	Task finished successfully
Failed	Red	Task ended with an error
Stopped	Grey	Stopped with Ctrl+X or claude stop

The signal even escapes the window: the terminal tab title reflects the blocked count (2 awaiting input · claude agents), so you catch it from another tab.

2 Attach, answer, detach — stay the orchestrator

When a row turns yellow, you do not need to abandon your post. From the list: Space peeks the exact question, Tab fills a suggested reply, Enter sends it — all without leaving. Only when real judgment is required do you attach (Enter or →): the session takes over the terminal as if you had run claude there, with a recap of what happened while you were away.

← on an empty prompt detaches back to the list — and detaching never stops a session. A session ends only on /stop, Ctrl+X twice, or claude stop <id>. Drop into one full conversation, resolve it, then back out. That attach-and-return loop is what keeps you supervising instead of babysitting.

The surface buys attention, not budget

Background sessions consume subscription quota exactly like interactive ones — running ten agents in parallel uses quota roughly ten times as fast as running one. Agent view shows you what is running; it does not curb the cost of running it. And above ~10–20 concurrent rows a flat list stops scaling — push to an issue-tracker substrate instead.

3 The Monitor tool: push beats poll

Agent view watches sessions. The Monitor tool watches a single long-running process. Before Monitor, watching a background job meant Bash(run_in_background: true) and manually calling Read on its output file to check progress — a polling loop. Monitor inverts that: it streams each stdout line to Claude as a notification, and Claude reacts mid-conversation without you asking again.

# No special syntax — just ask in natural language Run `docker compose up --build` in the background and monitor its output. Flag any line containing "error" or "failed" immediately, and tell me when all services report "healthy". # Claude writes the watch script, runs it, interjects only on a matching event

Use Monitor when the process already emits events and you want zero-latency reactions; use scheduled polling (CronCreate / /loop) when you want a fresh check on a timer. But push has sharp edges:

Gotcha	What bites	Fix
Chatty processes	Every stdout line is a notification; a verbose runner floods context	Monitor auto-stops a flooding watch; restart with a `grep` filter
Pipe buffering	Block buffering holds output until a ~4 KB chunk fills — delays of minutes	Use `grep --line-buffered`
Silent failure	Monitor forwards stdout only; stderr and exit codes are invisible	Use `Bash` with captured output where failure is silent

Match the filter to every terminal state

When you watch a job for a result, the filter must match both success and failure signals. Match only "healthy" and a failed run produces silence — which Claude reads as "still running." And remember monitors are session-scoped: they die when the session exits. For work that must outlive the conversation, use an external supervisor.

↪ Your win: steer the run, don't fly blind

Open claude agents — one screen, grouped by the attention each session needs, not by name.
Hunt the yellow row — Needs input makes blocked-on-input a first-class signal, O(1) not O(N transcripts).
Attach, answer, ← back — detaching never stops a session; only /stop or claude stop ends it.
Reach for Monitor when a process emits events — it pushes each stdout line instead of making the agent poll a file.
Filter both outcomes, buffer your pipes — match success and failure, and use grep --line-buffered.

Retrieval practice — recall, don't peek

Question 1Agent view groups background sessions primarily by…

Question 2The state that makes blocked-on-input a first-class signal is…

Question 3Pressing ← on an empty prompt in agent view…

Question 4The Monitor tool differs from Bash(run_in_background) because it…

Question 5 · spaced recall from an earlier lessonYou delegate bounded work to sub-agents mainly to…

Ask me anything. Want a Monitor prompt for your own deploy log, or a walkthrough of attaching to a blocked row without losing your place? Next in Part 1: Hooks & the Lifecycle — making behavior deterministic by enforcing and auto-fixing at PreToolUse and PostToolUse, instead of asking nicely.