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:
-
Matched the failing agent’s transfer settings to the known-working transfer configuration.
-
Changed the failing agent’s transfer destination to the same destination used by the working agent.
-
Created a new minimal agent from the working import specifically for transfer-only testing.
-
Tested multiple transfer node variations, including more complex transfer behavior and simplified warm transfer behavior.
-
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:
-
Are older saved agents using legacy transfer behavior that newer or re-saved agents no longer use?
-
Is there a hidden/default transfer setting being applied differently on newer agents?
-
Is this related to the inbound number or telephony route rather than the visible transfer node config?
-
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