Warm transfer works on older agents but fails on newer agents, even with matching transfer config

We are seeing inconsistent transfer behavior between two voice agents.

Issue summary:
A warm transfer works successfully on an older saved agent, but fails on newer agents, even after matching the transfer settings and even after creating a new minimal transfer-only agent from the working import. The failure appears to happen during transfer execution, not in the conversation flow logic.

What is working:
An older saved agent successfully performs a warm transfer using a simple transfer configuration:

  • warm transfer

  • bridge audio cue enabled

  • blank handoff prompts

  • hold music enabled

What is failing:
A newer agent fails during transfer. In logs, the platform starts the transfer and then immediately returns a tool result saying the transfer failed due to an error. The flow then correctly transitions to the fallback transfer-failed node. This indicates the node logic is working, but the actual transfer leg is failing.

What has been tried:

  1. Matched the failing agent’s transfer settings to the known-working transfer configuration.

  2. Changed the failing agent’s transfer destination to the same destination used by the working agent.

  3. Created a new minimal agent from the working import specifically for transfer-only testing.

  4. Tested multiple transfer node variations, including more complex transfer behavior and simplified warm transfer behavior.

  5. Confirmed the fallback node logic is correct, because the transfer-failed path triggers properly after the transfer tool returns an error.

Important finding:
Even after matching the transfer settings and even after using the same transfer destination as the working agent, the newer agent still fails. That suggests the issue is likely not just the visible transfer-node configuration. It may be related to newer transfer runtime behavior, agent save history, telephony path, or another hidden/default difference between older saved agents and newer ones.

Why we believe this is not just flow logic:

  • the transfer node executes

  • the transfer tool is called

  • the platform reports a transfer error

  • the fallback edge runs correctly afterward

What we need help with:
Please compare a working transfer call from the older saved agent and a failing transfer call from the newer agent and identify why the transfer leg fails only on the newer agent path, even when the visible transfer payload is made equivalent.

Questions:

  1. Are older saved agents using legacy transfer behavior that newer or re-saved agents no longer use?

  2. Is there a hidden/default transfer setting being applied differently on newer agents?

  3. Is this related to the inbound number or telephony route rather than the visible transfer node config?

  4. Can you inspect the exact transfer failure reason for the failing call leg?

Reproduction summary:

  • working older saved agent: transfer succeeds

  • newer agent with same transfer setup: transfer fails

  • newer minimal clone/import of working setup: transfer still fails

  • fallback flow executes normally after failure

Hello @intouchpestcontrolai

Could you please share the agent IDs along with the relevant call IDs where the transfer is failing? This will help us investigate the issue more effectively.

Thank you!

Thanks for the reply. Here is the info.

-Failing-
Agent: agent_8694546f415692a748537f094d
Call: call_a37d89b8c2ad863397b78321019

Agent: agent_2b7d48bf428c736efc0a134766
Call: call_38ce6679a12c631b727b623950c

-Working-
Agent: agent_c1e69bb04c7763447355679102
Call: call_f05bd5b0dadb65074f5965b1dfc

Hello @intouchpestcontrolai

I’ve escalated this to our team for further review.

We’ll update you as soon as we hear back.

Best regards

Thanks for the fast response!

Hi @intouchpestcontrolai

For the working case, the agent was using a regular number transferring to a Canadian number.

For the failed case, the agent was using a toll-free number transferring to a Canadian number. Toll-free numbers can only call US numbers.

Thank You

Hi @shaw

We tested and confirmed it works with US numbers!

Is there plans to add Canadian numbers?

Thanks!