Which agent is waiting on you? Triaging a stalled fleet

Run one AI coding agent and you watch it. Run six and you watch whichever one you last clicked. The other five are in one of three states — working, finished, or stuck waiting for you — and from the outside those look identical: a window with text in it.

The third state is the one that costs money. An agent that asked "should I also update the tests?" at 10:12 and got no reply has been burning wall-clock, not tokens, for as long as you've been looking elsewhere. Across a fleet, idle-waiting is almost always the largest single source of lost throughput, and it's invisible by construction.

Why it's hard to see

A terminal doesn't announce state changes. The pane looks the same whether the agent is mid-tool-call or has been parked on a prompt for an hour. Three things make it worse at scale:

• Scrollback hides the ask. The question was printed, then more output followed, and now it's off-screen.
• Everything looks busy. Long agent runs produce output in bursts. Silence and "thinking" are indistinguishable from a glance.
• Polling doesn't scale. Checking six panes every few minutes is the context-switching cost you were trying to avoid by parallelizing.

You need the sessions to tell you, rather than you asking them.

Make the agent raise its hand

Claude Code supports hooks — shell commands the harness runs at defined lifecycle points, configured in settings.json. The two that matter here are Notification (fired when the agent needs your attention, including permission prompts) and Stop (fired when it finishes a response).

A minimal setup that makes a waiting agent audible on macOS:

{
  "hooks": {
    "Notification": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "osascript -e 'display notification \"needs input\" with title \"Agent\" sound name \"Ping\"'"
          }
        ]
      }
    ]
  }
}

That single change converts the problem from "scan six windows" to "respond when something pings." It's the highest-leverage five minutes available to anyone running more than two sessions.

Two refinements are worth adding once it works:

Include which session it is. A ping that doesn't say who still leaves you hunting. Hooks receive JSON on stdin and run with the session's working directory, so the folder name is a serviceable identity:

#!/usr/bin/env bash
# ~/bin/agent-notify.sh
name=$(basename "$PWD")
osascript -e "display notification \"$name needs input\" with title \"Agent\" sound name \"Ping\""

Point the hook at that script instead of the inline osascript. Now the notification names the project.

Distinguish "waiting" from "done". Wire Stop to a different sound. Waiting is urgent — it blocks progress. Done is not — it just means there's review work queued. If both make the same noise you'll start ignoring both, which returns you to where you started.

Triage when several ping at once

Notifications solve detection. They don't solve order. When three sessions want you simultaneously, work them in this order:

1. Blocked-and-cheap first. Anything answerable in one word — a permission prompt, a yes/no — clear it immediately. It's the smallest input with the largest unblocking effect, and every second it waits is a second that session is doing nothing.
2. Blocked-and-ambiguous second. "Should I refactor this while I'm here?" needs a real decision. Handle it before review work, because it's still blocking.
3. Finished work last. A completed agent is idle but not stuck. Its diff will still be there in ten minutes, and reviewing well takes actual attention you shouldn't spend while other sessions are frozen.

The instinct is to review the finished work first because it feels like progress. It isn't — it's the only item on the list that doesn't unblock anything.

Prevention beats detection

The best version of this problem is the one that doesn't happen. Two habits cut the number of interruptions substantially:

Pre-answer the predictable questions. Most "may I?" prompts are the same handful every time: run the test suite, install a dependency, create a file. Granting those up front in your permission settings — deliberately, at a scope you're comfortable with — removes a whole class of stalls. Keep anything destructive or outward-facing (pushes, deploys, deletions) on the ask list.

Give the task an escape hatch. A prompt that ends with "if a decision is genuinely ambiguous, choose the smaller change, note the assumption, and continue" converts a hard stop into a note you read later. That trade — slightly more review, far less idle time — is almost always worth it across a fleet.

Where a dashboard earns its keep

Hooks tell you that something needs you. They don't give you a standing picture of the whole fleet: six sessions, which are running, which are parked, which finished twenty minutes ago. That picture is what turns a fleet from a set of windows you cycle through into something you can actually manage.

That's the layer Agent Tile is built around — every session as a labeled tile with its project and folder visible at once, so "who's waiting" is a look rather than a search. But start with the notification hook regardless of tooling. Ten lines of config recovers more hours per week than any amount of faster typing.