The Agent-to-Human Handoff: What You Owe On-Call

Key Takeaways

• Medicine ran this experiment and published the numbers. A nine-hospital study of 10,740 admissions found that introducing a structured handoff bundle was associated with a 23% lower medical-error rate (24.5 to 18.8 per 100 admissions) and 30% fewer preventable adverse events (4.7 to 3.3 per 100 admissions). The intervention was a bundle: a mandatory format plus communication training, faculty development and a sustainability campaign. The format is the part that transfers to software.
• The format is five fields, and it transfers cleanly to incidents. I-PASS: Illness severity, Patient summary, Action list, Situation awareness and contingency plans, and Synthesis by receiver, where the receiver reads the plan back.
• The published handoffs are shift summaries, not investigation handoffs. PagerDuty ships an agent skill that formats an end-of-shift summary. Nobody we could find publishes a protocol for an agent handing an in-progress investigation to a human, with confidence, exclusions and a read-back.
• The field an agent almost never gives you is what it ruled out. Medicine has a name for this and treats it as diagnostic content, not filler. OpenRCA 2.0 shows why it matters: agents name a correct service 76.0% of the time but ground it in a verified causal path only 61.5% of the time, so what was excluded, and on what evidence, is the difference between a lead and a conclusion.
• A page has a hard budget and you should spend it on context, not volume. Google's SRE book: "Every page should be actionable," "If a page merely merits a robotic response, it shouldn't be a page," and "I can only react with a sense of urgency a few times a day before I become fatigued."
• Escalating is a feature, not a failure. Automation bias "cannot be prevented by training or instructions," so an agent that hands over a confident wrong answer damages more than one that admits it is stuck.
• Default autonomy is often looser than the marketing. Azure SRE Agent's overview says no change deploys without human sign-off, while its run-modes documentation shows incident response plans and scheduled tasks defaulting to Autonomous.

An agent-to-human handoff is the structured transfer of an in-progress investigation from an AI agent to the on-call engineer who now owns it: what is broken, what changed, what has been ruled out and on what evidence, how confident the agent is, and the first decision the human has to make. No vendor we could find publishes such a protocol. Medicine does, and it measured the outcome across nine hospitals.

This post borrows that structure, states clearly which parts are established practice and which are our synthesis, and ends with a handoff format you can implement against any agent.

Why borrow from medicine?

Because clinical handoff is the same problem with published outcome data, and software operations has no equivalent study.

The I-PASS study (Starmer et al., New England Journal of Medicine, November 2014) introduced a standardised handoff bundle across nine hospitals and measured 10,740 patient admissions before and after:

"The medical-error rate decreased by 23% from the preintervention period to the postintervention period (24.5 vs. 18.8 per 100 admissions, P<0.001), and the rate of preventable adverse events decreased by 30% (4.7 vs. 3.3 events per 100 admissions, P<0.001)."

What changed was not staffing or seniority. It was a mandatory handoff structure, taught and reinforced: the study describes "a mnemonic to standardize oral and written handoffs, handoff and communication training, a faculty development and observation program, and a sustainability campaign." AHRQ's patient-safety primer notes the related baseline finding that "being cared for by a covering resident was a risk factor for preventable adverse events," and that communication failures between providers are "a leading cause of preventable error" in closed malpractice claims.

The transfer to on-call is direct. A responder woken at 3am is a covering clinician: correct credentials, missing context, inheriting a situation mid-flight from someone, or something, that has been looking at it for a while.

One honest caveat: this is medicine, and we found no study transferring these protocols to software operations. The analogy is strong and the outcome data is real, but nobody has measured a 23% reduction in anything by restructuring incident handoffs. We are reasoning from adjacent evidence and saying so.

What is in I-PASS, and what is the SRE equivalent?

The five fields, per AHRQ, map onto an incident with almost no forcing.

I-PASS field	Clinical meaning	Incident equivalent
Illness severity	How sick, and how fast changing	Severity, user impact, trend
Patient summary	What is wrong and the story so far	Symptom, affected service, timeline
Action list	What to do next, by whom	The first decision and who owns it
Situation awareness and contingency plans	What might happen and the plan if it does	Blast radius, what to watch, the undo path
Synthesis by receiver	Receiver restates the plan	The responder confirms before the agent stands down

The fifth field is the one software will be tempted to skip, and it is the one doing the work. A read-back is what converts a broadcast into a transfer of ownership. An agent that posts a summary into Slack and considers the job done has not handed off; it has published.

SBAR, the other widely used protocol, is the compressed version: Situation, Background, Assessment, Recommendation. It is a reasonable shape for a page body where I-PASS is the shape for the full incident channel.

What do agents actually hand over today?

Summaries, mostly. The pattern across the category is a natural-language recap plus links, with the agent's confidence and its excluded hypotheses either absent or buried in a reasoning trace nobody reads at 3am.

The autonomy defaults are worth checking against the marketing, because they determine whether a handoff even happens. Azure SRE Agent documents two run modes: Review, where the "Agent proposes an action; you approve or deny," and Autonomous, where the "Agent executes immediately and reports what it did." The overview material states that no change deploys without human sign-off, while the run-modes documentation shows incident response plans and scheduled tasks defaulting to Autonomous, even though the same page calls Review the agent-level default and the fallback when no per-plan mode is set. Those two statements sit uneasily together, and the resolution matters: in Autonomous mode the handoff is a report after the fact, not a decision point.

Google's SRE organisation has published the most rigorous thinking here, and it is worth reading because they treat handoff as a property of the system rather than a UI concern. Their autonomy ladder runs L0 to L4, and the interesting mechanics are the transitions. Their agents downgrade themselves: "If an agent requests an L3 (High Automation) execution, but the agent detects an elevated risk score or an anomalous production state, it will automatically downgrade the request to L2 (Partial Automation), intercepting the execution and routing an approval request to a human SRE." That is an escalation trigger defined on system state rather than on model confidence, which sidesteps the calibration problem entirely.

They also specify what the agent must record, which is effectively the handoff payload: agents "must log their 'chain of thought', the signals used, the hypotheses considered, the reasons for choosing a particular action, and the confidence level." And their principles post adds the requirement that agents explain "what options were considered and rejected. In other words, we favor transparency over black-box automation."

Rejected options. That is the pertinent negative, and Google is the only major vendor we found asking for it explicitly.

When should an agent escalate instead of continuing?

This is the harder half of the problem, and the honest answer is that you cannot base it on the agent's own confidence.

Anthropic's research found that reasoning models frequently fail to verbalise what actually drove an answer: one model mentioned an influential hint 25% of the time, another 39%. If stated reasoning is unreliable, stated confidence inherits that unreliability. So "escalate when confidence is below 0.7" is a threshold on a number you cannot trust.

Better triggers, in rough order of how well they hold up:

1. System state, not self-assessment. Google's model: elevated risk score or anomalous production state forces a downgrade regardless of how sure the agent is.
2. Budget exhaustion. Steps, wall-clock time, or spend. An agent at its ceiling has demonstrably not converged. Aurora hard-stops at 240 graph steps, roughly 120 reasoning turns, and on the opt-in multi-agent path at 600 seconds per sub-agent and two synthesis waves.
3. A gated action. Anything mutating. Aurora denies structured writes with a BACKGROUND_DENIED code when no human is present rather than queuing them, unless the org has explicitly allowlisted that tool, which forces the escalation rather than deferring it.
4. Contradictory evidence. Two hypotheses with comparable support and no discriminating test available is a genuine judgment call, which is what humans are for.
5. Novelty. No similar prior incident and no matching runbook.

And the reason to escalate early rather than push through: Parasuraman and Manzey's review in Human Factors found that automation bias produces "both omission and commission errors when decision aids are imperfect," that it "occurs in both naive and expert participants, cannot be prevented by training or instructions," and that automation complacency "cannot be overcome with simple practice." A handed-over wrong conclusion is not neutral. It anchors a tired engineer, and their seniority will not save them from it.

So an agent that says "I could not determine this, here is what I eliminated" is more valuable than one that always produces an answer. This is why we treat it as a schema requirement rather than a prompt suggestion: Aurora rejects a sub-agent finding that lacks a "what I ruled out" section or a self-assessed strength from a fixed set, and a timed-out sub-agent returns an explicit inconclusive stub instead of silence.

The page itself has a budget

Whatever the agent knows, the page is the narrow aperture it has to fit through, and Google's SRE book is unusually direct about the constraint. From the monitoring chapter: "Every page should be actionable." And: "If a page merely merits a robotic response, it shouldn't be a page." And the human limit that most alerting configurations ignore: "I can only react with a sense of urgency a few times a day before I become fatigued."

Two consequences for agent design.

An agent should page less and say more. If it can page once with five fields instead of three times with fragments, it should. The budget is attention, not messages.

An agent that pages for something it could have resolved has spent a scarce resource for nothing. That is the same standard Google applies to robotic pages, and it is why the useful metric is not "how many incidents did the agent touch" but "how many pages did it avoid, and how good were the ones it sent."

Stripe's auto-remediation writeup (July 2026) is the benchmark for the avoidance half, and notably uses no LLM at all: state machines and invariants delivered "a 30% reduction in pager volume (~200 fewer pages a year)." Worth remembering before reaching for a model.

A handoff format you can implement

The mapping to I-PASS is established practice; the specific fields below are our synthesis of that structure plus the logging requirements Google publishes. Adapt freely.

INCIDENT HANDOFF
════════════════════════════════════════════════

SEVERITY     SEV-2 · checkout latency p99 4.2s (SLO 800ms)
             Degrading: 1.1s → 4.2s over 18 min

SUMMARY      payments-api p99 latency breach.
             Errors isolated to POST /charge.
             Downstream: 3 services degraded.

CHANGED      deploy payments-api v2.14.0, 22 min before onset
             (strongest temporal correlation)
             2 config changes in window, ruled out below

RULED OUT    ✗ Database saturation
               connections 34/200, no slow query log growth
             ✗ Upstream provider
               provider status green, egress latency flat
             ✗ Config change c-8821
               applied post-onset, cannot be causal

HYPOTHESIS   Connection-pool exhaustion introduced in v2.14.0
             CONFIDENCE: moderate
             NOT CONFIRMED: could not read pool metrics,
             exporter down since 03:12

BLAST RADIUS 3 services depend on payments-api
             checkout · order-history · reconciliation

FIRST CALL   Roll back v2.14.0, or fix forward?
             Undo path: kubectl rollout undo, ~90s
             Rollback destroys the pool state you'd need
             to confirm the mechanism.

EVIDENCE     14 tool calls, full timeline: [link]
             Cost: $2.41 · Duration: 6m 12s

CONFIRM      Ack to take ownership. Agent stands down.

Five deliberate choices in that layout.

RULED OUT sits above the hypothesis. It is the highest-value and most-omitted section, and putting it first signals that the agent did elimination rather than pattern-matching. Each exclusion carries the evidence that justified it, so you can disagree with any of them.

The hypothesis states what it could not check. "Exporter down since 03:12" is worth more than a confidence score, because it tells the responder exactly which gap to close first.

FIRST CALL is a question, not a recommendation. It names the tradeoff, including the one that is easy to miss under pressure: rolling back destroys the evidence needed to understand the failure. That is the decision, and it belongs to the human.

Cost is in the packet. It tells you whether the agent worked efficiently and whether something looped.

CONFIRM is the read-back. Without it, ownership is ambiguous and the fifth I-PASS field is missing, which is the field the clinical evidence suggests carries much of the benefit.

The part nobody has solved

Handing off a diagnosis is the easy half. Coordination is the hard half, and it is genuinely unsolved.

Lorin Hochstein made the sharpest version of this argument in February 2026, surveying the AI SRE category: "what none of these tools try to do, as far as I can tell, is incident management." His reasoning is the part worth sitting with:

"Incidents involve some sort of problem with the system as a whole, and because everybody in the organization only has partial knowledge of the whole system, we typically need to pool that knowledge together to make sense of what's actually happening right now in the system."

An agent can read every dashboard. It cannot know that the payments team shipped something unusual last Tuesday, that the provider had a similar issue nobody filed, or which staff engineer has seen this failure before. Google's SRE Workbook assigns that pooling to a human role, the Incident Commander, and nothing in the current tooling replaces it.

So the honest framing of an agent's job at handoff is narrow: arrive with evidence gathered, alternatives eliminated, and uncertainty stated, so the humans can spend their attention on the part that needs judgment and shared context. That is a real contribution. It is not incident management.

Where Aurora stands

Aurora produces most of this packet today, and it is worth being specific about which parts are structural rather than aspirational. Findings are schema-validated and rejected unless they include an explicit "what I ruled out" section plus a self-assessed strength from a fixed enum, so the RULED OUT block cannot silently go missing. Every tool call in an incident investigation is persisted with input, output (truncated), status and duration, and reconstructed as a per-incident timeline, which is the EVIDENCE line. Cost per investigation is tracked and surfaced. Gated writes are denied outright when no human is present, which is the escalation trigger in item 3 above. And a sub-agent that times out returns an inconclusive stub rather than nothing. One scoping caveat: the findings schema, the sub-agent timeout stub and the synthesis-wave cap belong to the multi-agent orchestrator, which is opt-in and off by default today, while the 240-step limit and the write gate apply on every path.

What Aurora does not do is enforce a read-back. There is no mechanism today that keeps an investigation open until a human explicitly acknowledges ownership, which by the clinical evidence is the field most associated with the benefit. That is a gap, we know it is a gap, and pretending otherwise would undercut the entire argument above.

Try the handoff yourself

Aurora is Apache 2.0, so the enforcement described above is something you can exercise rather than take on trust. Run it against your own incidents and read what the agent hands back:

git clone https://github.com/arvo-ai/aurora.git && cd aurora

make init                # generates secrets and local config
nano .env                # add OPENROUTER_API_KEY, OPENAI_API_KEY or ANTHROPIC_API_KEY
make prod-prebuilt       # pulls prebuilt images and starts

Open http://localhost:3000 and register; the first user becomes admin. Trigger an investigation and check the finding for the four things this post argues a handoff owes you: a summary, the evidence, the reasoning, and what it ruled out. A finding missing any of them does not get persisted.

The exclusions field is the one an agent skips unless something forces it, which is why it is validated rather than merely requested in a prompt. One scoping caveat from the section above: that validation belongs to the multi-agent orchestrator, which is opt-in and off by default.

• Start free: aurora-ai.net (hosted, no infrastructure to run)
• GitHub: github.com/Arvo-AI/aurora
• Related guides: SLOs for AI Agents · AI SRE Accuracy: What the Benchmarks Show · The SRE Incident Lifecycle · AI Agent Guardrails

Sourcing note. The I-PASS outcome figures come from the New England Journal of Medicine study via PubMed; the field definitions from AHRQ's patient-safety primer; paging guidance from Google's SRE book; autonomy mechanics from Google SRE and Microsoft Learn; automation bias from the peer-reviewed review in Human Factors. The handoff format is Arvo's synthesis of that material and is labelled as such. Verified July 28, 2026.