The Human Handoff

Overview

The module closes on the exit path. Every design in it produces handoffs: confidence below threshold, a bound exhausted, a tier requiring confirmation, an action refused, a customer asking for a person.

Handoffs are almost always specified as trigger conditions and nothing else. That omission is why automation gets quietly abandoned by the teams meant to benefit from it.

The failure this prevents

A customer explains a problem across four messages. The system tries, reaches its limit, and announces that it is transferring them to a person.

The person receives a conversation identifier. They open it, see the transcript if they are lucky, and ask the customer to explain the problem — which the customer has now done twice. From the customer’s side, the automation made things worse: it cost them four messages and delivered them to the same queue they would have reached immediately.

From the support agent’s side it is worse still. They inherit a conversation of unknown state: they do not know what the system told the customer, what it checked, or whether it already did something. If it rescheduled a job and then handed off, the agent is about to make decisions on a system state that has silently changed.

What the person receives

The handoff is a package, and it has required contents:

graph LR
  T["Trigger<br/><i>bound, tier,<br/>confidence, request</i>"] --> P["<b>Handoff package</b><br/>conversation · sources<br/>conclusion + confidence<br/>actions taken · next step<br/>reason for handoff"]
  P --> H["Person"]
  H -->|"resolution captured"| E["Evaluation data"]
  H -->|"hand back"| P

  classDef trig fill:#5B8FB9,stroke:#4A7A9E,stroke-width:2px,color:#ffffff
  classDef pack fill:#E8A33D,stroke:#C4832A,stroke-width:2px,color:#ffffff
  classDef human fill:#7D9A4E,stroke:#5F7A38,stroke-width:2px,color:#ffffff
  classDef data fill:#7C7C7C,stroke:#5E5E5E,stroke-width:2px,color:#ffffff
  class T trig
  class P pack
  class H human
  class E data

The trigger is the least interesting part. The amber box is the deliverable, and the two return paths are what most designs omit entirely.

The conversation so far, verbatim, so nobody asks the customer to repeat themselves.

What the system concluded, and how confident it was. A stated confidence lets the person calibrate how much of the reasoning to re-check.

The sources it used. This is what makes the conclusion checkable in seconds rather than re-derivable in minutes — and if a stale document caused the problem, this is where it becomes visible.

Actions taken or attempted, with outcomes. Including partial sequences. An agent that rescheduled a job and then stalled must say so prominently, because the person is otherwise working from a stale mental model of the system state.

What it was about to do, if it stopped before acting. Often the single most useful line in the package: the person can approve it, amend it, or see immediately that it was wrong.

Why it handed off — which bound, which tier, which threshold, or which request. “The system gave up” and “this action requires approval” are different conversations, and the second one is not a failure at all.

Both directions

Two return paths, both routinely missing.

The person must be able to hand back. Having answered the hard part, they should be able to return the conversation for the routine remainder — closing the ticket, sending the summary, scheduling the follow-up. A one-way handoff turns every partial difficulty into a full human interaction, which is most of the deflection value gone.

The person’s resolution is the best evaluation data you will ever have. A human expert just produced the correct answer to a case the system could not handle, on real traffic. That pair — the case and the resolution — is precisely what Module 2’s golden set is made of, and Module 6 will build the practice around it. Capture it at the moment of resolution, because reconstructing it later is hopeless.

The system must also treat a human correction as authoritative. If a person overrides a conclusion, that is not a conflict to resolve; it is the answer.

This surface decides adoption

The handoff belongs to the team receiving it, not to engineering. They will judge the entire system by it, and their judgement determines whether the initiative succeeds in a way no accuracy metric captures.

Module 1 made this point about guardrails: controls tuned so aggressively that people route around the tool leave you with no controls and no adoption. Handoffs are the same mechanism. A tool that dumps bare conversations into a queue teaches a support team to distrust it, and a distrusted tool gets bypassed — after which the deflection numbers are measuring a system nobody uses.

Which makes the format a thing to design with the recipients rather than for them, and the review is cheap: show them three realistic handoff packages and ask what is missing.

Volume is a capacity question

Confirmations and handoffs together are a workload landing on a team with a fixed size.

Add them up: confirmation requests for gated actions, handoffs from exhausted bounds, handoffs below the confidence threshold, explicit requests for a person. If that total exceeds what the team can absorb, the design has failed on adoption rather than on safety — and the remedy is a design change, not an exhortation.

Time zones matter here too. A handoff is only as good as the coverage behind it, and a package arriving when the covering region is thin is a different product experience from one arriving mid-shift.

The package, and who owns it

Handoffs reach 45 agents across three time zones, and Grace Adeyemi’s team fears tooling imposed without consultation — which makes this artifact the one most likely to decide whether they cooperate.

The package contains the conversation verbatim; the retrieved sources with versions; the system’s conclusion and confidence; the plan it formed; any action taken, with its idempotency key and outcome; what it was about to do if it stopped short; and the handoff reason — one of confidence below threshold, bound exhausted, tier requires approval, action refused, or customer asked.

The distinction that matters to this team: a credit confirmation is not a failure handoff. It is the design working as Dev Raghunathan required, and the package should say so plainly — otherwise every approval request reads as the system falling over, and a team already worried about being handed a half-finished tool will conclude it is one.

Hand-back exists: an agent who resolves the hard part returns the conversation for the routine close.

Resolutions are captured as candidate golden-set entries, which is how the 300-question set grows without anyone being asked to invent test cases.

Volume: every credit is a confirmation, so the confirmation rate is the credit rate. Add bound exhaustions and low-confidence handoffs and compare the total against what 45 agents across three time zones can absorb alongside the tickets that never reach the system at all. If it does not fit, the gating thresholds change — that is a trade Grace and Dev make together, with the arithmetic in front of them.

Owner: Grace Adeyemi. The format is reviewed with her team before build, using three realistic examples. This is the Module 2 elicitation move spent where it has the most leverage: the person who fears imposition becomes the person who specified the thing.

Feeds the workbook

This is the human handoff protocol. The rubric requires it to address what the human receives, not just when the handoff triggers — so lead with the package contents and treat the triggers as a list at the end.

→ Twelve topics done. You know what the system may do on its own, and what it may not. — Module 6 — Running It in Production

Optional workbook: Exercise 5 turns this module into artifacts. The exercises build on each other, so work them in order or not at all.