Handing Control Back to a Human

Handing Control Back to a Human is the path every other mechanism in this book eventually leads to. Gates fail, compensations fail, budgets are reached, and at that point the system's quality is decided by how well it can explain itself to somebody who was not watching.

Key takeaways

• Escalation is a designed path with a payload, a named recipient, a deadline and a default action, not an exception thrown where the code ran out of options.
• The payload has five parts: what the run was doing, what it decided and why, what has already reached the world, what it proposes next, and the specific question being asked.
• Hold the run resumable while a human decides. A run that terminates on escalation forces the person to redo the work before they can act on it.
• Ask for decisions, not for approvals. A request to approve invites a reflex; a request to choose between two named consequences invites attention.
• Approval fatigue is the design constraint. Escalate rarely, escalate specifically, and measure the rate at which humans agree with the agent, because a rate near 100% means the gate is theatre.

Read this beside Chapter 9, whose ceilings trigger most escalations, and Chapter 6, whose failed compensations produce the hardest ones. Chapter 12 puts the same machinery on a rota.

At two in the morning a message arrives in a shared channel. It says that an agent run has failed and includes a stack trace and a run identifier.

The person on call does not know what the run was for, what it had already done, or whether anything is currently wrong in production. They will spend forty minutes finding out, and the first thing they will want is the thing the message did not contain.

Escalation is a path, not an exception

In most agent systems, handing off to a human is what happens when nothing else works. The code path is short, it is written last, and it carries whatever context happened to be in scope.

Treat it instead as a first-class outcome of the run, designed alongside success. That means it has a schema, a routing rule, a service level, and a test. It also means the plan artifact from Chapter 3 names, per step, who receives an escalation about that step, because the right person for a payment failure is rarely the right person for a data-quality question.

Anthropic's December 2024 guidance touches this from the design end, noting that agents require extensive testing in sandboxed environments and appropriate guardrails. The escalation path is a guardrail, and it is the only one whose quality is measured in how quickly a human can act.

The Model Context Protocol makes the adjacent requirement explicit for tool invocation: hosts must obtain explicit user consent before invoking a tool, and users should understand what a tool does before authorising it. Consent is only meaningful when the request is legible, which is the whole subject of the next section.

The five parts of a usable handoff

A handoff message is a small artifact with a fixed shape. The shape matters more than the prose.

What the run was doing: the task, the step, and the plan version, in one sentence that assumes no prior knowledge. What it decided and why: the judgement that led here, with the evidence it used, so a human can check the reasoning rather than repeat it. What has already reached the world: every emitted effect with its external reference, from the record in Chapter 4, because this is what determines urgency. What it proposes next: a concrete action, not a description of the problem. And the question: what specifically is being asked, with the options and their consequences.

The third part is the one that turns a forty-minute investigation into a two-minute decision. A person reading that three emails were sent, to these addresses, at this time, with this content, knows immediately whether this is an incident or a question.

One discipline about length. The message should be readable on a phone in under a minute, with the full record one link away. Escalations that arrive as a wall of context get skimmed, and skimming is how the wrong option gets chosen confidently.

Keep the run alive while the human thinks

An escalation that kills the run makes the human's job strictly harder.

The correct behaviour is a pause: stop dispatching new steps, complete or compensate anything in flight per Chapter 6, checkpoint, and hold. The run is now a durable object waiting on an input, which is exactly what the durable execution model from Chapter 7 supports, since a workflow can wait for an external signal for as long as necessary without holding a process open.

Holding state open has a cost, so bound it. Give every escalation a deadline and a default action, chosen so that the default is the safe branch rather than the convenient one. For most decisions the safe default is to abandon the remaining work and leave what has been done in a stable state, which is not the same as rolling everything back and should be decided per task rather than globally.

Two further behaviours are worth specifying. Re-verify preconditions on resume, because the world moved while the human was deciding and a plan snapshot from four hours ago may no longer hold. And record the human's decision in the run history as an event with its author, since Chapter 12's postmortems depend on knowing who decided what and when.

Ask for a decision, not for an approval

The wording of the question shapes the quality of the answer more than any other factor in this chapter.

"Approve this action?" invites a reflex, and the reflex is yes, because the system has been right the last forty times. "This will send a correction to 412 customers who were charged twice. Sending now corrects the error and reveals it. Waiting until Monday allows the bank reversal to land first. Which?" invites a decision, because it names two futures and makes the reader choose between them.

Three properties make the difference. Name the consequence of each option, in the units the reader cares about. Include the option to do nothing where it exists, with its consequence, since an implied binary hides the third choice. And show the uncertainty honestly: if the agent is unsure whether 412 is the right number, say the count is approximate and why, rather than presenting a precise number the reader will treat as verified.

This is also where the agent's own confidence should be reported as evidence rather than as a score. A statement that the pricing table was read twice with different results is useful. A confidence of 0.72 is not, because nobody knows what it is a probability of.

Approval fatigue is the constraint

Human review is a scarce resource that degrades under load, and every escalation you add spends some of it.

Two failure modes bracket the design. Too many escalations produce rubber-stamping, where the reviewer approves without reading, which is worse than no review because it manufactures a false record of oversight. Too few produce the unattended wrong action this whole book is about.

Three measurements keep the balance visible. The escalation rate per hundred runs. The agreement rate, meaning how often the human chose what the agent proposed. And the time to decision. An agreement rate close to 100% means the escalation is not being read or is not needed, and both of those are findings. An agreement rate near 50% means the agent's proposals add no information, and the step should probably not be automated yet.

There is a design lever that reduces escalation volume without reducing safety. Escalate per batch rather than per item, as Chapter 9's batching makes possible, and group related decisions into one message. One review of ten records is a better use of attention than ten reviews of one, and it produces a more consistent decision.

Where the escalation lands

A well-written handoff sent to the wrong place is an unread message. Routing is part of the design, and it has three components.

The recipient. Not a channel, a role, with an on-call rotation behind it. A message addressed to everyone is addressed to nobody, and shared channels at two in the morning are where escalations go to be seen by four people who each assume another is handling it.

The medium, chosen by urgency rather than by convenience. A decision that blocks a run for four hours can be an email or a ticket. A blast-radius stop needs a page. The mapping from escalation class to medium belongs in the plan artifact, decided once, rather than being improvised by whoever wired the notification.

The acknowledgement. The escalation is not delivered until somebody has claimed it, which means the system needs to know the difference between sent and accepted, and needs a second route when acceptance does not arrive inside the deadline. Without that, a paused run waits on a person who is asleep, and the default action fires having never been considered by anyone.

One more property is worth building early. Every escalation carries a link that opens the full run record with the relevant step selected. The reader should reach the evidence in one action, because the alternative is a search through logs at the moment attention is most expensive.

When the human is the wrong answer

Not every failure should reach a person, and routing everything to a human is its own kind of design failure.

Three cases resolve without escalation. Transport failures, which retry per Chapter 7. Failures where the compensation succeeded and the run can continue on a different branch, which need a log entry rather than a decision. And failures whose correct response is defined in advance, such as a budget ceiling with a stated default action, where waking someone adds latency and no information.

What must always reach a person is narrower and firmer: a failed compensation, an irreversible effect emitted incorrectly, a blast-radius ceiling reached in its absolute form, and any case where the agent cannot describe its own state. The last one is the most important and the least implemented. An agent that cannot say what it did is in the condition the 2026 reliability work calls meltdown, and continuing from there is how a bad run becomes an incident.

Chapter summary

Escalation is a designed path with a schema, a named recipient per step, a deadline and a default action, rather than an exception written last and carrying whatever was in scope. Its payload has five parts: what the run was doing, what it decided and why, what has already reached the world with external references attached, what it proposes next, and the specific question with its options. The third part is what converts a long investigation into a short decision. Keep the run resumable while the human decides. Use the durable execution model to wait on a signal rather than holding a process. Bound the wait with a deadline whose default is the safe branch, re-verify preconditions on resume because the world moved, and record the decision and its author in the history. Ask for a decision rather than an approval, naming the consequence of each option in the reader's units, including the do-nothing option, and reporting uncertainty as evidence rather than as a score nobody can interpret. Design against approval fatigue, which is the binding constraint, measuring escalation rate, agreement rate and time to decision, and reading an agreement rate near 100% as evidence that the review is theatre. Batch escalations so one review covers ten records rather than ten reviews covering one. Route to a role with a rota rather than to a channel, choose the medium by urgency, require acknowledgement with a second route when it does not arrive, and link straight to the run record at the relevant step. And keep humans out of the cases that resolve themselves, while guaranteeing that a failed compensation, a wrongly emitted irreversible effect, an absolute blast-radius stop, or an agent that cannot describe its own state always reaches a person.

The architecture is now complete: decomposition, checkpoints, gates, compensation, durability, tools, budgets and escalation. What remains is knowing whether it works for your workload. Chapter 11 is Measuring a Reliability Horizon for Your Own Workload, which builds the curve from Chapter 1 out of your own runs, so that every decision in this book can be priced against a number you measured rather than one you inherited.