Skip to content
Implementation·

7 min read

·For operators

How to connect an AI voice agent to your existing phone system

Forward a number, route a SIP trunk or transfer from your IVR. What each option costs you, how warm transfers keep context, and where builds break.

Silviu Major·Founder, Fiveleaf··Updated

You connect an AI voice agent to an existing phone system in one of three ways: forward calls from a number you already own, route calls into the agent over a SIP trunk or SIP transfer, or let your current IVR hand selected calls to it. The first is fastest to set up, the second is what you want long term, and the third is how most operators should start.

None of them mean replacing your telephony. Your numbers, queues and human agents stay where they are. The real work is in what crosses between the two systems: who is calling, what they said, and where the call goes next.

What are the options for connecting an AI voice agent?

Call forwarding from an existing number. The agent is given its own number, and your phone system forwards calls to it, either all of them, out of hours, or on overflow when the queue is long. It is quick to set up. The catch is that forwarding often loses information on the way. Depending on the provider, the agent may see your number as the caller instead of the customer's, and getting the call back to a human means dialling out again, which usually drops whatever the agent learned.

SIP trunk or SIP transfer. SIP is the protocol most business phone systems already use to set up calls. With a SIP trunk, calls arrive at the agent as proper calls with their headers intact. With a SIP transfer, your system passes a live call to the agent and the agent can pass it back, using the standard transfer method defined in RFC 3515. This is what computer telephony integration means in practice for a voice agent: the call and its data travel together.

Behind your existing IVR. Your IVR stays as the front door. One option on the menu, say "check an order" or "report a fault", routes to the agent. Everything else carries on as now.

Should the agent sit in front of the IVR or behind it?

Behind it, to start.

Putting the agent in front of everything sounds bold and goes badly. Every caller meets it on day one, including the angry ones, the vulnerable ones and the ones with a question nobody scoped. You learn in public.

Behind the IVR, you pick one or two call types the agent can resolve, measure them, and widen as it earns it. Later, once it handles most of your volume well, it can replace the menu entirely and route by what people say rather than which button they press. A good end state, a bad starting point.

How does the agent know who is calling?

Caller ID first. Over SIP, the caller's number arrives in the call headers. Your provider will tell you which one. It is usually the From header or P-Asserted-Identity. The agent uses it to look up the account before it says a word, so it can greet the customer and skip the "can I take your account number" question for most callers.

Two cautions from real builds. A number is not proof of identity, so anything that touches billing or account changes still needs a security check. And households share numbers, landlines especially, so the lookup needs to handle one number with several accounts without guessing.

If the IVR has already collected an account number, pass it in with the call rather than asking again. SIP can carry small blocks of call data in headers, including the User-to-User header in RFC 7433, or in custom headers your provider supports. Ask which ones survive their network, because some get stripped.

How do you do a warm transfer with context?

A warm transfer is the agent handing the call to a human along with what it has already learned: who the customer is, what they want, what has been checked. Get this right before anything else. It is also where most builds go wrong.

There are two ways to carry the context. Put it in the transfer itself, as SIP headers your phone system reads and shows to the human agent. Or write it somewhere the human's screen already reads, a ticket, a CRM note or a screen pop, before the transfer happens. The second is often more reliable, because it does not depend on every header surviving every hop. More on that in can conversational AI integrate with my CRM.

The test is simple. Call it, get transferred, and see whether the person who answers already knows why you rang. If they ask you to start again, the handover has failed, whatever the transfer logs say.

Decide too what happens when no human is free. A transfer into an empty queue at 7pm is a dead end. The agent should know the queue state, and either take a callback request or raise a ticket instead. We cover that wider question in what happens when an AI agent does not know the answer.

In the UK, a business recording calls on its own system relies on the Investigatory Powers (Interception by Businesses etc. for Monitoring and Record-keeping Purposes) Regulations 2018. One of their conditions is that the business makes all reasonable efforts to tell people using the system that their calls may be intercepted. Your existing "calls may be recorded" message may already cover this, but check it plays before the agent picks up, not only on the human path.

Recordings and transcripts are personal data under UK GDPR, so they need a retention period and access controls like any other customer record. A voice agent usually produces both, plus a summary, so decide which system holds which, and for how long.

Card payments need their own answer. PCI DSS Requirement 3.3.1 does not allow card security codes to be kept after authorisation, and the PCI Security Standards Council says that includes call recordings. Where your system can suppress the audio while card details are given, it should. The cleanest approach is to keep card numbers away from the agent entirely and hand payment to a dedicated secure payment step.

On telling callers they are speaking to an AI: say so early and plainly. Most people do not mind, and the ones who do mind finding out later. See can customers tell they are talking to AI.

What should you ask your telephony provider before you start?

  • Do you support SIP trunks and SIP transfer to an external endpoint, and what do you charge for it?
  • Which header carries the caller's number, and is it ever withheld or replaced on forwarded calls?
  • Can we pass call data with a transfer, and which headers survive your network?
  • How are keypad tones sent: in the audio, as RFC 4733 events, or as SIP INFO?
  • Where is the call recorded, by you, by us or by the agent, and who keeps it?
  • What happens to a call if the agent does not answer? Is there a fallback route to a human queue?
  • Is there a test number or sandbox we can use before touching live routing?

The answers set the design. A provider that cannot do SIP transfer pushes you towards forwarding, and you should know that before you scope the warm transfer.

Where do these connections fail?

At the seam, almost every time. The agent works in testing and the phone system works on its own. The fault is in what passes between them.

Context lost on transfer. The most common one. Data set in a header is stripped somewhere along the way, or the human's screen reads a different field. It looks fine in the agent's logs, because the agent sent it.

Keypad tones that never arrive. A customer is asked to key in a reference and nothing happens. Tones can travel in the audio, as RTP events defined in RFC 4733, or as SIP messages, and if the two ends expect different methods the digits disappear. Test every keypad step on the real route, not a softphone.

Latency. Every hop adds delay: the network, speech recognition, the model, the account lookup, speech generation. A pause that feels short in a demo feels long on a real call, and callers start talking over the agent. Slow account lookups are the usual culprit. Fetch the account at call start, not mid-sentence.

Forwarding loops. The agent transfers to the main number, the main number forwards to the agent. Map every route before go-live.

None of this is exotic. It is the work most first builds underestimate, which is part of why a properly connected first agent takes weeks rather than days, as we set out in how long it takes to deploy conversational AI.

If you are weighing which route suits your phone system, we are happy to talk it through, or you can hear how a voice agent handles a real call at try our agent.

Frequently asked

Do we need to replace our phone system to use an AI voice agent?
No. The agent sits alongside it. The simplest set-up forwards calls from a number you already own, and the more capable one connects over SIP to the system you already run. Your numbers, your queues and your human agents stay where they are.
Should the AI voice agent go in front of our IVR or behind it?
Behind it, for most operators starting out. Let the IVR send one or two call types to the agent, prove it on those, then widen. Putting the agent in front of everything on day one means every caller meets it before it has earned that.
Can the AI agent pass the caller to a human with the details it collected?
Yes, if the phone system can receive data with the call or the agent writes it somewhere the human's screen reads, such as a ticket or a CRM record. Test this first, because a transfer that drops the context is worse than no agent at all.
Do we have to tell callers they are being recorded by an AI agent?
UK rules on business call recording expect the business to make all reasonable efforts to tell callers that calls may be recorded, and recordings and transcripts are personal data. Telling callers they are speaking to an automated agent is also simply good practice. Take advice on your own wording.

If you want help building this

Building AI agents into a business with real customer volume is what Fiveleaf does.

Bespoke build, fully integrated, continuously optimised. A 30-minute discovery call is enough to tell you honestly whether AI agents fit your team right now, or whether you’re better off waiting six months. No pitch.

About the author

Silviu Major, Founder, Fiveleaf

Silviu Major

Founder, Fiveleaf

A decade in enterprise SaaS, now applying that same operational rigour to AI implementation for businesses with real customer volume. Writes about what works (and what doesn’t) from inside live deployments, not from the outside looking in.

More about SilviuConnect on LinkedIn →

Keep reading