Miss Blue field notes # 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. Published September 13, 2026 6 minute read In this guide [A handoff changes who is allowed to send](#section-1) [Define a small ownership state machine](#section-2) [Perform the handoff as one durable decision](#section-3) [Close the race between a model draft and a staff reply](#section-4) [Give the teammate useful context](#section-5) [Resume with current state, not the old queue](#section-6) [Exercise the handoff before enabling automatic replies](#section-7) Build with Miss Blue **Turn the next message into a real reply.** Get a blue line for your product, agent, or team. Use the Message Center today and connect the API anytime. [Create your account](https://missblue.dev/signup) [Explore the API](https://missblue.dev/imessage-api) Build with Miss Blue **Turn the next message into a real reply.** Get a blue line for your product, agent, or team. Use the Message Center today and connect the API anytime. [Create your account](https://missblue.dev/signup) [Explore the API](https://missblue.dev/imessage-api) 01 ## 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. - [Build the complete AI text responder](https://missblue.dev/blog/ai-text-message-responder) - [Connect tools, memory, and messaging](https://missblue.dev/blog/imessage-api-for-ai-agents) 02 ## 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. Example states for your application, not a Miss Blue API enum. | 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. 03 ## 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. 04 ## 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. - [Test late results and uncertain sends](https://missblue.dev/blog/testing-imessage-api-integration) - [Understand send acceptance](https://missblue.dev/docs/sending-messages) 05 ## 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. - [Map replies and owners without guessing](https://missblue.dev/blog/imessage-crm-contact-sync) - [Create a Pipedrive follow-up activity](https://missblue.dev/integrations/pipedrive) 06 ## 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. - [Persist AI SDK turns and recover history](https://missblue.dev/blog/vercel-ai-sdk-persistence) 07 ## 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. Example acceptance cases for an AI-to-human handoff. | 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. - [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) - [Authorize actions at the server boundary](https://missblue.dev/blog/secure-text-messaging-api) Frequently asked questions ## 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. Primary sources ## Read the documentation. - [Miss Blue send acceptance](https://missblue.dev/docs/sending-messages) - [Miss Blue reply events](https://missblue.dev/docs/receiving-messages) - [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) Explore the platform ## Turn the research into a working conversation. [For developers ### iMessage API Build two-way blue-bubble conversations into your product or agent. Explore](https://missblue.dev/imessage-api) [For teams ### Message Center Use a complete shared conversation platform without writing code. Explore](https://missblue.dev/features/message-center) [For Apple contacts ### FaceTime Audio calling Call from your blue line without carrier Spam Likely labels. Explore](https://missblue.dev/features/facetime-audio-calling) [For every phone ### Outbound calling Call any dialable number from your Miss Blue business line. Explore](https://missblue.dev/features/outbound-calling) Ready to build? ## Send your first blue bubble with Miss Blue. [Explore the iMessage API](https://missblue.dev/imessage-api)