TL;DR: The scary version of vendor lock-in is not that a voice platform raises its price. It is that the platform is quietly holding the pieces you cannot rebuild: the phone number, the post-call automation, a year of transcripts, and a voice your callers now recognise. The agent itself, the prompt and the flow, is the cheapest part to redo. I build so that everything expensive lives outside the platform, and I have moved agents between platforms often enough to know exactly which parts hurt.
Every few months a client asks some version of the same question. What happens if this platform doubles its price, gets acquired, or has a bad week? Usually they are asking because a founder or an investor asked them.
It is a fair question and it deserves a specific answer rather than reassurance. So here is the inventory I actually run: what a live voice agent is made of, which parts move to another vendor in an afternoon, and which parts do not move at all.
I have built the same kinds of agents on Retell for a US product, and on an in-house platform at a UK company, plus enough migrations and rebuilds in between. The pattern is consistent, and it is not the one people expect.
The agent is the cheap part
When people picture lock-in they picture the prompt. Months of tuning, hundreds of small wording decisions, all trapped in someone's dashboard.
In practice, the prompt is text. It is the single most portable thing you own. Paste it into another platform and roughly eighty percent of it works immediately, because it is instructions written for a language model and every platform is pointing at the same handful of models.
What actually breaks in a move is everything the prompt was standing next to.
The inventory, ordered by how much it hurts
The phone number. This is the one that ends careers of otherwise good projects. If the number lives inside the platform and was bought there, you are not negotiating from a strong position. If it is the client's own number, forwarded into the platform, then switching vendors is a change to a forwarding rule and callers never notice. This is why I forward rather than port on day one and insist the client owns the number. It costs nothing at setup and it is the difference between a migration and a hostage situation.
Post-call automation. The single biggest fork in the road. If your booking writes, CRM updates, texts and notifications run through platform-native workflow builders, then moving platforms means rebuilding your entire back half, including all the failure handling you learned the hard way. If they run in n8n behind a webhook, the platform is just the thing that fires the event. I keep that layer external on every build, and not primarily for portability. I keep it external because that is where the real reliability work lives and I want it somewhere I can version, replay and debug.
Tool and function definitions. Portable if they point at your own endpoints, painful if you leaned on the platform's built-in integrations. A tool named lookup_customer that calls a URL you control is three minutes of re-entry. A native calendar integration configured through a dropdown is a rebuild plus a fresh round of edge case discovery.
The conversation flow. Node graphs, components and flex mode are genuinely proprietary. There is no export format that another vendor reads. But rebuilding a flow you designed yourself is a day of work, not a month, because you are transcribing a structure you already understand. Keep a diagram or an outline of the flow outside the platform and that day gets shorter.
Tuning. Endpointing thresholds, interruption sensitivity, filler behaviour, how long the agent waits before it decides you stopped talking. None of this transfers, because the latency chain is different on every platform. This is real, unglamorous switching cost. Budget a week of listening to calls and nudging numbers again.
The voice. Underrated. If the business has been answering calls with one specific voice for a year, that voice is part of how they sound to their customers. Voices are provider assets. You may find something close on the new platform, you will rarely find the same one, and the client will hear the difference on the first call even if nobody else does.
History. Transcripts, recordings, call metadata, analytics. This is the part that genuinely does not move. You can export what the platform lets you export, and then you have a folder of JSON instead of a searchable product. Anything you built on top of that history, reporting, quality review, a client dashboard, has to be re-pointed at a new source with a different shape.
The rule I actually build by
This is the same rule I learned writing a cross-platform C# SDK that had to run on Windows, Android and iOS: share the logic, never the platform. Everything that encodes a business decision lives in code you own. Everything that is genuinely platform-specific stays thin, isolated, and cheap to throw away.
Applied to voice agents, it comes out as four rules:
- The client owns the phone number, and the platform sits behind a forward.
- Everything after the call ends happens in n8n and the client's CRM, not in platform workflows. Retell, or whoever, only fires the event.
- Tools call my endpoints, not vendor integrations, wherever there is a choice.
- The prompt, the knowledge content and an outline of the flow live in git, not only in the dashboard. That is the same file I need for rollback and regression testing anyway.
Do those four things and a platform migration is a week of careful work. Skip them and it is a rebuild with the client's phone line as the deadline.
Notice that none of the four are extra work done for portability. Each one is something I would do anyway for reliability, debuggability or client ownership. Portability is a side effect of building the thing properly, which is the only version of portability worth paying for.
What I do not do
I do not build an abstraction layer over multiple voice platforms.
It is the obvious engineer's instinct: wrap the vendor behind an interface so you can swap it. I have watched that idea eat months in other contexts and I think it is wrong here specifically. The platforms differ in exactly the places that matter, in how they model turns, how they handle interruption, how flows are expressed. An abstraction that covers all of them collapses to the lowest common denominator and you lose the reason you picked a platform in the first place.
The cheaper insurance is a clean boundary, not a portable layer. Keep the vendor-shaped part small enough that rewriting it is a known, bounded task, and then let it be as vendor-shaped as it wants to be.
I also do not treat lock-in as a reason to build the voice stack from scratch. You can assemble telephony, streaming speech recognition, a model loop and text to speech yourself. You will spend months rediscovering endpointing and then own an operational burden forever. Some captivity is a fair price for a platform that got you to a working agent in a fortnight. The point is to know exactly what you are paying, not to pay nothing.
How the migration actually goes
When I have moved an agent, the shape is always the same, and it borrows directly from the release discipline I ran on App Store and Play Console builds: never cut over blind.
Build the new agent on a second, unpublished number. Point it at the same n8n webhooks, since the back half does not change. Run the frozen regression set against it, which is the moment you find out that a phrase which worked on the old platform gets interrupted on the new one. Tune the endpointing while listening to real calls to the test number.
Then cut over by changing where the client's number forwards, which takes seconds and reverses in seconds. Read the first twenty live calls yourself. Keep the old agent paid for and reachable for two weeks, because the rollback you can actually perform is the only rollback that counts.
The whole thing lands somewhere between three days and two weeks depending on how much tuning the old agent had accumulated. The uncomfortable part is never the agent. It is the reporting nobody remembered was built on the old platform's analytics.
The short version
Lock-in on a voice platform is not about the prompt, and worrying about the prompt is what lets the real exposure build up quietly. The client's phone number, the post-call automation, and a year of call history are the assets. Keep the first two outside the vendor and accept that you will lose the third.
Then stop thinking about it. Pick the platform that makes the agent good, keep the boundary clean, and spend the energy you saved on the calls themselves.
I build production AI voice agents and the automation, CRM and telephony layer behind them for founders across the US, UK and Europe. More about my work here, or book a call.