The Exit Test: Can You Actually Leave Your AI Vendor?

There is a question you can ask in any AI architecture review that will change the temperature of the room in under a minute. It is not about models, benchmarks, or roadmaps. It is this: if we decided today to move this workload to a different platform, how long would it take, what would it cost, and how would we know the answers are still correct when we finished?

Most teams cannot answer any of the three parts. They can usually answer a fourth, unasked question — can we export our data — because storage portability was solved years ago, and open table formats made that particular fight boring. So the honest version of the answer sounds like this: we can get our data out, we have never tried to get anything else out, and we have no idea whether the system would still behave the same on the other side.

That gap is the whole subject of this essay. Choice, the fourth C in the framework this book is built on, is not a procurement clause and it is not a checkbox in a vendor questionnaire. Choice is a measurable property of an architecture, and like every other measurable property, it decays silently unless somebody tests it on a schedule.

The reason to care right now is timing. In 2026 a very large number of enterprises are moving from AI pilots to AI platforms. Pilots are disposable, so lock-in is irrelevant. Platforms are load-bearing, and every decision you make in the next two quarters will either preserve your ability to change your mind or quietly sell it. The teams that treat portability as a launch requirement pay a small, visible tax. The teams that defer it pay an enormous, invisible one, and they pay it at the worst possible moment — during a price renegotiation, a security incident, or a model deprecation they did not choose.

For a decade, lock-in was a storage argument. Whoever held the data held the customer, so the entire industry fought over formats, and open formats largely won. That victory was real, and it made a generation of buyers complacent, because they learned to check exactly one thing: can I get my bytes back.

In an agentic system, bytes are the least valuable thing you own. The valuable assets are the derived layers — the accumulated engineering that makes a general model useful in your specific organization. There are four of them, and every one of them is a plausible lock-in point.

The first is the retrieval index. Not the source documents, which you own, but the chunking strategy, the embedding model, the hybrid search configuration, and the reranking behavior that together determine what the model actually sees. Change any of those and retrieval quality changes with it. Embeddings are the sharpest edge here: they are model-specific vectors, and moving providers means re-embedding your entire corpus and re-tuning every threshold that was calibrated against the old vector space. Chapter 35 covers retrieval mechanics in detail, and every knob it describes is a knob that has to be re-tuned after a migration.

The second is memory. What the system has learned about your customers, your workflows, and its own past mistakes is often the single most valuable artifact your AI program produces, and it is frequently the least portable. Vendor memory stores tend to be opaque, schema-free, and export-hostile — not always out of malice, often just because nobody asked. Chapter 10 argues that institutional memory is the real moat, and Chapter 12 makes the case that a moat you cannot carry is a moat somebody else owns.

The third is tool contracts. Every integration your agents can call — every query interface, every write action, every internal service — is described somewhere in a format that a specific platform understands. If those descriptions live in a proprietary schema, your integration surface is not an asset you own. It is a rental. This is the specific problem open protocols were invented to solve, and it is why the protocol conversation matters more than the model conversation.

The fourth is evaluations. Your evaluation suite is the only thing standing between you and a silent quality regression, and it is the layer teams forget completely. If your evals live inside a vendor console, you cannot compare platform A to platform B without rebuilding your entire measurement apparatus first — which means you cannot switch, because you cannot prove the switch was safe. Chapter 29 treats evaluation as core infrastructure precisely because it doubles as your portability instrument.

The Exit Test is deliberately narrow, because broad questions produce broad answers and broad answers produce no action. It has one form: for a named workload, could a competent team move it to a different platform within ninety days, without loss of measured quality, using only artifacts we already possess?

Read that carefully, because every clause is load-bearing. A named workload, because portability is a per-workload property and averaging across a portfolio hides everything interesting. Ninety days, because an unbounded timeline makes every answer yes. Without loss of measured quality, because a migration you cannot measure is not a migration, it is a hope. And using only artifacts we already possess, because if the answer depends on a vendor cooperating with your departure, you do not have portability — you have goodwill.

Score the test on five artifacts, one point each. First: source corpus and its metadata, exportable in an open format. Second: chunking and embedding configuration, written down as code or config rather than clicked into a console. Third: memory store, exportable with a documented schema you can read without vendor tooling. Fourth: tool contracts, expressed in a protocol at least one other platform understands. Fifth: an evaluation suite that runs outside the vendor's environment and produces a number you would defend in a board meeting.

Five out of five means you have real optionality and can negotiate from a position of truth. Three or four means you have a project, not a crisis. Zero to two — which is where most enterprise AI programs sit in mid-2026 — means your platform decision is already permanent and nobody in the organization has noticed yet.

The most useful property of this test is that it is cheap. It takes an afternoon and produces a number that a chief information officer, a procurement lead, and an engineer will all interpret the same way. Chapter 19 makes the broader case that Choice has to be engineered rather than negotiated, and the Exit Test is the smallest possible instrument for finding out whether you did.

Once you have a score, convert it into money. Vendors price your switching cost with far more rigor than you do, and the asymmetry shows up in every renewal conversation. Building your own estimate is the fastest way to close that gap.

A switching-cost ledger has five lines. Re-indexing: the compute cost of re-embedding your corpus plus the engineering weeks to re-tune retrieval to the new vector space. Tool rewriting: the number of integrations multiplied by the average cost to re-express each one in a new schema, plus the regression testing each rewrite demands. Memory migration: extraction, transformation, and validation of accumulated state, which is usually the line item with the widest error bars because nobody has ever attempted it. Evaluation rebuild: zero if your evals are external, brutal if they are not. Human relearning: the retraining, prompt-pattern relearning, and productivity dip your team absorbs for a quarter.

Add them up and you get an exit price. Now compare that number to your annual contract value. If the exit price exceeds two or three years of spend, you are not a customer with alternatives. You are an annuity, and your next renewal will reflect that whether or not anyone says it out loud.

The reframing here matters more than the arithmetic. Lock-in is not a moral failing of vendors or a naivety of buyers. It is the predictable result of optimizing every individual decision for speed while never pricing the aggregate. Chapter 18 walks through the hidden costs of agentic AI, and switching cost is the one that never appears on an invoice — which is exactly why it grows unchecked. Chapter 21 gives the discipline for treating tradeoffs like this as explicit, priced decisions instead of accidents.

There is a failure mode on the other side of this argument, and it is worth naming before anyone over-corrects. Portability does not mean vendor neutrality at any cost, and the pursuit of perfect optionality produces its own category of expensive mistakes.

The first mistake is the abstraction layer nobody asked for. Teams build an internal wrapper so they can swap models freely, and the wrapper flattens every provider to a lowest common denominator. Six months later they are paying for premium models while using none of their distinctive capabilities, and the wrapper itself has become the thing they cannot migrate off. You have not escaped lock-in; you have insourced it and made it your own team's maintenance burden.

The second mistake is refusing every proprietary capability. Some vendor features are genuinely better and worth adopting. The correct posture is not abstinence, it is knowing the price. Adopt the proprietary feature, write down what it would cost to replace, and revisit that number at renewal. A documented dependency is a strategy. An undocumented one is a surprise.

The third mistake is confusing standards adoption with portability. Speaking an open protocol is necessary and not sufficient. If your tool descriptions are open but your memory is opaque and your evals live in a console, you are one fifth portable and will discover the rest under deadline pressure.

The synthesis is simple: be deliberately dependent. Pick the layers where depth beats flexibility, accept the lock-in there consciously, and defend portability ruthlessly everywhere else. Chapter 16 works through where open formats pay for themselves and where insisting on them is architectural theater.

Every property you do not test degrades. Backups that are never restored are not backups. Failovers that are never exercised do not fail over. Portability behaves identically, which is why the only credible way to hold onto Choice is to rehearse it on a schedule.

Run one drill per year, on one workload, with a seventy-two hour budget. Four stations. Export: pull the corpus, the retrieval configuration, the memory store, and the tool contracts using nothing but documented interfaces and your own credentials. Re-index: stand up retrieval on a second stack — a different embedding model and a different vector store are enough, and the second stack can be as cheap and temporary as you like. Re-evaluate: run your external evaluation suite against both stacks and record the delta per metric. Report: one page, three numbers — hours consumed, quality delta, and blockers found.

The point of the drill is not to migrate. It is to discover, in a low-stakes week of your own choosing, the things you would otherwise discover during a crisis. The findings are almost always the same and almost always surprising to the team that finds them. The memory export was undocumented. Fourteen tool definitions existed only in a console. The evaluation suite could not run without vendor authentication. Two retrieval parameters were tuned by someone who left the company and never written down.

None of those findings is a disaster in a drill. Every one of them is a disaster in a renewal negotiation. The teams that run this exercise annually describe the same second-order effect: after the first drill, engineers start designing for exportability by reflex, because they know they will be the ones standing at the export station next year. Chapter 34 treats multi-agent architecture as an engineering discipline; the drill is what turns portability from an aspiration into part of that discipline.

The strategic argument for all of this is not defensive. Teams who take portability seriously talk about it as insurance, and insurance is the least interesting thing it buys.

The interesting thing is speed. An organization that can move a workload in ninety days can adopt a better model the quarter it ships instead of the year after. It can run two platforms in parallel during an evaluation instead of committing on a slide deck. It can negotiate on the merits, because both sides know the alternative is real. Every one of those advantages compounds, and they compound faster in a market where the frontier resets every few months.

There is also a quieter benefit. The artifacts that make you portable — documented retrieval configuration, exportable memory with a real schema, tool contracts in an open protocol, evaluations that run anywhere — are the same artifacts that make you good. They are what a mature context layer looks like from the outside. Nobody builds them purely for portability; they build them because a system whose behavior is written down is a system you can improve. Portability is the side effect of engineering discipline, which is why the Exit Test doubles as a maturity test.

So the closing question is not whether your vendor is trustworthy. Most of them are. The question is whether your architecture would survive being wrong about that — and whether you would find out in a drill you scheduled, or in a renegotiation someone else scheduled for you.