- Lock-in is not primarily a technical inconvenience; it determines your pricing power, continuity exposure, and compliance position, which are board-level concerns.
- The AI frontier moves fast, so the ability to switch or blend models is a source of ongoing commercial advantage, not a one-time procurement decision.
- Model-agnostic architecture means the vendor sits behind a boundary you control, so swapping a provider is a configuration change rather than a rebuild.
- The real cost of lock-in shows up at renewal, during outages, and when regulators or customers ask where data goes and which model touched it.
- A short set of pointed procurement questions exposes switching cost before you sign, when you still have leverage.
Most organisations decide how they will use AI agents long before they notice they have also decided who holds the leverage. The choice arrives dressed as a technical detail: a model provider, a cloud region, a framework, a set of convenient APIs. Each looks like a sensible engineering call made under deadline. Stacked together, they quietly determine something the board actually cares about: how much freedom the business retains to change its mind.
Lock-in is the accumulation of those choices into a position you cannot easily leave. It rarely announces itself. It shows up later, at the moments when you have the least room to manoeuvre: a renewal negotiation where the vendor knows you cannot walk, an outage that stops a revenue-generating process, a regulator asking where your data was processed, or a competitor adopting a newer model while you are still tied to last year's. By then the cost of switching is no longer a technical estimate. It is a business constraint.
The reframing that matters is simple. Lock-in is not mainly about code that is hard to move. It is about pricing power, continuity, compliance, and the pace at which you can adopt what is better. Those are commercial questions, and they belong on the executive agenda, not buried in an architecture diagram.
What lock-in actually costs the business
It helps to separate the exposure into the outcomes a board already tracks, rather than the technical mechanisms underneath them.
- Pricing power. When a vendor knows switching is impractical, your renewal is negotiated from weakness. Prices tend to move in one direction once the cost of leaving is high enough, and the increase need not be dramatic to matter across a growing volume of usage.
- Continuity. If one provider's availability, rate limits, or policy changes can halt an operation that customers or revenue depend on, you have concentrated a business risk in a party you do not control.
- Compliance and data residency. Where data is processed, which jurisdiction governs it, and whether a given model may see certain information are increasingly contractual and regulatory questions. Being unable to move workloads is being unable to answer them.
- Pace of adoption. The capability frontier moves quickly and unevenly. If you cannot adopt a stronger or cheaper model when it appears, you inherit your vendor's roadmap and their timing instead of your own.
None of these require anything to go wrong technically. They are the ordinary consequences of holding a weak hand, and they compound as the business relies on the system more heavily.
Model-agnostic architecture, explained in business terms
The technical answer to this exposure has a name that sounds like plumbing: model-agnostic, or portable, architecture. The commercial meaning is straightforward. You put a boundary between your business logic and any single provider, so the provider sits behind an interface you own rather than being woven through everything you have built.
Think of it the way a well-run company treats any critical supplier. You do not pour your operations into a single source with no alternative and no way to compare. You keep the relationship at a defined boundary, you retain your own records and processes, and you preserve a credible path to a second source. The AI equivalent is keeping your data, your orchestration logic, and your evaluation criteria in your own hands, while the model itself remains a component you can swap. When done well, changing providers becomes closer to a configuration change than a rebuild.
Portability is not a technical luxury. It is the difference between negotiating with a supplier and being administered by one.
This is not an argument against committing to a vendor. Depth of commitment is often how you earn better terms and support, and constant switching would be its own kind of waste. The point is to commit deliberately: to know the exit cost before you sign, and to ensure no single provider's pricing, outage, or policy shift can dictate terms to the business. You can lean heavily on one supplier and still hold the ability to leave. Those two things are not in tension when the architecture is designed for it from the start.
The questions a CFO or CEO should ask
Switching cost is easiest to assess before you sign, while you still have leverage and the vendor still wants the deal. These questions are deliberately non-technical. You do not need to understand the implementation to hear whether the answers are evasive.
- If we wanted to move to a different model or provider in twelve months, what specifically would we have to rebuild, and who bears that cost?
- Where is our data processed and stored, under which jurisdiction, and can we change that without re-architecting the system?
- What happens to our workloads, and our access to our own data, if we stop paying — during the contract and after it ends?
- Can we run more than one model behind the same process, so we are not exposed to a single provider's outage or price change?
- How would we adopt a newer or cheaper model when one appears, and does that decision sit with us or with the vendor?
- What is the exit path — data export formats, notice periods, transition assistance — and is it written into the contract rather than promised in a conversation?
A confident supplier answers these plainly, because a well-built system has good answers. Evasion, or a retreat into technical language meant to end the conversation, is itself information. The vendors most worth working with tend to be comfortable telling you exactly how you would leave, precisely because they intend to keep you by being good rather than by being inescapable.
The decision in front of you
As agent systems move from pilots into the operations a business actually runs on, the cost of being unable to switch rises with every process that comes to depend on them. The sensible time to protect optionality is early, while the system is still small and the boundary is cheap to draw. Retrofitting portability after the business has grown around a single provider is possible, but it is the more expensive path, and it is usually undertaken under pressure rather than by choice.
The practical next step is not to tear anything out or to swear off vendors. It is to treat switching cost as a number you are entitled to know — a line item in any material AI commitment, owned jointly by the people who build the system and the people who sign for it. Put the six questions above to your current and prospective providers, and see how readily the answers come. The quality of those answers will tell you most of what you need to know about who is holding the leverage today, and whether you are comfortable leaving it there.
Common questions
Does staying model-agnostic mean we sacrifice performance or move slower?
Not if the boundary is designed well. A model-agnostic architecture routes each task to whichever model is best suited, so you can adopt a stronger model when one appears rather than being held to a single provider's roadmap. The discipline is in keeping the integration behind an interface you own, so switching is a configuration change rather than a rewrite. The cost is modest upfront design; the return is optionality as the frontier moves.
Is avoiding lock-in the same as never committing to a vendor?
No. Depth of commitment is often how you get better pricing and support, and switching for its own sake is wasteful. The goal is to commit with your eyes open: know the exit cost before you sign, keep your data and orchestration logic portable, and make sure a single provider's outage or price change cannot halt the business. You can lean heavily on one vendor and still hold the ability to leave.
Who should own this decision internally?
It is shared. Technical leaders own the architecture that makes switching feasible, but the risk itself is commercial, so finance and the executive team should treat switching cost as a line item in any material AI commitment. Procurement, legal, and compliance all have a stake in data residency and exit terms. Treating it purely as an engineering matter is how the exposure stays invisible until renewal.