Fix: "agent_user does not have a live call" on a transfer

You fire a transfer-conference command and it comes back with agent_user does not have a live call. The transfer never happens. This error means the system looked at the agent you named and did not see a live call on their session to act on. It is one of the most common transfer errors, and almost every cause is about state or timing rather than a broken setting.

What counts as a live call

The transfer-conference function acts on the named Agent and needs that agent to be connected to a customer right now. A live call means an active conversation in the agent's session, not a paused agent, not an agent sitting on the disposition screen, and not an agent who just hung up. If the named user is logged in but not on a call, the function has nothing to transfer and returns this error. So the question to answer is simple: was there really a live call on that exact agent at that exact moment?

Cause, check, fix

flowchart TD
  A[agent_user does not have a live call] --> B{Is the agent logged in}
  B -->|No| C[Log the agent in first]
  B -->|Yes| D{Is the agent on a live call now}
  D -->|No| E[Wait for connect or stop firing on wrap]
  D -->|Yes| F{Is agent_user the right user id}
  F -->|No| G[Pass the user actually on the call]
  F -->|Yes| H{Did the call just end}
  H -->|Yes| I[Race condition ignore and move on]
  H -->|No| J[Re-run the transfer]

It helps to remember that the function deliberately skips the named agent and only counts other sessions, so a lone closer on the call will always come up empty no matter what value you pass. Work down the chain. First confirm the agent is logged in; a logged-out user gives a different error, so rule it out. Next confirm the agent was on a live call when the command fired. The classic mistake is firing the transfer during Wrap-up or while the agent is paused, when there is no customer connected. Then double-check the agent_user value itself; sending the command against the wrong user id, like the closer instead of the agent actually on the call, produces this exact error.

The sneakiest cause is a race condition. If the customer hangs up a fraction of a second before your command lands, the call is no longer live and you get the error even though everything looked fine. When you are driving transfers through the Agent API, build for that: check the agent Status (lead status) right before you act, and treat a late hangup as a normal outcome rather than a failure to retry forever. A single status read costs almost nothing and saves you from a wave of false errors during busy stretches.

Preventing it in practice

If agents hit this from the screen, it is usually a double-click after the customer already dropped. If a script hits it, it is usually firing on the wrong state. Gate your transfer on a confirmed live-call status and the error mostly disappears. The same live-call requirement applies to other session commands, so a status check before any action is a good habit. For the full set of transfer values and what each one needs, the transfers and closers guide lays it out, and the related no-live-call case for forcing a fronter off is covered in the no fronter found fix.

If you would rather not babysit call state to make transfers reliable, a managed dialer handles the edges. See our pricing to see what is included.