### Answer This is a tricky loop caused by your warm transfer's human detection feature picking up Amy's AI greeting as a "human" voice, which then completes the transfer and restarts the cycle. Here are some approaches to break this loop: *1. Disable Human Detection on the Transfer to Sylvester (330) * When configuring warm transfer, you can disable the Enable human detection setting. [(1) ]() When human detection is enabled, the agent checks if a human is present after the transfer target answers—but in your case, it's detecting Amy's AI voice as human. Disabling this would let the transfer complete without that check, though you'd lose the voicemail protection on that leg. 2. Use Cold Transfer Instead of Warm Transfer Cold transfer simply transfers the call to the destination number without the agent attempting to detect if the other side is human. This would prevent Amy's greeting from being interpreted as a successful human pickup. 3. Adjust the Agent Detection Timeout The Agent detection timeout setting controls the maximum time the AI waits to determine whether the transfer target is a human. Setting a very short timeout might cause the transfer to "fail" before Amy's greeting is detected, triggering the fallback to the 862 number. 4. Reconsider Your Call Flow Architecture Since Sylvester's 330 number is on silent and always forwards to Amy, you may want to restructure so that: - Callers reach Amy directly first - Amy only transfers to Sylvester's 862 number (not 330) when requested This avoids the circular loop entirely. I don't have documentation on a specific variable or flag to distinguish between AI agents and humans during transfer detection, so the above workarounds are your best options based on available settings.

Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.

​ To learn more, see the sources I considered: [[1] Transfer call](https://docs.retellai.com/build/single-multi-prompt/transfer-call) ​

Thanks for the follow-up, @moody. I'll get back to you soon.

Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.

​ To learn more, see the sources I considered: [[1] Transfer call](https://docs.retellai.com/build/single-multi-prompt/transfer-call) [[2] Call Transfer Node](https://docs.retellai.com/build/conversation-flow/call-transfer-node) ​

@AI Evy how can i track transfer attempts

### Answer Tracking transfer attempts within a call isn't a built-in feature with a dedicated counter or variable in the Retell AI dashboard. However, you have a couple of approaches: 1. Use Dynamic Variables You can use [dynamic variables](/build/dynamic-variables) to pass and track state during a call. [(1) ]() While the documentation shows dynamic variables being used for the transfer number itself, you could potentially use them in conjunction with a Custom LLM to maintain transfer attempt state. 2. Custom LLM with State Tracking If you're using a Custom LLM via the LLM WebSocket, you can track transfer attempts on your server side. The WebSocket sends real-time updates including tool call invocations and results. [(2) ]() When a transfer is attempted, you receive the tool call result:

json
{"status":"Transfer call cannot be completed, maybe the other side did not pick up"}

[(3) ]() Your server can count these failed attempts and include that context in subsequent LLM responses, instructing the agent to try the fallback number (862) after a failed attempt to 330. 3. Prompt-Based Workaround For your specific scenario, the simplest solution may be to update your prompt to skip 330 entirely and always transfer to 862 when the caller requests Sylvester—avoiding the loop altogether without needing to track attempts. I don't have documentation on a native "transfer attempt counter" feature, so the Custom LLM approach would give you the most control for tracking this state.

​ To learn more, see the sources I considered: [[1] Transfer call](https://docs.retellai.com/build/single-multi-prompt/transfer-call) [[2] LLM WebSocket](https://docs.retellai.com/api-references/llm-websocket) [[3] Issue with call transfer - not possible to transfer to second number if first one fails](https://discord.com/channels/1186424376300679209/1354765943334637634) ​

Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.

### Answer Yes, you could structure your prompt so the agent tracks transfer state conversationally. The idea would be to have the agent "remember" within the conversation context whether a transfer has already been attempted. You'd add instructions to your prompt like: - "Before transferring to Sylvester at 330, ask yourself: have I already attempted this transfer in this call? If yes, transfer to 862 instead." - "After any failed transfer attempt, remember that the primary number has been tried and use the fallback number for subsequent requests." The documentation recommends incorporating transfer call conditions into the prompt to enhance the agent's understanding. [(1) ]() However, keep in mind that LLMs don't have persistent memory across turns in the same way a database would—they rely on conversation context. If the conversation is long or complex, the agent might lose track. For your specific loop issue, a cleaner prompt approach would be: "When the caller asks to speak to Sylvester, always transfer directly to 862. Do not transfer to 330." This avoids the tracking problem entirely by eliminating the 330 transfer from the flow when Sylvester is requested.

​ To learn more, see the sources I considered: [[1] Transfer call](https://docs.retellai.com/build/single-multi-prompt/transfer-call) ​

Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.