AI Agent Human Takeover: How Do You Prevent Two Replies?
Start with the short answer ↓
Assigning a conversation to a person does not prove the AI has stopped replying. Define who controls the next reply, what happens to prepared or in-flight messages, and when automation may resume.
Prepared with AI assistance. These are practical scoping recommendations; examples are illustrative, not client results.
Separate assignment from permission to reply
An AI agent prepares a service reply. Before it sends, a teammate opens the same conversation and starts handling the request. The inbox now shows the person's name, but a background job still holds the AI draft. If both paths can send, the customer may receive two different answers. This is an illustrative design problem, not a client incident or a claim about a delivered AgenticShip connector.
Assignment answers who should handle the case. Conversation control answers who may initiate the next customer-facing action. Treat them as separate requirements until the chosen platform proves they move together. An internal note, an owner field and a successful transfer notification are not interchangeable evidence that an AI reply was stopped.
This guide concerns taking control of an already active conversation. The shared-inbox guide covers a different question: how a prepared request reaches an accountable owner without becoming several tasks.
Write a conversation-control contract
Name the system that owns the control state, the conversation ID, the current controller and a control version that changes when authority moves. Decide which effects are covered: customer replies, follow-ups, booking changes or only a specific subset. Read-only preparation may continue only where that is explicitly permitted and does not silently trigger an external action.
The following worksheet is our proposed operating contract, not a built-in state machine shared by all inbox products. Show the control state to staff and enforce it in the execution path. A prompt telling the model to stop when a person joins is not enough.
| Control state | New AI customer-facing work | Visible next responsibility |
|---|---|---|
| AI handling | Allowed only within the approved scope and current control version | The agent handles supported work; a person can request takeover |
| Takeover requested | Block new dispatches; identify outstanding requests | The handoff owner verifies the stop boundary and pending effects |
| Human handling | No new AI reply or follow-up for this conversation | The named person handles incoming messages and unresolved actions |
| Return proposed | Remain stopped while the return conditions are checked | An authorized person chooses the permitted next automated step |
| Closed or held | Do not restart merely because an old job wakes up | The owner decides whether a new message reopens human work or a new supported case |
Verify what your platform's handoff actually does
Check the channel, engagement hub and adapter as one path. Microsoft documents a custom adapter that receives a handoff event and conversational context for a generic Copilot Studio engagement hub. That is a specific integration pattern, not proof that an unrelated queued email or external system update is canceled at the same moment.
Ask for observable acceptance criteria: which event requests transfer, which component acknowledges it, where the transcript is available and what staff see if no person is available. Do not tell the customer that a teammate has joined when the evidence only shows a transfer request. A waiting state needs an owner and an honest next step.
Account for drafts, queued work and requests already accepted
A draft that has not entered dispatch can normally be withheld by the application that controls it. A queued job needs a control-version check when it is actually dispatched, not just when the draft was created. Coordinate ownership changes with authorization of outbound work; reading a status field and sending later leaves a race between those steps.
A request already accepted by the channel provider is different. Do not display it as canceled unless the provider confirms a supported cancellation. Record it as accepted, completed or uncertain according to the evidence. A timeout does not show whether the customer received the message. The person taking over needs to see that uncertainty before preparing a conflicting reply.
The takeover acknowledgement should describe the boundary the system can enforce. It may be able to prevent new requests while one previously submitted message remains in flight. If the provider cannot cancel it, the interface must not promise that nothing else can arrive. Reconcile the outstanding result and let the responsible person choose the next communication.
Worked example: the old draft wakes up after takeover
Consider conversation C-27 in control version 4. The agent prepares draft D-8 proposing a reply about an appointment, but dispatch has not started. A teammate requests control; the application records version 5 and blocks new automated dispatches. The teammate then checks the booking and prepares the human answer. These identifiers are invented for this example.
When the old worker wakes up with D-8 and version 4, the dispatch gate rejects that stale authority and retains the draft as not sent. It must not silently label the job completed as though a reply reached the customer. The person can inspect or discard the draft, while the audit record distinguishes a suppressed send from a delivered message.
Now change one fact: the provider accepted D-8 before version 5 was recorded. Takeover cannot erase that acceptance. The system shows the outstanding message and its known result; the teammate verifies it before sending a correction or continuation. The acceptance test must cover both event orders. Testing only the easy case, where the draft is still local, does not demonstrate a safe in-flight handoff.
Prevent the next customer message from restarting the bot
A customer may send another detail while a person is handling the conversation. Route that message to the current controller. Do not let a generic new-message trigger recreate AI authority just because it would have started the agent on a new conversation. Check scheduled follow-ups, reopened cases and fallback workflows as well as the main reply path.
Intercom's Fin chat troubleshooting documents this distinction: escalation ends the active session, but a subsequent workflow trigger can re-engage Fin. Its guidance includes guard conditions for conversations already handled or escalated. This is provider-specific behavior that supports a broader implementation question: which entry points can reactivate automation after the handoff?
Returning control is a separate decision. Specify who can authorize it, whether the person has finished, which messages and record changes the agent must reread, and the exact scope allowed next. Create fresh authority rather than replaying an old draft. Approval of one prepared action is not permission to return the entire conversation to autonomous handling.
Separate approval of an action from broader AI authority
Read Intercom's guidance on Fin re-engaging after escalation →
Test the control boundary before widening the agent's scope
Use an isolated environment with real outbound delivery and irreversible writes disabled. Test takeover before drafting, after drafting, after queueing and after provider acceptance. Add two teammates requesting control, an unavailable recipient, a new customer message during human handling, a scheduled follow-up, a reopened case and an explicit return to automation. Include the actual supported languages and channels rather than assuming chat behavior applies to email or voice.
For each case, write the expected controller, allowed effects, withheld work, evidence shown to the person and next recovery action. Inspect the underlying dispatch record and provider result, not only the inbox badge. Define a release-blocking result such as an unauthorized new reply after acknowledged takeover. Keep genuinely uncertain earlier requests visible instead of counting them as successfully canceled.
Retain a handoff receipt with conversation reference, control versions, request and acceptance times, pending effects, next owner and the reason for any restart. Apply appropriate access and retention; a general operational log should not become a second unrestricted customer transcript. Review duplicate or conflicting replies, unaccepted handoffs and time waiting for a controller separately. Start with one conversation path and expand only when the stop and return paths have been demonstrated.
Primary references
The guidance above is AgenticShip's proposed approach. These references provide technical background for the relevant recommendations.