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
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.