TL;DR: The agent is rarely what breaks in launch week. The phone number is. Do not port the client's main business line on day one, forward to the agent instead so you can undo it in thirty seconds. Register the number before it ever dials out, or carriers will label it Spam Likely and the whole system quietly stops working. Register A2P 10DLC before any confirmation text is sent. Decide recording disclosure by the state the caller is in, not the state the business is in. And test the transfer destination, because forwarding loops are the most embarrassing bug in this entire category.
I have built and shipped production voice agents for clients in the US and UK, on Retell and wired into n8n, GoHighLevel and Twilio. The pattern I keep seeing is that the conversation design gets weeks of attention and the telephony layer gets an afternoon. Then launch week arrives and every single problem is a phone number problem: the agent never got the call, the callback got flagged as spam, the confirmation text never arrived, the transfer rang back into the agent.
None of it is hard. All of it is invisible until it is live. Here is the order I do it in.
Do not port the main number first
The instinct on day one is to move the business's main line onto the platform running the agent, because that feels like the real launch. It is the single riskiest thing you can do in week one, for a boring reason: porting is slow to undo.
A port takes days, involves the losing carrier, and can fail on a mismatched account address. If the agent then does something the owner hates on day two, the fastest fix you can offer is another multi-day port back. You have taken the business's most valuable asset, the number printed on their van and sitting in Google Business Profile, and made it hostage to a system nobody has trusted yet.
The sequence I use instead:
- Provision a new number on the platform. The agent lives here during build and testing. Nothing about the business's real phone changes.
- Forward to it when going live. The main number stays exactly where it is, with the existing carrier, and simply sends calls to the agent under conditions you choose. Turning this off is a setting, not a project.
- Port only after the agent has earned it, usually a month or two in, and usually only when the business wants call handling consolidated in one place.
Most clients never need step three, and that is fine. Forwarding is not a hack you graduate from. It is the configuration that leaves the owner in control, which is the thing they are actually buying.
Forwarding is a decision about which calls the agent gets
Once you forward, you have to answer a question the client has usually not thought about: which calls does the AI hear?
- Overflow forwarding (busy, no answer, after hours) sends the agent only the calls a human did not take. This is the right default for any business with staff who answer phones. It is also the easiest sell, because the agent is provably additive: it cannot lose a call the team was already handling.
- All calls routes everything to the agent first. This suits solo operators, out-of-hours-only setups, and businesses drowning badly enough that a human answering is a coin flip anyway.
The trap in overflow is the ring window. If the desk phone rings for six or seven rings before rolling over, the caller has already spent twenty five seconds listening to a ringtone, and the agent inherits an annoyed person. Keep the pre-forward ring window short, around fifteen to twenty seconds, and remember that the caller's patience is a shared budget spent before your agent ever says hello. That is the same principle I described in why a voice agent feels slow: the delay a caller experiences includes everything, not just your part of it.
Register the number before it ever dials out
The moment your system makes outbound calls, and it will if you build missed-call callback, you are in a different regulatory and reputational world than inbound.
Unregistered numbers making repeated short outbound calls get scored as spam by carriers and analytics providers. The failure is silent and progressive: at first everything works, then a couple of weeks in the callback answer rate drops, and eventually the number carries a Spam Likely label on the recipient's screen. Nobody gets an alert. The client just says the callbacks stopped working.
What actually helps:
- Register the number and the business identity with your provider's trust or verified-caller program so the calls are attributable to a real entity.
- Call from the number the customer already saw. If they dialed the main line, a callback from an unfamiliar area code reads as a telemarketer and gets declined.
- Keep the outbound pattern human. One callback attempt, not four. Bursts of very short calls are exactly the signature spam scoring looks for.
- Never repurpose the same number for outbound marketing. The reputation of the number your customers call is worth more than the campaign.
A2P 10DLC is the SMS half of a voice agent
Almost every voice agent I ship also sends text: a booking confirmation, a reminder, a link, a follow-up when a call goes unanswered. In the US that traffic is application-to-person messaging, and it requires brand and campaign registration.
Skip it and nothing throws an error. The workflow reports success and the messages are filtered before delivery, which means the client discovers it a fortnight later when a customer says they never got the confirmation. Budget several days for approval, register with real business details, and handle opt-out language properly. I covered the registration path step by step in the missed-call textback build, and the same registration covers reminders and confirmations from the voice agent.
One practical note: the confirmation text has to come from the number the caller has been dealing with. Cross-number replies orphan the conversation, so the customer's reply lands somewhere nobody is watching.
Recording and disclosure depend on where the caller is
Voice agents record by default, because transcripts are how you improve them and how the client reviews outcomes. Recording law follows the participants, not your server.
The rule I hold to is simple: disclose in the greeting, always. A single clause at the top of the first sentence covers you in two-party-consent states, costs about a second of speech, and has never once cost me a conversion. Trying to detect the caller's state and branch the greeting is the kind of clever that fails on a number ported from another area code.
Two extra things worth handling:
- Decide what happens to recordings at handoff. When the call transfers to a human, know whether recording continues and whether the person picking up has been told. This is a policy question for the client, not a preference for the builder.
- Treat regulated verticals separately. For anything touching health information, disclosure is the smallest part of the problem. I wrote a fuller playbook for that in AI voice agents for medical clinics.
Test the transfer destination, not just the transfer
Here is the bug I have seen bite more than one setup, including in testing where it belongs. The agent is configured to transfer to the business's main number. The business's main number forwards to the agent. The caller is now in a loop, talking to the same agent that just promised them a human.
It is obvious written down and completely invisible in a flow diagram, because on paper the transfer destination is "the office" rather than a specific number with its own forwarding rules attached.
So before launch, place a real call and follow the escalation path all the way to a human picking up. Confirm the transfer destination is a direct line or a mobile that does not route back. Confirm what happens when nobody answers, which is the normal case, not the edge case. And confirm the caller hears an honest fallback rather than silence. The full design of that layer, including what the handoff has to carry, is in when a voice agent should hand the call to a human.
Who owns the number
The last item is commercial rather than technical, and it matters more than the rest combined over a two-year horizon.
If you provision numbers inside your own agency account, you own the business's phone number. Some agencies like that, because it makes leaving expensive. I do not build that way. It turns a service relationship into a hostage situation, and clients can smell it during the sales conversation.
Provision inside an account the client owns or can be given, keep the numbers portable, and document what happens on the day they leave. The clients who feel free to leave are the ones who stay, and the ones who ask this question early are usually the good ones.
The launch checklist
- New number for build and testing. The main line does not move.
- Forwarding rules decided with the owner: overflow or all calls, and a short ring window before rollover.
- Outbound number registered, calling from the number customers recognize, human call pattern.
- A2P 10DLC brand and campaign approved before the first confirmation text goes out.
- Recording disclosed in the greeting, and the handoff recording policy agreed with the client.
- Transfer destination dialed for real, checked for loops, checked for the nobody-answers path.
- Number ownership sitting with the client, in writing.
None of that is the interesting part of building a voice agent. The interesting part is the conversation design, which I cover in how I build production voice agents on Retell and in how I structure conversation flows. But a beautifully designed agent behind a misconfigured phone number is a system that does not answer the phone, and no amount of prompt work fixes that.
Get the boring layer right first. It is the part the client's business actually runs on.
I build production voice and chat agents on Retell, wired into n8n, GoHighLevel and Twilio, including the telephony and compliance layer that makes them safe to put in front of real customers. If you want the phone answered properly, more about my background is here, or book a call.