### Answer To separate dev, prod, and different clients with independent concurrency handling, you can create separate workspaces for each environment or client. [(1) ]() Concurrency limits apply per workspace, not per account. [(2) ]() Each workspace has its own quota, burst settings, and reserved inbound capacity, and traffic in one workspace does not consume slots in another. This means each workspace can handle concurrent calls independently without affecting other workspaces. For example, you could set up separate workspaces like this: [(1) ]() - Dev workspace for development and testing - Production workspace for live operations - Individual client workspaces for each onboarded client Each workspace will have separate workspace IDs and credentials, ensuring isolation between environments. Regarding the number of workspaces: I don't have specific information in the sources about workspace limits per account. For details on workspace limits and how to set up multiple workspaces for your use case, I recommend reaching out to Retell AI support. Check out these potentially useful sources: [Understand concurrency & limits]() , [Migrate agents across workspaces]()

​ To learn more, see the sources I considered: [[1] Migrate agents across workspaces](https://community.retellai.com/t/migrate-agents-across-workspaces/532) [[2] Understand concurrency & limits](https://docs.retellai.com/deploy/concurrency) ​

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

mends checking the error log for the specific cause, and if you're using Warm Transfer and human detection isn't working, switching to Agentic Warm Transfer — but since you're already on agentic warm transfer and it's cancelling, review the transfer agent's own conversation to see why it isn't bridging. [(3) ]() I don't have specifics in these sources about exact error codes for agentic transfer cancellations. If reviewing your transfer agent's prompt, wait time, and timeout action doesn't resolve it, I'd recommend reaching out to Retell AI support directly for a deeper look at your specific call logs. Check out these potentially useful sources: [Transfer call tool (single & multi-prompt agents) ]() , [Call transfer node in conversation flow]() , [Address metric issues]()

​ To learn more, see the sources I considered: [[1] Transfer call tool (single & multi-prompt agents)](https://docs.retellai.com/build/single-multi-prompt/transfer-call) [[2] Call transfer node in conversation flow](https://docs.retellai.com/build/conversation-flow/call-transfer-node) [[3] Address metric issues](https://docs.retellai.com/ai-qa/address-metric-issues) ​

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

@AI Evy following up — I have the actual call logs, which point somewhere more specific than a wait-time misconfig. Setup: a conversation-flow agent transferring via an agentic_warm_transfer node into a dedicated transfer agent (created with is_transfer_agent: true), dialing a real destination number. The evidence: one call bridged fine (transfer_bridged) with a given config. Two minutes later, same config, zero changes on our end — the next transfer leg ended transfer_cancelled after 1 second. That's too fast for the transfer agent to have dialed, had the destination answer, and made a bridge/cancel decision — it reads like the destination leg never connected at all. Five more legs that same evening died the same way, all right around 1 second each. One leg was different: it ran about 13 seconds, and the transfer agent did have a real conversation with the destination — and still ended transfer_cancelled. That one could fit a wait-time/timeout story. Two questions: For the sub-2-second cancels specifically — is that consistent with "Wait time for agent answer" expiring, or does a cancel that fast usually mean the destination dial itself failed (no answer detected, SIP rejection, etc.) before the transfer agent was ever put on the line? Those feel like different root causes and I want to know which logs would show the difference. Same config bridged once, then failed six times in the next ~25 minutes with no settings changed on our end — is that consistent with a known flakiness/rate-limit pattern on agentic warm transfer, or would that always trace back to something destination-side (e.g. the number itself intermittently rejecting)? Happy to share exact call IDs and agent IDs via DM or a support ticket if that helps pull server-side logs.

### Answer I don't have documentation-level detail on the specific timing signatures that distinguish a destination-dial failure from a "Wait time for agent answer" expiration, so I can't confidently attribute your sub-2-second cancels to one cause versus the other from the sources available. What the sources do confirm: The transfer agent only has two ways to end its call intentionally — Bridge Transfer (recipient ready) or Cancel Transfer (recipient not available) — and otherwise the call ends by hitting the wait-time limit. [(1) ]() The Action on Timeout setting determines what happens when "Wait time for agent answer" expires: either Cancel Transfer (treated as failed) or Bridge the transfer (connects anyway) . [(1) ]() [(2) ]() Note that a timeout-triggered cancel is governed by whatever you've set for "Wait time for agent answer" — if that value is set to something very short, a timeout-driven cancel could in theory happen quickly, but the sources don't specify exact timing thresholds or give a way to distinguish a timeout-cancel from a dial-failure-cancel purely from duration. On your second question, about the same config bridging once and then failing six times shortly after with no changes on your end — the sources don't document any known flakiness or rate-limit pattern specific to agentic warm transfer, nor do they confirm this always traces to the destination side. I don't have information in the sources to support either explanation definitively. For sub-2-second cancels and log-level differentiation between a failed destination dial versus a timeout, and for the intermittent bridge/cancel pattern you're seeing, this is genuinely a c

ase where sharing call IDs and agent IDs directly would help — that's consistent with how other users with agentic/warm transfer issues in this Discord have had their call IDs pulled by the Retell team for server-side log review. [(3) ]() [(4) ]() I'd suggest opening a support ticket or DM with the Retell team with your call IDs, as done in similar transfer troubleshooting cases. Also check [Debug outbound call]() and [Debug SIP calls with PCAP files]() if you want to inspect the destination-leg signaling yourself — though I don't have those documents in the current sources to cite details from them directly. Would you like me to also look into your SIP trunking provider's origination/termination settings angle, since dial failures on the destination leg would show there?

​ To learn more, see the sources I considered: [[1] Transfer call tool (single & multi-prompt agents)](https://docs.retellai.com/build/single-multi-prompt/transfer-call) [[2] Call transfer node in conversation flow](https://docs.retellai.com/build/conversation-flow/call-transfer-node) [[3] Warm Transfer disconnection reasons](https://discord.com/channels/1186424376300679209/1460556976499982407) [[4] Warm call transfer issue.](https://discord.com/channels/1186424376300679209/1468937717097431215) ​

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

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

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

### Answer No, not in the way you're describing — the transfer agent's communication is one-directional and doesn't relay back-and-forth messages between the two agents. Here's what the sources confirm about the transfer agent's setup: - The transfer agent is given the original conversation automatically, so the caller's context is passed to it once, at the start of the handoff. It "knows who called and what they wanted, so it can explain the situation to whoever picks up." [(1) ]() This includes dynamic variables carried over, including anything extracted earlier in the call, plus

original_call_id

. - What it doesn't get is anything said after the transfer starts — the main agent's conversation with the caller isn't fed to it live, and "your main agent never sees the screening conversation." The two calls (the original and the transfer leg) are recorded and transcribed separately. - The transfer agent has exactly two tools available: Bridge Transfer or Cancel Transfer. It has no End Call, Call Transfer, or Agent Transfer tools, so bridging, cancelling, or hitting the wait-time limit are the only ways its call ends. There's no mechanism described for it to send a message back to the original agent for relay to the caller — its role is to decide whether to connect or cancel, not to pass messages between the two agents. - Once the transfer agent bridges, the caller and destination are connected directly and every AI drops off the call — at that point neither AI is passing messages, since they're no longer on the line. So the transfer agent can pass the initial context/summary to the destination once (via the conversation it inherits) , but there's no documented back-and-forth relay where it takes a message from the destination and sends it back to the original agent to convey to the caller mid-

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

@AI Evy so if i have the transfer agent pass the screening message from transfer number caller's message to a custom tool to save as json and pass it back to main agent?

### Answer The transfer agent could call a custom tool during its conversation with the destination to save data (like a screening message) as JSON, since it can call tools while conducting its two-way conversation before deciding to bridge or cancel [(1) ]() . However, the sources don't document any mechanism for that saved JSON, or any tool output, to be passed back to the main agent. What is documented about what the main agent receives: - The main agent never sees the screening conversation, and the transfer agent's call is recorded/transcribed separately from the original call . - The transfer agent's only ways to end its call are Bridge Transfer or Cancel Transfer — there's no tool or field described for relaying data back to the original agent . - The transfer agent is given the original conversation and dynamic variables at the start of the handoff (one-directional, into the transfer agent) , plus

original_call_id

to tie the two calls together — but this is context flowing into the transfer agent, not data flowing back out to the main agent . Since there's no documented pathway for a custom tool's output to be written back into the original call's dynamic variables or transcript, I don't have sources confirming that a JSON payload saved by the transfer agent would be accessible to the main agent afterward. If you need this kind of cross-call data sharing, opening a support ticket with your specific setup would be the way to confirm whether it's possible.

​ To learn more, see the sources I considered: [[1] Transfer call tool (single & multi-prompt agents)](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.

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

​ To learn more, see the sources I considered: [[1] Connect Retell voice agents to custom telephony](https://docs.retellai.com/deploy/custom-telephony) [[2] Vonage](https://docs.retellai.com/deploy/vonage) [[3] Telnyx](https://docs.retellai.com/deploy/telnyx) [[4] Inbound call & SMS webhook](https://docs.retellai.com/features/inbound-call-webhook) ​

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

@AI Evy it was working, suddenky it stopped working

### Answer A sudden stop after previously working points to a few likely areas worth checking first. Check the disconnection reason for the affected calls, in Call History or via the Get Call API — this tells you exactly why calls are failing now (e.g.

dial_failed

,

telephony_provider_unavailable

,

sip_routing_error

,

marked_as_spam

,

concurrency_limit_reached

) [(1) ]() . If the number is on custom telephony: - For Telnyx-imported numbers, if inbound fails check the FQDN and inbound settings on your Telnyx trunk [(2) ]() . - For Vonage-imported numbers, if inbound fails check the origination SIP URI on your Vonage trunk [(3) ]() . There was a known incident where inbound calls experienced connection issues and timeouts from 11:10 AM – 11:34 AM PST due to a brief outage with a telephony provider, which has since been resolved [(4) ]() . If your number stopped working suddenly and recently, it's worth checking whether the timing lines up with a similar provider-side outage, though I don't have information confirming this is the same or an ongoing issue. If a phone number makes many short calls in a short period, carriers might mark it as spam, and the number can then get blocked, showing up as

dial_failed

[(1) ]() . To narrow this down: is the number Retell-native or imported via SIP trunking? Pulling the

disconnection_reason

from a recent failed call would be the fastest way to identify the root cause. If it comes back as

dial_failed

,

telephony_provider_unavailable

, or

sip_routing_error

, that points to a carrier/trunk-side issue rather than something in your Retell configuration .

If checking the disconnection reason and trunk settings doesn't resolve it, I'd recommend contacting Retell support directly with the number and timeframe so they can check server-side logs.

​ To learn more, see the sources I considered: [[1] Debug call disconnection](https://docs.retellai.com/reliability/debug-call-disconnect) [[2] Telnyx](https://docs.retellai.com/deploy/telnyx) [[3] Vonage](https://docs.retellai.com/deploy/vonage) [[4] Intermittent Call Connection Failures](https://community.retellai.com/t/intermittent-call-connection-failures/143) ​

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