On-Call for Agents

On-Call for Agents is the operating practice for software that takes actions without being asked each time. It differs from operating a service in one respect that reorganises everything else: the incidents that matter here rarely show up as downtime.

Key takeaways

• Alert on behaviour, not on availability. Escalation rate, gate failure rate, entities touched per hour and plan revisions per run detect the incidents that a green uptime dashboard will not.
• Build three stop controls, not one: pause intake, drain, and hard stop. Only the third abandons live runs, and it should be the one you almost never use.
• The on-call engineer must be able to answer one question within a minute of being paged: what has this agent done to the world in the last hour. Build the view that answers it before you need it.
• Write runbooks from real incidents rather than from imagination, and record when each was last executed, because an untested runbook is trusted at the moment nobody can check it.
• Review a wrong autonomous action as a system defect with an owned action, in the blameless form, and feed the finding back into the gates, budgets and horizon measurements rather than into a prompt tweak.

Read this beside Chapter 9, whose budgets produce most of the automated stops, and Chapter 10, whose escalations arrive in the same rota. Chapter 11 supplies the baselines that make an alert threshold meaningful.

The dashboards are green. Latency is normal, error rates are flat, and the queue is draining at its usual pace.

Meanwhile an agent has spent the last ninety minutes applying a discount code to every order it processes, because a tool returned a default when it should have returned an error. Nothing is down. Everything is working. The incident is entirely invisible to the instrumentation the team already has.

Agent incidents do not look like service incidents

A service fails by becoming unavailable or slow, and decades of practice are built around detecting exactly that.

An agent fails by acting. It stays up, it responds promptly, it consumes normal resources, and it does the wrong thing at a steady rate. Every signal a service dashboard reports will be healthy while it happens.

That is why the signals have to be behavioural, and the four worth having on the first screen are these. Escalation rate, because a rise means the system is meeting conditions it cannot resolve. Gate failure rate by gate, from Chapter 5, because a specific gate failing more than usual localises the problem immediately. External entities touched per hour, from Chapter 9, because that is the damage rate. And plan revisions per run, from Chapter 3, which in my experience is the earliest indicator that runs are thrashing rather than progressing.

Two more are worth a second screen. Cost per completed task, which catches the expensive-and-still-succeeding failure mode, and the share of runs completing inside their expected duration bucket, which is the horizon from Chapter 11 turned into a live signal.

Thresholds come from your own baselines

An alert on an absolute number will either never fire or fire constantly, because nobody knows in advance what normal is for a workload this new.

Take the baselines from the horizon measurement. Each task family has a measured distribution of success rate, duration, cost and escalation frequency. An alert is then a departure from it. Escalation rate for this family is three times its weekly median, or entities touched this hour exceeds the 99th percentile of the last month.

Google's error budget framing is the right governing structure on top of that. State the reliability you intend for each task family, measure the gap, and let it decide whether the response is to page someone, to pause deployments of new agent behaviour, or to do nothing because the budget is intact.

Alert on the rate of change as well as the level. A gate failure rate that doubles in an hour is more informative than one that has been slightly elevated for a week, and the doubling usually corresponds to something specific and recent: a model version, a tool deployment, a provider change.

Three stop controls, with different costs

"Kill switch" is one phrase describing three different actions, and conflating them means the operator reaches for the wrong one under pressure.

Pause intake stops new runs from starting while letting existing runs finish. It is cheap, reversible, and the correct first response to almost any behavioural alarm. It should be available to anyone on call, without approval, in one action.

Drain stops new runs and holds existing ones at their next checkpoint, leaving them resumable. It is the right response when you suspect the behaviour is wrong but not harmful, because it preserves everything the investigation will need.

Hard stop terminates in-flight runs immediately. It is the only one that can leave work half done, so it is reserved for active damage, and it must still emit each run's record before exiting. A hard stop that loses the history removes the ability to find out what happened, which converts a bad hour into an unexplainable one.

Test all three on a schedule. The control that has never been exercised will be discovered to be broken during the incident that needed it, which is the same argument Chapter 6 makes about compensations.

The question on-call must answer in a minute

Every agent operation should be able to answer one question immediately: what has this system done to the world in the last hour.

Not what it processed. What it changed. Records modified, messages sent, payments moved, files published, tickets created, with counts and the ability to list them. Chapter 4's record of emitted effects with external references is what makes this possible, and this is the payoff for having insisted on it.

Build the view before you need it, because an operator assembling that answer from logs during an incident will take forty minutes and get it partly wrong. The view should filter by task family, by time window and by effect class, and it should be the first link in every page and every escalation.

There is a second question that follows immediately, and it needs the same preparation: which of those effects can be reversed, and how. Chapter 6 recorded a compensation or its absence per step, so this is a query rather than an investigation.

Runbooks written from incidents

An agent runbook is short and specific, and it earns its place only by having been used.

The set that covers most cases is small. How to pause a task family. How to drain and resume. How to list and reverse the effects of a run or a set of runs. How to force a run to escalate. How to roll back a prompt, tool or model version, which is the change most likely to have caused the behaviour.

Write each one during a real event rather than in advance: somebody who is not driving records what the driver actually does, including the wrong turns, and that becomes the document. Put a last-executed date at the top of every runbook, and treat a procedure that has not been run in six months as a hypothesis rather than as instructions.

One entry is specific to agents and worth calling out. The runbook for rolling back a model version needs to state what happens to in-flight runs whose recorded history was produced by the previous model, because resuming a run under a different model is a change of behaviour mid-task rather than a neutral operation.

Who carries the pager, and what they need

An agent rota has a staffing problem that a service rota does not. The person who can tell whether an action was wrong often needs domain knowledge rather than infrastructure knowledge, and those are usually different people.

Two-tier works better than one. An engineering on-call owns the stop controls, the infrastructure and the rollbacks, and can act within minutes on anything behavioural. A business owner per task family, named in advance, answers the question of whether a given action was correct, and is the recipient for the escalations in Chapter 10 that ask for a decision rather than a fix.

Write down which decisions each tier may take alone. The engineer may pause or drain any task family without asking. The business owner may authorise a compensation that contacts customers. Neither should be discovering the boundary at three in the morning.

The rota also needs one thing a service rota rarely does: a plan for the run that is paused and waiting on a human who never answered. Those accumulate quietly, and each one is work half done sitting in a resumable state, so make expired escalations a visible queue with an owner rather than a state nobody looks at.

Review the wrong action as a defect

The last practice is the one that compounds. A wrong autonomous action gets the same treatment as an outage: a blameless review whose output is an owned action with a date, in the form Google's postmortem practice describes.

Blameless here has an unusual target. There is no engineer to blame, and the temptation is to blame the model, which is the same evasion in a different costume. "The model hallucinated" ends the investigation exactly where it should start. The useful questions are which gate should have caught this, which budget should have bounded it, which tool made the wrong call easy, and which part of the plan artifact failed to declare the effect.

The April 2026 diagnostic work is the model for the analysis itself, attributing failures across more than 3,100 trajectories to identifiable steps and causes with a judge validated against human annotation. Your run histories support the same analysis at a smaller scale, and doing it consistently is what turns individual incidents into a defect list.

Then close the loop. Every review outcome should land in one of four places: a new or strengthened gate, a changed budget, a tool or description fix, or an addition to the task set used for the horizon measurement. A review that lands in a prompt tweak and nothing else has usually not found the defect. The Model Context Protocol's own principle that third-party tool descriptions are untrusted is a reminder here. Prompt-level fixes sit on the least controlled surface in the system.

Chapter summary

Agent incidents are wrong actions rather than outages, so a service dashboard stays green throughout. The signals that detect them are behavioural: escalation rate, gate failure rate by gate, external entities touched per hour, and plan revisions per run. Cost per completed task and the share of runs inside their expected duration bucket follow close behind. Thresholds come from the baselines measured in Chapter 11 rather than from absolute numbers, expressed as departures from a family's own distribution, governed by an error-budget policy, and watching rate of change as well as level. Build three stop controls rather than one. Pause intake is the cheap reversible first response, available to anyone on call. Drain holds runs resumable at their checkpoints. Hard stop is reserved for active damage and still emits each run's record. Exercise all three on a schedule. Make the one-minute question answerable by construction, being what this system has changed in the world in the last hour, listed by effect class with the reversal path attached, built as a view before it is needed. Keep a small set of runbooks written from real events, each carrying a last-executed date, including one for rolling back a model version that states what happens to in-flight runs. And review every wrong autonomous action as a system defect in blameless form, refusing the evasion of blaming the model, closing each review into a gate, a budget, a tool fix or the horizon task set.

That is the book. Its argument, in one line: an agent finishes long work when the architecture around it can notice a wrong step, return to the state before it, undo what escaped, and stop before the damage grows. None of that is a property of the model, all of it is yours to build, and the measurement in Chapter 11 is how you find out whether you built it well enough for the work you actually have.