Transfer Call

An AI agent handling a call will eventually meet something it cannot do. A customer who is angry, a question about an invoice it has no access to, or someone who simply says “put me through to a human”. What happens next is the difference between a voice agent people tolerate and one they resent.

Transfer Call is what happens next. And it is the first node in this course that does not sit on the workflow's path at all: you attach it to a Voice Agent as a tool, and the agent invokes it when the conversation calls for it. Nothing you draw decides when a transfer happens. The agent does.

Everything hinges on destinations. Each entry has a name, a number, and — the field that actually does the work — a description.

The agent does not see your canvas. What it sees is a list of destination names and their descriptions, assembled from this node's configuration and handed to it as part of the tool. That text is the entire basis on which it decides where to send someone.

This is also the fix for most bad transfers. If calls are landing in the wrong queue, the destination descriptions are wrong or missing — not the agent.

transfer_message is not played by the phone system. It is an instruction to the agent to say that exact sentence before invoking the tool. So the caller hears it in the agent's own voice, mid-conversation, and then the transfer begins.

One consequence worth planning for: the message is spoken first, so it is spoken even when the transfer subsequently fails. Somebody hears “please hold while I transfer your call” and then stays exactly where they were. That is what fallback_message is for, and it should read like a recovery rather than an apology — say what you will do instead.

When the agent asks for a destination, the node resolves it in two steps and neither of them is clever:

That last row is better behaviour than it sounds. A failed transfer does not drop the call or end the run; it hands the agent a list and lets it recover in conversation. But it does mean a mismatch is invisible in your metrics unless you look for it — the call carries on and nothing is marked failed.

Setting operation to check_agent_availability turns this into a different, read-only tool: it reports which agents are available rather than transferring anyone. With active_only on — the default — that means verified, online and not currently on a call.

Destinations mean different things on different providers. The number field is a phone number on Exotel and Twilio and an intercom extension on Tata Tele, and a destination can be typed as an agent instead, which uses a provider-side agent id. A set of destinations that works on one provider is not a set that works on another — this is configuration to re-check after any provider change, not to copy across.

Nothing stops the agent transferring badly. There is no confirmation step and no rule you can write here that says “only after two failed attempts”. If you need that, it belongs in the agent's own instructions, not in this node. This node is capability; the agent's prompt is policy.

A transfer ends the AI's part of the call, and its transcript with it. Whatever you wanted to record about the conversation — the reason, the summary, what the customer asked for — read it from this node's output at the moment of transfer. The optional reason the agent supplies is the cheapest way to find out later why calls are being escalated, and it costs nothing to ask for.