Human Checkpoints & Agent Observability

Picture a team a few months into running several agents at once: on a Tuesday afternoon, four sessions are live — two on independent features, one running a database migration, one chasing a flaky test. The engineer who kicked them off treats this the way they treated one agent, then two: a handful of terminal tabs to glance at between other work. Mid-afternoon, the migration agent hits a schema conflict it cannot resolve on its own and stops, waiting for a decision. Nobody notices for a long while, because the tab that had been getting attention was the one printing the most interesting output, not the one that had gone quiet.

Nothing about that outcome required a bug or a bad engineer. It is what happens by default once the number of running agents exceeds the number of things a person can hold in continuous attention — a threshold that turns out to be much lower than teams assume when they scale from one agent to several. Volume VI has spent nine chapters on how multiple agents coordinate with each other. This chapter is about the much older and less glamorous question underneath all of it: once there is more happening than one person can watch closely, what does watching well actually mean?

Where the ceiling actually sits

The question of how many autonomous units one operator can supervise did not start with coding agents. Human-robot interaction research asked it two decades earlier, under the name fan-out: the number of robots a single operator can control effectively, bounded by each robot’s neglect tolerance — how long it can run safely without attention — against the interaction time each one demands when it does need a person. An agent that can run productively for ten minutes without input has a much higher safe fan-out than one that stalls every ninety seconds waiting on a decision. But even at generous neglect tolerance, the foundational answer from that literature was never “as many as you want” — it was a specific, boundable, and usually small number, set by the operator’s attention budget rather than the robots’ competence.

This Library has made a version of this argument twice already, at smaller scale. Checkpoint gates that ask for approval too often produce rubber-stamping, the point at which approval stops being a judgment and becomes a reflex triggered by the shape of the request. Security operations centers have the more severe version of the same collapse, studied directly under the name alert fatigue: when warnings arrive faster than an analyst can meaningfully evaluate them, true-positive detection falls regardless of skill, because the bottleneck was never competence — it was volume against a fixed budget of attention. A fleet of agents each producing its own trickle of things that might need a look is the same failure mode at one more layer of scale: instead of one session over-asking, several sessions under-asking in parallel, which adds up to the same overwhelmed attention budget by a quieter route.

The specific failure mode of periodic glancing — checking each of several terminals in turn, hoping to catch the one that needs you — is also worse than intuition suggests. It is a monitoring task for a rare event (an agent stopping and needing input), performed by scanning something visually repetitive and mostly uneventful, which is close to the textbook setup for the vigilance decrement: performance on sustained-attention tasks degrades over time, and the degradation is larger, not smaller, on cognitively simple and repetitive tasks than on demanding ones. Watching four quiet terminals for the one that changes is exactly that kind of task. And the act of checking is not free even when nothing is wrong: switching attention from one session to another while the first is mid-thought leaves attention residue behind, so the review you give the second session is measurably worse than the review you would have given it with a clean start. More concurrent sessions means more switches, and each switch taxes the next one.

From watching everything to watching what needs you

The fix is not a bigger monitor. It is the same move Google’s site reliability engineering practice made for paging decades before agents existed: reserve interruption for conditions that are urgent, actionable, and genuinely require a human, and let everything else live in a dashboard nobody has to watch continuously. Applied to a fleet of agents, this becomes a queue rather than a grid — a short, ranked list of exactly the sessions that are blocked, erroring, or waiting on a decision only a person can make, sorted by how long each one has been waiting. A session working normally does not belong in that list at all, no matter how many tool calls it has made; it belongs in an ambient status view a person can ignore.

Sorting by wait time rather than recency or alphabetical order is a small design choice that carries most of the value. The session that has been silently stuck the longest is the one accumulating the most cost from being ignored — a blocked migration losing an hour is worse than a blocked feature branch losing five minutes — and oldest-first is the ordering that gets a person to it first without requiring them to scan the whole list to notice. It is the same logic that makes support-ticket queues sort by age rather than by whichever ticket happened to update most recently: recency rewards whichever session is loudest, not whichever one needs a person most.

Fleet-level observability is not session-level observability, scaled

A second, easier-to-miss distinction is that fleet-wide visibility and single-session review are different instruments answering different questions, not the same view at a different zoom level. The fleet view answers “is the fleet healthy right now” — how many agents are running, how many need a person, what the aggregate spend looks like — and it should stay that shallow on purpose. The session view answers “what exactly did this agent do, and why” — the full trace of tool calls, diffs, and decisions behind one session’s current state — and it should only be opened for a session someone is actually about to act on.

Conflating the two recreates the original problem in a different shape. A dashboard that tries to show trace-level detail for every live session at once is the wall of terminals with better typography; a needs-attention queue that lets a person clear it without ever opening a session is rubber-stamping with an extra step. The fleet view’s job is to tell a person where to look next; the session view’s job is to give that person everything they need once they are there. Neither one should try to do the other’s job.

What still needs a person

The previous chapter covered judge panels — automated evaluation that can screen the bulk of routine decisions a fleet generates: diff-quality scoring, pass/fail test gates, policy compliance checks, the kind of review that is repetitive precisely because most instances of it really are routine. That automatable slice is real, and at fleet scale it matters more, not less, because it is what keeps the needs-attention queue short enough for the sort-by-wait-time logic to work. A queue that still contains every routine decision defeats its own purpose.

What is left after that screening is not nothing, and this Library will not pretend otherwise. Three kinds of decision resist automation even at fleet scale: genuinely novel situations a judge panel has no precedent for and will score with false confidence rather than useful uncertainty; decisions with consequences that cannot be undone — a production deploy, a force-push, a customer-facing change — where the cost of a wrong automated call is not symmetric with the cost of a wrong automated pass; and conflicts between two agents’ outputs that need a person to pick a direction, because averaging or auto-merging the disagreement produces something neither agent actually intended. None of these get smaller as fleet size grows. What changes is that a well-built queue makes sure the concentrated judgment a person still has to spend lands on these cases specifically, instead of being spread thin and evenly across every session whether it needed a person or not.

What to do on Monday

1. Stop watching a grid of live sessions and build a queue instead: only blocked, erroring, or awaiting-decision sessions belong in it, sorted by how long each has been waiting.
2. Write down the exact list of states that qualify as "needs a person" on your team. If the list is longer than three or four states, some of them are really ambient-glance states in disguise.
3. Keep the fleet-wide view aggregate only — status, cost, last activity. Route to a session’s full trace only once a person is actually about to act on it.
4. Push the routine, repeatable review — diff quality, test gates, policy checks — to the judge-panel pattern from the previous chapter, and audit weekly what it is screening so the escalation criteria do not quietly drift.
5. Protect what is left of the attention budget for the cases that actually need it: novel situations, irreversible actions, and conflicts between agents that a score cannot resolve.

None of this requires a bigger monitor or a more elaborate dashboard. It requires accepting that a person’s attention is the scarcest resource in a multi-agent system, not the model’s, and designing the observability layer around that constraint from the start rather than discovering it the afternoon a blocked session sits quietly for the better part of an hour.