The problem in plain language
An AI-enabled workflow reaches a point where a human should take over. The escalation arrives, but the person receives only a short message, a ticket number or the latest model output. They then reopen systems, read conversation history, check customer records and repeat questions before they can act.
The automation has technically done its job: it recognised a case it should not handle and passed it on. But the human now carries the full cost of the case plus the cost of reconstructing what the agent already knew. In the worst version, the customer is asked the same questions twice and concludes that the automation achieved nothing.
What the buyer is actually trying to solve
The buyer is not merely trying to "add human-in-the-loop". They need a reliable transfer of work state: why the handoff happened, what the agent already knows, what actions were attempted, what constraints or approvals apply and what the human is expected to decide next.
Search language tends to be framed as escalation quality: "AI agent escalation to human", "chatbot handover context", "agent handoff summary", "customer repeats information after escalation". Each is a symptom of the same missing context contract.
Evidence and system mechanism
OpenAI's Agents SDK handoff documentation treats a handoff as an explicit transfer between agents and exposes controls for the information and history passed to the receiving agent. By default the receiving agent sees the previous conversation history; filters can change what it sees, and an optional feature compacts history into summaries. The documentation also distinguishes model-generated handoff metadata, such as a reason or priority, from application state and dependencies.
The SDK's context documentation sharpens that distinction: the local context object that holds application state is not sent to the model at all. Business data reaches the model, or a person, only if it is deliberately exposed.
That distinction matters operationally: the handoff payload, durable business state and conversation history are related but not interchangeable. A transcript is not a case record, and a model-written summary is not a verified statement of what happened in the systems.
NIST's AI Risk Management Framework treats AI risk management as a lifecycle activity organised around governing, mapping, measuring and managing risk. For action-capable workflows, a human escalation point should therefore be designed as part of the operating system, not as a generic fallback message.
An illustrative example
The following is hypothetical. A billing agent handles refund requests. Refunds above a threshold require approval. The agent escalates a case with the message "Customer requests refund; above limit; please review." The reviewer must find the account, locate the invoice, read the conversation to understand the complaint, check whether the agent already issued a partial credit and work out whether the customer was promised a timescale.
A better handoff package carries the account and invoice identifiers, the amount requested and the threshold breached, the customer's stated reason, any credit already applied with its transaction reference, what the customer has been told and the exact decision required: approve, reduce or decline. The reviewer can act in minutes and the customer is not contacted again for facts the business already holds.
Problem owner and why now
The process owner and automation owner jointly own the handoff. Urgency rises when agents begin handling customer, finance, service or operational work where a failed escalation can delay a transaction or cause the human to repeat work the automation was meant to remove. It rises again as volume grows, because the exception queue can expand faster than the automated path, a pattern described in human exception queues that grow faster than automated throughput.
Warning signs
Reviewers open three or more systems for every escalation. Customers repeat information after transfer. Escalations are bounced back to the agent or another team for missing details. Nobody can say, from the escalation alone, whether the agent already took an action.
Economic consequence
Poor handoffs consume skilled human time, increase handling time, create customer repetition and reduce the usable automation rate because exceptions remain expensive. Useful measures include time from escalation to human action, number of systems reopened, repeated customer questions and the share of escalations returned to the agent because context was incomplete.
The effect compounds. Escalated cases are, by definition, the harder ones, often handled by more senior staff. If each one starts with a reconstruction exercise, the automation may lower average handling cost on simple cases while raising it on the cases that matter most.
Root cause
The root cause is often that the automation was designed around agent capability rather than work continuity. Teams define when the agent should stop but not the minimum context contract required for the next actor to continue.
A second cause is relying on the conversation as the record. If the only evidence of what happened is the transcript, the handoff can only pass the transcript, or a summary of it. Durable state belongs in the business systems, where both the agent and the human can read it. The same principle applies to human-to-human transfers; see how to design a handoff that cannot depend on memory.
Practical intervention
- List the common reasons an agent hands work to a human.
- For each reason, define the minimum business context the recipient needs.
- Separate durable application state from conversational history and model-generated summaries.
- Include actions already attempted, relevant identifiers, risk or approval flags and the exact next decision.
- Route the handoff to a queue or role that can act on it, not a general inbox.
- Test handoffs with real operators and measure reconstruction time.
- Log handoff outcomes so recurring escalation causes can be improved upstream.
Trade-offs
More context is not always better. Passing the full history to every recipient is easy to build but slow to read, may expose data the recipient does not need and can bury the decision. Summaries are faster but can omit or distort facts, so key identifiers and attempted actions should come from system records rather than the model's wording. The design aim is a compact package with links back to authoritative records, tailored to each escalation reason.
Diagnostic questions
- Can the human understand why the agent stopped without reopening the entire history?
- Does the escalation include the business record and current work state?
- Are attempted actions and errors visible?
- Is the requested human decision explicit?
- Can handoff quality be measured?
- Which facts in the handoff come from systems, and which from the model?
What good looks like
The human receives a compact but sufficient work package and can continue from the point of escalation instead of starting the investigation again. Each escalation reason has a defined context template, the facts are drawn from durable records, the customer is not asked to repeat themselves and handoff outcomes feed back into improving the automation.
Where Mellorca fits
Mellorca can map agent-to-human workflows, define context and escalation contracts, integrate durable system state, instrument handoff outcomes and redesign high-cost exception paths.
Method note
This article describes an operating-design pattern rather than a benchmark. Required handoff context depends on the process, risk, data sensitivity and systems involved. The OpenAI Agents SDK is used as one current example of handoff mechanics; the example scenario is illustrative, not a client case.
Sources and further reading
- Handoffs - OpenAI Agents SDK (last verified 10 October 2026)
- Context management - OpenAI Agents SDK (last verified 10 October 2026)
- AI Risk Management Framework (last verified 10 October 2026)