Assistant Transfer Randomly Failing
# support
c
Hey I have a sqaud of assistants and the entry assistant has this long array of assistants it can transfer to. I have noticed that if the User attempts to interrupt the AI's first message, that later when it attempts to transfer the call to the appropriate assistant, it always fails. Like it will say that 'transfering the call' line, and then just end the call. This is a redacted example which occured earlier today: AI Good afternoon. Yeah. Thank you for calling [company name]. My name is [AI name]. Which location are you calling about today? User [location name] AI Good afternoon. Thank you for calling [company name]. My name is [ai name]. Which location are you calling about today? User [location name] AI Transferring the call now. Forwarded → But it just forwards it to the grave šŸ˜‚ and hangs up. Any clues on why this is occuring? And how to debug or resolve this?
v
Hey there! šŸ‘‹ I see you're having issues with assistant transfers failing when users interrupt the AI's first message. I wasn't able to determine the exact cause in your specific implementation without seeing your configuration or logs. However, I can definitely help with common causes and debugging steps for this issue! Based on the information I found, here are some potential causes and solutions: ## Potential Causes 1. **Turn-Taking Behavior Issues**: When a user interrupts the AI's initial message, it can disrupt the expected flow, causing transfer failures. According to [information I found](https://discord.com/channels/1211482211119796234/1211483291191083018/threads/1335054553250533439), "This is how turn-taking behavior operates, the user must provide input in order for it to be processed by the assistant for the subsequent response." 2. **Timing Issues**: The transfer might be initiated before the AI has fully processed the user's interruption or completed its initial message. [One source](https://discord.com/channels/1211482211119796234/1211483291191083018/threads/1316539646808686602) indicates that transfers can fail when initiated immediately after a message that wasn't fully played. 3. **Misconfiguration**: There might be issues with your assistant's configuration, particularly related to
forwardingPhoneNumber
or conditions that unintentionally trigger the
transferCall
function. 4. **Conflicts with Other Settings**: The
phone-call-control
server event might be interfering with Vapi's ability to handle call transfers. [Sources indicate](https://discord.com/channels/1211482211119796234/1211483291191083018/threads/1335869152535121960) that when this server event is utilized, call forwarding control and logic are managed by you rather than VAPI. ## Debugging Steps 1. **Gather Call Information**: Collect the call ID, timestamp, expected response, and actual response for failed transfers.
2. **Review Assistant Configuration**: Verify that the assistant ID is correctly set on the phone number and that there are no issues with the assistant request itself. 3. **Analyze Logs**: Check the Vapi dashboard and Twilio logs for any errors or unusual activity during the transfer process. 4. **Check Tool Call Details**: Examine the tool call details in the logs to see if the
transferCall
function is being called with the correct arguments and if any errors are being returned. ## Potential Solutions 1. **Adjust AI Settings**: - Set the model temperature to 0.3 - Consider changing the Model to GPT4o (some users [reported success](https://discord.com/channels/1211482211119796234/1211483291191083018/threads/1339614362742165606) with this) - Adjust
numWordsToInterruptAssistant
to a higher value - Set
maxDurationSeconds
to define the maximum time the AI waits for a response 2. **Modify Call Flow Logic**: - Rework the prompt using the Vapi prompting guide for tools calling - Adjust the call flow logic to wait for message playback to complete before initiating the transfer 3. **Ensure Proper Configuration**: - Remove the "phone-call-control server event" from the assistant configuration - Ensure that the
assistantOverrides
are set correctly - Verify that the first message and system prompt are properly configured Is there any specific part of this you'd like me to elaborate on further? Sources: - [Discord Thread about Turn-Taking Behavior](https://discord.com/channels/1211482211119796234/1211483291191083018/threads/1335054553250533439) - [Discord Thread about Timing Issues](https://discord.com/channels/1211482211119796234/1211483291191083018/threads/1316539646808686602) - [Discord Thread about phone-call-control conflicts](https://discord.com/channels/1211482211119796234/1211483291191083018/threads/1335869152535121960)
k
To help track down this issue, could you share one or two: \- The call ID \- When exactly this happened (the timestamp) \- What response you expected to get \- What response you actually got instead This would really help us figure out what went wrong
c
1. 2c016d8a-4bf3-4b6b-80c9-79310fafbdec . 2. Apr 12 2025 at 13:13 est (17:13 utc). 3. transfer to assistant called 'Red House Road - Main' . 4. "{ "name": "transferCall", "role": "tool_call_result", "time": 1744479116959, "result": "", "toolCallId": "call_NILYv9kgAZ18AYRgV7s2Pii1", "secondsFromStart": 12.629 }" and then like it tried calling it again and this time "{ "role": "tool_calls", "time": 1744479131041, "message": "", "toolCalls": [ { "id": "call_qnxPwQ8EEWt9KVzLP27ASDIv", "type": "function", "function": { "name": "transferCall", "arguments": "{\"destination\": \"Red House Road - Main\"}" } } ], "secondsFromStart": 26.711 } { "role": "bot", "time": 1744479132474, "source": "", "endTime": 1744479133594, "message": "Transferring the call now.", "duration": 1120, "secondsFromStart": 15.18 } { "name": "transferCall", "role": "tool_call_result", "time": 1744479132483, "result": "", "toolCallId": "call_qnxPwQ8EEWt9KVzLP27ASDIv", "secondsFromStart": 28.153 }" where it just hung up the call .
a
I have exactly the same issue
k
Caleb we are looking into it
Alex, I recommend that you create a support ticket thanks
c
Glad to hear im not alone lol. It's actaully a huge issue, causing a much worse UX for my customers
Any update?
k
logs
🟢 17:32:18:512 Call 2c016d8a-4bf3-4b6b-80c9-79310fafbdec Done. (assistant-forwarded-call) šŸ”µ 17:32:12:491 Finding Requested Destination... (Red House Road - Main) šŸ”µ 17:32:12:491 Using Requested Destination Even Though Not Matched: Red House Road - Main. Converted to: { "type": "number", "number": "Red House Road - Main" } šŸ”µ 17:32:12:501 Transferring Twilio Call...TwiML:<Response><Dial><Number>Red House Road - Main</Number></Dial></Response>
Your model triggered the tool call with a destination that was not in your transfer tool call destinations, so it pivoted to a number type and actually tried to forward the call. But because it was not a number, Twilio failed on their end (which he can verify in the Twilio call logs). Now, you can also let him know that transfer to assistants only works within this squads, not out at the squads
c
Ahh okay thank you this was helpful
It looks like there was a SLIGHT variation in the assistant name in our prompt vs in the assistant destinations array
I just pushed a code update. But can you confirm if that slight difference was causing the issue?
Hey so it solved lets say 80% of the problems HOWEVER there is still another underlining bug that i suspect is a system wide problem. here is a call_id for a call that occured just now "9738d745-485a-4b12-9e48-c51f12c1f8fa" . The User called and asked for a certain location - which triggers a tool call with to a new assistant called 'Tamiami Trail N. - Main-7fj' . It was properly set as 'name' for the assistant we want to transition to, in the assistantDestiation for the current assistant, and in the prompt. This transition occured flawlessly. However, once we are in that new assistant node, the user repeats a phrase once more which was the reason why the toolCall occured in the first place. This triggers ANOTHER toolcall to transfer to the assistant (but it is ALREADY ON that assistant , as we already did that transfer), and then therefore the call fails with these last 3 elements in that Messages array: "{ "role": "user", "time": 1744651032515, "endTime": 1744651033015, "message": "Naples.", "duration": 500, "secondsFromStart": 14.16 } { "role": "tool_calls", "time": 1744651033593, "message": "", "toolCalls": [ { "id": "call_NUicYVjQ7N1vASvjwVKWm1Zt", "type": "function", "function": { "name": "transferCall", "arguments": "{\"destination\": \"Tamiami Trail N. - Main-7fj\"}" } } ], "secondsFromStart": 14.368 } { "name": "transferCall", "role": "tool_call_result", "time": 1744651033608, "result": "", "toolCallId": "call_NUicYVjQ7N1vASvjwVKWm1Zt", "secondsFromStart": 14.383 }". Can you please do further investigate with this new call id to figure out the actually why that it has this odd circular logic for tool calling of assistants, even after we have successful done one? I suspect this is likely a VAPI-system issue occuring here, and a problem other Users are experiencing too
s
call_id pls
c
literally gave the call id if you wanna read it
...
@Sahil Bro please like this is MASSIVE issue that is occuring liteally on 10-25% of ALL CALLS
It is having MASSIVE negative implications for us. I just switched from Bland to VAPI, and I really would rather not have to mvoe to Pipecat
@Kings_bigšŸ’«
k
Kindly resend your call id
c
9738d745-485a-4b12-9e48-c51f12c1f8fa
Bro its literally in the 2nd sentence of the message...
I gave you everything you needed to know to solve this in that message, and that just shows to me you didn't read it
I get yall are busy af, but you Assistant tool calls are literally broken, and thats a big issue. This should be a critical issue ...
s
Use gpt-4o
and it is going to solve most of your issues.
@Caleb
2 Views