Handoff starts with a trigger
A human should take over when the customer asks for one, confidence is too low, the request is outside policy, sensitive judgment is needed, or a supported action cannot be completed safely.
These triggers should live in code and operating policy where appropriate, not only in a model prompt.
- Explicit request for a person
- Low-confidence or unsupported answer
- Policy exception or suspected fraud
- Sensitive or high-impact decision
- Failed tool or provider path
Transfer the state, not just the transcript
A useful handoff includes the customer’s goal, verified identity state, sources already checked, actions attempted, promises made and the reason for escalation.
Secrets, unnecessary personal data and unsupported guesses do not belong in the summary.
- Goal and urgency
- Safe customer and order references
- Evidence and attempted actions
- Clear destination and reason
Waiting is not assigned
If nobody is eligible, the work is waiting in a queue. That is a valid operational state, but it is not a successful assignment to a person.
The customer and operator interface should use language that matches the committed state. This prevents invisible work and false promises.
Test the edges
Good handoff design covers stale tabs, simultaneous transfers, declined reservations, unavailable skills and the customer replying during the transition.
A safe system preserves one truthful owner, a durable event trail and a clear recovery path through each race.
- One active owner
- Version checks for stale actions
- Timeout and decline recovery
- No lost customer message
The handoff is complete when responsibility is committed and visible — not when the AI says it is transferring.