What must an AI support handoff preserve?

A complete handoff ends in an owned queue

An AI support handoff is complete only when verified identity, conversation, evidence, attempted actions, tool results, unresolved work, and risk flags arrive in an owned queue.

A transfer event proves that routing ran. It does not prove that the receiving agent can continue the case. Picture a billing dispute handed from a virtual agent to a human rep who has to re-authenticate the customer, hunt down the receipt the customer already uploaded, repeat a refund call that already failed once, or discover a deadline the customer mentioned that nobody recorded: the process has changed channels while discarding the work already done.

That loss has an operational cost. Industry benchmarking reports that first call resolution is ¹ than for customers who remain outside an escalation queue. A handoff design should therefore be judged by what survives the boundary and who becomes accountable after it.

The failure taxonomy below defines the acceptance criteria. Each class corresponds to information that can be present before transfer and absent after it.

Claimed identity replaces verified identity

A name, email address, or account number identifies a claim. It does not establish that the claim was verified.

The handoff packet should carry a verification assertion containing the subject identifier, verification method class, completion time, permitted scope, expiry condition, and the system that performed the check. It should not carry passwords, one-time codes, security answers, or reusable credentials.

This distinction becomes mandatory when access to protected health information is involved. The HIPAA Security Rule requires covered entities to implement procedures verifying that a person or entity seeking access to electronic protected health information ².

If the assertion is missing, expired, or too narrow for the requested action, the receiving agent must reverify. The packet should say that explicitly. Treating an unverified identity as verified creates a security failure. Treating a valid verification as absent creates repetition and avoidable handling time.

A generated summary truncates the conversation record

A summary helps an agent scan the case. It cannot preserve every qualification, correction, refusal, disclosure, and change of intent in the conversation.

This is a live product boundary rather than a theoretical one. Genesys Cloud Virtual Agent ³. A system built around that summary alone can lose the raw exchange by design.

Preserve three conversation layers: the original transcript or recording reference, a normalized event stream with speaker and time metadata, and a derived summary. The summary should point into the source record through message identifiers or time offsets. An agent can then scan the summary and inspect the exact exchange behind a disputed statement.

The packet also needs the customer's channel, locale, consent state, and whether the customer was told they were interacting with AI. The EU AI Act generally requires natural persons to be ⁴. Losing that state can cause the next agent either to repeat a disclosure or to assume one occurred when it did not.

Evidence becomes an unsupported narrative

Evidence includes customer attachments, screenshots, order records, retrieved policy passages, call recordings, and system events used to reach a conclusion. Writing “customer supplied proof” in a summary does not preserve that evidence.

Each item should retain a stable identifier, source, capture time, media type, integrity marker where available, and access policy. The packet should state which claim the item supports. A link without provenance leaves the receiving agent unable to distinguish customer-supplied material from generated or internally retrieved content.

Access must travel with the reference. Copying restricted evidence into a broader queue solves availability by creating a disclosure problem. The same design principle described in How to preserve RAG access controls end to end applies here: retrieval must preserve the source policy through every downstream representation.

Attempted actions collapse into intentions

“Refund attempted” is ambiguous. The agent may have opened a form, submitted a request, received a rejection, or completed the refund and failed to record it.

Attempted actions should be append-only events. Each event needs the actor, requested operation, target, parameters safe to retain, start time, completion time, and correlation identifier. Corrections should add events rather than rewrite the earlier record.

Zendesk uses this pattern for ticket history. Its ticket audits are ⁵, with discrete events preserved inside each audit.

This history prevents the next agent from repeating side effects such as refunds, cancellations, or account changes. It also shows where execution stopped. A requested action and a completed action must remain separate states.

Tool results lose the state needed for recovery

An action record says what the system tried. A tool result says what the dependency returned. Combining them into prose removes the information needed to decide whether retrying is safe.

Preserve the tool name, operation, correlation identifier, response status, completion time, structured result reference, and retry classification. For a failed call, record whether the outcome is confirmed absent, confirmed applied, or unknown: a refund call that times out with no confirmation either way needs to reach the next agent as an open question, not as the paraphrase "refund processed," because resubmitting a refund that already went through creates a second problem instead of closing the first. Unknown outcomes require reconciliation before another state-changing call.

Tool inputs and outputs also need redaction rules. The receiving agent usually needs identifiers and result state, not every secret sent to a downstream service.

An agent that cannot establish whether an action completed needs a defined stopping path. Your AI agent needs a safe way to stop explains the control boundary: uncertain side effects should transfer to review rather than trigger autonomous retries.

Unresolved work disappears behind the summary

A case can have a clear conversation summary and still lack a usable next step.

Represent unresolved work as explicit items. Each item needs its current state, next action, dependency, blocking reason, due condition, and acceptance condition. Where responsibility is split, name the owner of each item rather than assigning the whole list to a team label.

This record distinguishes waiting from abandonment. “Awaiting customer document” requires a request, a deadline policy, and a continuation rule. “Engineering investigating” requires a linked issue and a return path. Without those fields, the receiving queue inherits a description of the past instead of executable work.

Risk flags arrive without basis or disappear entirely

Risk flags cover conditions that change how the case may be handled: suspected fraud, vulnerable-customer indicators, threats of harm, regulated data, legal escalation, authentication anomalies, and uncertain side effects.

A flag should contain its category, observed basis, source event, creation time, severity rule, and required handling path. Separate observations from model inferences. A model classification should never be rewritten as a confirmed fact merely because it crossed a queue boundary.

Flags also need acknowledgement. A vulnerable-customer flag raised because a caller mentioned a recent bereavement can survive transfer buried on page three of a transcript and still be operationally invisible if nobody surfaces it in the receiving agent's first view. Put active flags there, and record who accepted them.

The trace may later be reused for quality review or model evaluation. That secondary use needs separate controls, as described in How to govern AI agent traces used for evaluation.

A shared inbox provides location without ownership

Delivery and ownership are different states. A shared inbox can contain the complete packet while nobody is accountable for opening it.

An owned queue has a named operating team, assignment rule, acceptance event, service clock, capacity policy, and fallback when no eligible agent accepts the case. Ownership transfers only after the destination acknowledges the packet and passes its required-field checks.

Until that acknowledgement, the current process retains responsibility. This prevents a routing timeout, permission error, or malformed payload from creating an ownerless case.

Structured queue attributes can survive contact transfers. Amazon Connect, for example, ⁶. That mechanism is suitable for identifiers, ownership state, and flags. Large transcripts and evidence should remain referenced records rather than oversized attributes.

Common shortcuts move work to the receiving agent

A summary-only handoff is easy to display, but it discards disputed wording and source evidence. A transcript preserves the exchange in full, though it leaves the receiving agent to reconstruct state, actions, and open work from raw text.

Free-text case notes skip schema design entirely, which also means the system cannot reliably determine whether authentication survived, whether a refund completed, or whether an escalation deadline exists.

A shared inbox looks cheaper because it skips explicit acceptance logic, until the cost shows up as unclaimed work, duplicate handling, and manual triage.

Replaying tool calls sidesteps the work of transferring results, but it is unsafe for any operation whose outcome may already have been applied: the receiver needs the prior correlation identifier and outcome state before deciding to retry.

The workable design combines structured fields with source references. Narrative remains useful for orientation. It should never be the sole carrier of state that determines access, side effects, risk handling, or ownership.

Make packet acceptance part of the transfer transaction

Use this sequence as the implementation contract:

1. Define required records for each handoff reason. Identity, conversation, evidence, actions, results, open work, and risk flags must each be present, explicitly absent, or marked unavailable with a reason.

2. Capture records while the AI is working. Reconstructing them at transfer time invites omissions and forces the model to infer prior tool state from prose.

3. Assemble a packet under one stable case identifier. Store summaries as derived views, keep transcripts and evidence as governed references, and attach append-only action events.

4. Validate before routing. Check required fields, identity scope, destination permissions, uncertain side effects, active risks, and evidence accessibility. A failed check keeps responsibility with the current owner or moves the case to a defined exception queue.

5. Commit ownership only after acknowledgement. Record the destination, accepting agent or team, acceptance time, service clock, and fallback path.

6. Test with interrupted cases rather than clean demonstrations. Include expired verification, inaccessible evidence, partial tool failure, conflicting customer statements, active risk flags, and a destination with no available agent. The test passes when the receiver can continue without reconstructing hidden state.

Complete packets still fail under attention, retention, and capacity limits

Preserving the record does not guarantee that an agent or model will use it correctly. Long-context research found that retrieval performance is strongest when relevant information appears near the beginning or end, and ⁷. Put active risks, identity state, and unresolved work at the top of the receiving view. Keep the full record available for verification.

Retention also has opposing constraints. For deployers of high-risk AI systems, the EU AI Act sets a floor of ⁴, unless other applicable law provides otherwise. GDPR requires identifiable personal data to be kept ⁸. A single indefinite retention policy cannot satisfy both principles. Set retention by record class, purpose, jurisdiction, and system classification.

A valid packet cannot create queue capacity, repair incorrect source data, or make an inaccessible attachment useful. It also cannot turn a mistaken model inference into evidence. The receiving operation still needs staffing, permission management, and human review rules.

The transfer must therefore fail visibly when required state cannot be delivered or accepted. An explicit exception with a continuing owner is a controlled operational state. A successful routing event with missing context is not.