Hand an AI text conversation to a person safely
A concrete handoff design for an AI responder: pause queued work, assign a teammate, preserve context, and resume automation deliberately.
A handoff changes who is allowed to send
When a customer asks for a person, the workflow needs more than a notification. It needs a durable change in who may send the next message. If the old model run can still deliver its draft, the customer may receive two incompatible answers while the teammate believes they own the conversation.
This guide describes an application design for your AI integration. The states and actions below are not new Miss Blue endpoints. Your application owns its model, queue, and automation permissions; Miss Blue supplies the messaging channel and Message Center. A personal conversation pin does not pause an external bot.
Define a small ownership state machine
Keep ownership in durable storage next to the conversation reference. Persist an increasing revision whenever the owner or automation permission changes. Model jobs and queued actions should carry the revision under which they were created, so a later worker can detect that its work is stale.
Swipe across the table to see every column.
| State | Who may send | Transition |
|---|---|---|
| Automated | The authorized dispatcher after policy checks | A customer request, tool failure, or staff takeover requests handoff |
| Awaiting teammate | No free-running AI reply; an approved acknowledgment may be separately authorized | A named teammate claims the work |
| Human-owned | The assigned teammate or approved team workflow | The owner resolves, closes, or explicitly returns the conversation |
| Paused | No automated send | An authorized operator investigates and chooses the next state |
| Closed | No new automatic follow-up from the old workflow | A new inbound request follows the configured reopening policy |
Example states for your application, not a Miss Blue API enum.
Perform the handoff as one durable decision
In one transaction, record the new ownership state, increment its revision, invalidate pending automated sends for the old revision, and create the teammate’s work item. The notification can retry after that commit. If notifying the teammate fails, the conversation should remain paused with a visible pending task rather than silently reverting to automation.
An explicit request such as “Can I speak to someone?” should enter this path deterministically. Other triggers can include a tool failure, an unresolved correction, a policy boundary, or a low-confidence decision. Let the model propose escalation, but let your server authorize and record the transition.
Do not promise a response time the team cannot staff. An acknowledgment such as “I’ve passed this to our team” should only follow a successful durable handoff and your messaging policy. A queued acknowledgment also needs a stable logical action ID so an event retry does not send it twice.
Close the race between a model draft and a staff reply
Consider a fictional appointment assistant. At 10:01 it starts drafting an answer. At 10:02 the customer requests a teammate, and the workflow increments the ownership revision from 7 to 8. At 10:03 the old model run completes with revision 7. Store or discard that draft according to your retention policy, but do not dispatch it under the new owner.
All automated send paths must use the same dispatch gate. Serialize ownership changes and send authorization per conversation, check current permission and revision, and record an in-flight attempt before calling the provider. A check performed only when the model starts leaves the whole generation interval exposed to an ownership change.
There is still a real boundary: a provider may already have accepted an in-flight message before the takeover. Show that attempt to the teammate and reconcile its outcome. Stopping a model stream or changing a local flag cannot retract an already accepted network request. The UI should distinguish canceled pending work from a send whose result is still unknown.
Give the teammate useful context
Provide the customer’s latest request, the unresolved question, the business record, the selected line, the last attempted send, and the reason automation stopped. Preserve links to the verified transcript and tool results. A short summary helps, but the teammate must be able to inspect the evidence instead of trusting a model’s interpretation alone.
For example: “Customer wants Friday instead of Tuesday. Availability lookup timed out; no booking was changed. One acknowledgment is delivered. No other sends are pending.” This is a hypothetical handoff note, not a claim that an appointment exists. Distinguishing attempted actions from completed ones prevents a person from confirming a booking that never happened.
Load the current CRM owner at assignment time, and define a fallback queue when that person is absent. Changing a CRM owner, claiming a task, and pinning a thread are different operations. Keep their relationships explicit so work does not disappear between the CRM and inbox.
Resume with current state, not the old queue
Require an explicit resume action from the owner or a documented reopening rule. Read the latest conversation and business state, increment the revision again, and create new work under that revision. Do not wake the old model job and send the draft it wrote before the customer’s clarification.
Persist chat history, tool outcomes, and ownership separately. Saving a transcript does not automatically save an appointment transaction or make a future send duplicate-safe. The AI SDK persistence guide explains stable turn IDs and history recovery; use a separate durable action record for customer-visible effects.
Exercise the handoff before enabling automatic replies
Build a repeatable evaluation around observable actions. It should report who owned the conversation and which sends actually occurred, not only whether the model wrote a polite response. NIST’s AI Risk Management Framework is useful background for treating evaluation and monitoring as ongoing work; the following cases are our implementation checklist.
Swipe across the table to see every column.
| Trigger | Expected evidence |
|---|---|
| Customer requests a person during generation | Revision changes; late draft does not create a new send |
| Same reply webhook arrives twice | One handoff task and at most one authorized acknowledgment |
| Staff notification fails | Conversation remains paused; notification work is recoverable |
| Provider request times out during takeover | Unknown attempt is visible; no automatic duplicate |
| Teammate replies before a delayed tool result | Tool result cannot re-enable automation |
| Blocked destination returns in an old job | Current policy prevents a new automated dispatch |
| Owner resumes after correcting the request | New work uses current state and a new revision |
Example acceptance cases for an AI-to-human handoff.
Quick answers
Does asking the model to stop prevent every reply?+
No. Pending jobs, delayed tool results, and requests already submitted to a provider need separate handling. Enforce ownership in the dispatcher and surface in-flight attempts.
Should the bot resume as soon as a teammate sends a message?+
Use an explicit resume action or a documented reopening policy. A teammate’s message alone should not revive old queued work.
Does pinning a Miss Blue conversation stop an external AI agent?+
No. Pinning affects a member’s conversation order. Your integration must update its own automation state and queued actions.