freno-dev/marketing/approved/agent-parallel-tracking/copy.md

# How do you keep track of multiple coding agents?

> **Status: approved — sponsor fact-check passed 2026-11-05** (FRE-199 pair 2
> fact-check card, verdict: "Approve both — move to approved/"). Not published;
> a human places it on nook.freno.me from `approved/`. Internal target:
> Mon 2026-11-09, met four days early. This page never names a product of ours
> and never names a competitor.

The honest answer: not by watching them. Run three agents and the watching
already fails — the session you are not reading is the one that finished, or
the one sitting on a question, and both states look identical from the outside.
The fix is not more windows; it is giving each agent a way to announce its own
state, so checking becomes something that happens to you instead of something
you have to remember.

## Why attention is the limit

Parallel agents are cheap to start and expensive to supervise. Every running
session can stop and wait for you — a permission prompt, a question, a finished
turn — and from your side of the screen those are invisible until you go look.
Operators who run agents at scale keep describing the same wall in different
words. One practitioner running dozens of parallel threads a day put it as the
limit moving "from tokens to my attention"; another, asked how many sessions
they could run, got the answer from their own comment section: not compute —
you. A developer who ran agents unattended for a month summarised the failure
as silence: "the six hours of silence was the real problem, not the dialog
itself." And the most common collision is the simplest — two agents waiting on
you while you are deep in the third, and one of them idle so long you lost the
thread of what you asked it to do.

None of that is a speed problem. It is a visibility problem: *which* of your
agents needs you, and *how do you find out without touring every window?*

## What a per-agent signal actually is

A terminal coding agent has no shared dashboard by default — each session is
its own process, its own window. But its state changes are events, and events
can be wired outward. Claude Code documents the pieces:

- **Every state you care about fires an event.** `Stop` fires when Claude
  finishes responding — the end of a turn. `Notification` fires when Claude
  Code sends a notification, and the notification's type tells you which kind
  of waiting it is: a `permission_prompt`, an `idle_prompt`, `agent_needs_input`,
  or `agent_completed`. `SessionStart` and `SessionEnd` bracket the whole
  session.
- **The event names the session it came from.** Every hook payload carries a
  `session_id`, so one handler can serve every window and still know which
  agent fired.
- **A hook is just a command you choose.** The events are configured in the
  settings files and run whatever command you point them at — append to a log
  file, update a status line, send a desktop notification that names the
  project.
- **The status line can carry per-session state.** Claude Code's status line
  is a customizable bar driven by a script you write; it receives session data
  on every render, and the docs name "work across multiple sessions and need
  to distinguish them" as a reason it exists.

The pattern in all four: stop touring windows and make each agent's
running / waiting / finished state observable where you already are.

## What to check or do

1. **Name the states before naming the tools.** For your workflow the states
   are usually three — running, waiting on you, finished — and the expensive
   one is always "waiting on you". A tracking setup that cannot distinguish a
   permission wait from a completion will quietly hide the state that costs
   the most.
2. **Wire the waiting events first.** A `Notification` hook matched on
   `permission_prompt` and `agent_needs_input` catches the blocked cases; the
   payload's `session_id` lets one handler label each alert with the project
   it came from.
3. **Route completions separately.** `Stop` means the turn ended — not that
   the work was right, and not that nothing is blocked elsewhere. Treating
   "finished" and "needs you" as one notification is how a waiting agent gets
   buried under a pile of done messages.
4. **Make the state visible without switching windows.** A per-session status
   line, a log file the hook appends to, or a desktop notification that names
   the project all work — the test is whether you can answer "does anything
   need me?" without leaving the window you are in.
5. **Expect the ceiling to be yours.** Operators consistently find the
   bottleneck before the machines do. The number of agents you can run is the
   number whose waiting state reaches you reliably — not the number your
   terminal can host.

One next step: run two agents side by side and wire only their permission-wait
events to a notification that names the project. The first time the second
agent's prompt reaches you before you happen to check its window is the whole
argument.

---

## Fact-check table (not part of the page)

Every technical claim above, with its primary source. Claims about Claude
Code's behaviour come from its own documentation, re-read 2026-11-05.

| # | Claim in the page | Source |
|---|---|---|
| 1 | `Stop` fires when Claude finishes responding; `SessionStart`/`SessionEnd` are per-session events | Claude Code hooks reference — https://code.claude.com/docs/en/hooks (hook events table; "per session: SessionStart and SessionEnd; per turn: UserPromptSubmit, Stop, and StopFailure") |
| 2 | `Notification` fires when Claude Code sends a notification; matcher supports notification types including `permission_prompt`, `idle_prompt`, `agent_needs_input`, `agent_completed` | same hooks reference (matcher table: "Notification | notification type") |
| 3 | Every hook payload carries `session_id`, the current session identifier | same hooks reference (Common input fields: `session_id` — "Current session identifier") |
| 4 | Hooks are configured in the settings files and run a command of your choosing | same hooks reference (configuration and command-hook examples) |
| 5 | The status line is a customizable bar driven by a script, receives JSON session data, and the docs name "work across multiple sessions and need to distinguish them" as a use | Claude Code status line doc — https://code.claude.com/docs/en/statusline |
| 6 | "The limit moved from tokens to my attention" / "fifty a day add up to something I could feel by Friday" | r/ClaudeCode 1xh5cum (2026-10-27, "Four months of 50+ parallel agent threads a day"), logged in `drafts/listening.md` Scan 3. Practitioner's own account, not a measurement. |
| 7 | "How many sessions before you become the bottleneck" — the thread went to compute; the attention half stayed on the table | r/ClaudeCode 1xdjb2g (2026-10-23, 72 comments), logged in `drafts/listening.md` Scan 1. |
| 8 | "The six hours of silence was the real problem, not the dialog itself" | r/ClaudeCode 1xipsk0 (2026-10-29, "~40 Claude Code agents unattended for a month"), quoted by the OP in-thread, logged in `drafts/listening.md` Scan 2. |
| 9 | Two agents waiting while the human is in the third; idle so long the thread of the task was lost; "most of my idle time came from agents waiting on a permission prompt while I was in another window" | r/ClaudeAI 1xmzp2n (2026-11-03, "How do you keep track of multiple coding agents running in parallel?"), two independent commenters, logged in `drafts/listening.md` Scan 9. |
| 10 | "You're the bottleneck agents were meant to eliminate" — approvals routing through one person | r/ClaudeCode 1xk0ghj (2026-10-31, "multiple agents working on multiple projects"), commenter's words, logged in `drafts/listening.md` Scan 4. |

**Ban compliance:** no product of ours named · no competitor named (herdr,
tmux, dashboards: none named — the page answers generically) · no handles · no
superlatives · no benchmark numbers · no invented testimonials (anecdotes are
real threads, described without handles) · no price · no roadmap dates.