How can we make the warm-transfer whisper intelligible when the current agent's voice doesn't match the whisper language?

We’re looking for the recommended way to handle the following situation — or if there’s no built-in way, we’d love guidance on the best workaround.

Setup. We run multi-agent conversation flows for hotel phone reception in Japan: a router agent detects the caller’s language and uses Agent Transfer to swap to a per-language agent (ja-JP, en-US, zh-CN, ko-KR…), each with a language-appropriate voice. On escalation, the language agent runs a transfer_call node with warm_transfer and a private_handoff_option of type prompt that summarizes the call in Japanese, since the transfer target is Japanese hotel staff.

Problem. The whisper is spoken by the current agent’s voice. After a swap to e.g. the zh-CN agent, the Japanese whisper is read by a Chinese TTS voice and staff genuinely cannot understand it. Example call: call_c5d29af6092a56975d2d52b010c (caller spoke Chinese; staff couldn’t parse the Japanese summary).

Questions:

  1. Is there any existing way to control which voice speaks the whisper — a voice_id on private_handoff_option, a per-node voice, or an agent setting we’ve overlooked?
  2. If not, what’s your recommended pattern for this? The whisper language is dictated by the transfer target, not the caller, so any multi-language deployment that whispers to staff hits this.
  3. We prototyped swapping back to a primary-voice agent just before the transfer, but since Agent Transfer lands on the destination flow’s start node and dynamic variables can’t be set at swap time, we’d need one executor agent per transfer destination plus per-language agents for the transfer-failed/callback paths — roughly doubling our agent fleet per customer. Is there a lighter pattern we’re missing?
  4. If none of the above exists today: could a whisper voice_id override on private_handoff_option / public_handoff_option be considered? Since the whisper is only heard by the transfer target and is synthesized separately from the live conversation, it seems self-contained on your side.

This affects multiple production customers; happy to share more call IDs or test a beta.

Hello @andrew3

Q1: Is there a voice_id override on private_handoff_option?

No. The private_handoff_option only supports the handoff type (prompt or static_message) and the message content.

Q2: Recommended pattern?

A recommended approach is to use Agentic Warm Transfer, where a dedicated transfer agent handles the handoff conversation with the hotel staff.

Because the transfer agent is a separate AI agent, it can use a Japanese voice regardless of which language agent initiated the transfer.

The transfer agent speaks privately with the staff before bridging the caller.

Docs : ( Transfer call tool (single & multi-prompt agents) - Retell AI ) and ( Agent Transfer Node - Retell AI )

Q3: Is there a lighter pattern than per-language executor agents?

Yes. A single shared Japanese-speaking transfer agent can be reused across all of your language agents for the private handoff.

This avoids the need to create separate executor agents for each language solely to support the whisper.

Q4: Feature request for voice_id override?

A voice_id override for the whisper is not currently available.

If you’d like to see this functionality added, please submit a feature request in the Feature Requests section of the forum so the team can review your suggestion.

Best Regards.

Hi Mark,

Thanks! We’ll try out the agentic warm transfer. I didn’t realize this was an option.

Andrew

Hi Mark,

We switched to agentic warm transfer and it seems to be working as expected for the most part.

However, the transcript and recording of the agentic warm transfer call leg is tracked under a separate call ID which is different behavior from traditional warm transfer. Is there any way to have this call leg be recorded in the same call log as the rest of the call, similar to how agentic transfer works?

If not, we’ll find a way to work around it.

Thanks,

Andrew

Hello @andrew3

Agentic warm transfer places a real outbound call to a phone number — this creates a separate call leg with its own call_id. This is fundamentally different from Agent Transfer, which stays on the same call with the same call_id.

This is by design and not configurable.

Best Regards.