What Actually Transfers in an AI-to-Human Handoff

ai-support, vendor-evaluation, intercom, zendesk, chatwoot

Every "AI escalation best practices" post says the same thing: preserve context on handoff. None of them opens the vendor's own docs to say what an AI agent's human handover context actually is — a full transcript in the same record, or a generated summary in a new one. Read the mechanics and the three big vendors split into two different answers. Zendesk keeps the same ticket end to end, transcript backfilled in. Intercom's Fin, escalating through its Helpdesk, opens a new conversation and carries over a summary as an internal note — not the verbatim transcript. Chatwoot's Captain reassigns the same conversation it was already running. Three different answers to "what transfers," and none of the generic advice tells you which one your vendor gives.

We don't have an AI agent to hand anything off from — no LLM provider is connected to Replium today. What we do have is the human-to-human version of the same problem, and it's worth being honest about why that version has nothing to lose: it's one database row that changes an owner field, not a handoff at all in the sense this article is about.

What Fin's human handover context actually is

Intercom's own developer docs describe a POST /fin/escalate endpoint that hands a conversation to a human teammate. On the Intercom Helpdesk specifically, escalating an existing agent conversation doesn't continue that conversation as a ticket — it opens a new Helpdesk conversation, and Fin summarizes the prior exchange into that new conversation's internal note. There's also an optional context parameter, for background the orchestrating agent has that Fin itself doesn't, and it's inserted above the summary in that same internal note — never shown to the customer.

So a Fin escalation to Helpdesk hands the receiving teammate a summary and, optionally, a paragraph of context — not the raw back-and-forth. Whatever nuance was in how the customer phrased something, or a detail Fin's summary skipped, isn't in the new conversation unless the summary happened to capture it. The API does record that this happened: escalating sets the conversation's ai_agent.resolution_state to escalated, readable back through the Conversations API. If Fin's own mechanics matter to you, they're worth weighing alongside the fifteen questions we put to Intercom's documentation after the Salesforce acquisition — this is one more to add to that list.

What Zendesk keeps, because it never creates a new object

Zendesk's model is structurally different. A messaging conversation and the ticket that represents it are the same object from the start — one interaction, one ticket, whether an AI agent is handling it or a person is. When an AI-agent ticket escalates, its status resets from Open to New so it re-enters the normal ticket workflow, and the conversation history that happened before the human ever saw it is backfilled into that same ticket. There's no second record to reconcile against the first, because there's only ever been one.

The trade Zendesk makes for that continuity is that nothing about the AI-only phase is visible until you go looking in a ticket that, by definition, already exists — it just wasn't shown as a ticket in the UI before this became generally available. The record was always singular; what changed was whether an admin could see it while the AI was still the only participant. While it's AI-only, that ticket is also documented as read-only and exempt from triggers and other automated workflows — the usual ticket-routing rules only start applying once a human is actually on the thread, which matters if your team leans on those rules to notice a ticket at all.

What Chatwoot's Captain does with the same conversation

Chatwoot doesn't split "conversation" and "ticket" into two objects at all — Captain's handoff reassigns the same conversation record to a human agent rather than closing it and opening something new. A "Handoff to Human" action, configured in Captain's console, is what triggers the reassignment, and the agent taking over sees a banner marking that a handoff happened, then picks up the same thread. Structurally this is the closest of the three to what a small, single-product help desk can offer without a separate ticketing layer to keep in sync.

Where the generic advice actually comes from

The "85% of chatbot handoffs lose context" figure making the rounds in 2026 comes from Alhena, an AI customer-support vendor, which tested 15 live AI agents itself and found 4 of the 15 escalated with no context carried over at all — a competitor's own research, worth reading with that in mind, but it's the actual origin of the number, not a blog repeating it. The underlying pain is real and better sourced elsewhere: Zendesk's own 2026 CX Trends report, surveying over 11,000 people, found 74% of customers frustrated at having to repeat information to a different agent. That's Zendesk describing the exact problem its own competitors are selling a fix for — and, per the section above, a problem its own ticket model is structurally built to avoid.

What to ask a vendor before you believe the landing page

1. Is the post-handoff record the same one the AI was using, or a new one? If it's new, ask what populates it — full transcript, or a generated summary — and whether that's configurable.
2. What happens to structured data the AI collected — account details, order numbers, a diagnosis — if the record changes? A summary can drop a field a transcript wouldn't.
3. Is there a system-visible record of the handoff itself — who or what handed off, when, and why — or does the receiving agent have to infer it from the first message they see?
4. Does "seamless handoff" in the marketing page match what the changelog or developer docs describe? The gap between the two is exactly where the 2026 "AI escalation best practices" posts stop looking.
5. Do your existing ticket rules and automations fire while the AI is still the only participant, or only after a human joins? If routing depends on triggers a bot-only conversation doesn't run yet, a ticket can sit unnoticed for longer than the dashboard's resolution-time number suggests.

Where Replium stands on this

We don't run this comparison on an AI agent, because we don't have one — no LLM provider is connected to the product, so there is no AI-to-human handoff to describe honestly. What we have is com.replium.conversations.TransferConversationRequest: an operator moves a conversation to a colleague, or back to the shared queue, through PUT /api/conversations/{id}/operator. That call does exactly one substantive thing to the data — conversation.setOperatorId(targetOperatorId) — and one thing for the humans involved: it appends a system message, in the workspace's own language, naming who transferred it and to whom, into the same thread the customer has been reading the whole time. No new record, no summary, nothing to reconcile.

The same is true earlier, when a conversation is created: an online teammate is picked round-robin, and if nobody happens to be online, the conversation simply waits, unassigned, in the shared queue rather than going anywhere that would need reconciling later. It's the same register we used to read our own MCP server's tool contracts rather than describe them from memory — the honest answer about your own mechanics is whatever the code actually does, not what the docs promise it does.

Who should stop reading here: anyone evaluating handoff fidelity as a reason to pick an AI-agent vendor. We're not a data point on that question, because the failure mode this article is about — an AI's summary losing something the transcript had — can't happen to a product that has no AI summarizing anything. What we can promise is narrower and true: a conversation moved between two people in Replium is still, structurally, the one conversation it always was.

If a shared inbox where nothing needs summarizing between operators is what you're evaluating, create a workspace — self-serve, an email confirmation, no card.