Lock-In Is Fine. Lock-Out Isn't.

Everyone is terrified of the wrong kind of lock-in.

The fear is the model. If we build on vendor X's model, we're locked in. If vendor X changes the price, the terms, or the model itself, we're stuck. So the organization spends months building abstraction layers to avoid depending on any single model — and in the process, creates the lock-in that actually hurts: the lock-out from the ecosystem.

Let me be direct about this: model lock-in is mostly a myth, and the abstraction layer built to prevent it is usually the real trap. The models are interchangeable in the ways that matter. The thing you should actually be afraid of is being locked out of the tooling, the evaluation, and the operating knowledge that make any model work.

Why model lock-in is the wrong fear

Models change. That's not a risk, it's a fact, and it's the same fact that makes model lock-in survivable. The frontier model you use today is not the model you'll use in eighteen months, and that's true whether or not you build an abstraction layer, because the vendor changes their own model constantly. You are already on a moving platform. The question was never whether the model changes under you. It's whether you can verify the new model still works.

That's the insight that dissolves the lock-in fear: your real dependency isn't the model. It's the evaluation. If you can run your test set against a new model and see whether it's better or worse, switching is a weekend project. The eval set is the portable asset. It's your bargaining power over every model vendor, because it means you can leave when you want to.

The teams that are genuinely stuck aren't the ones on one model. They're the ones with no eval set — the ones who can't tell whether a new model is better, so they stay on the old one out of fear. That's lock-in. It's not the vendor's doing. It's the missing evaluation.

The abstraction layer doesn't protect you from lock-in. The eval set does. One is a pile of code that will rot. The other is the asset that makes every model a commodity.

The lock-out that's real

The lock-in to worry about is the lock-out: being unable to participate in the ecosystem around the technology.

The AI ecosystem is moving fast, and it moves through tooling. The evaluation frameworks, the observability tools, the orchestration standards, the MCP-style connectors, the community practices — this is where the operational knowledge lives. A team that builds its own bespoke everything, insulated from the ecosystem in the name of avoiding lock-in, is a team that has to reinvent every improvement the ecosystem ships.

That's the expensive lock-in. It doesn't show up in a contract. It shows up as the team that's six months behind on every practice, because their custom layer doesn't connect to anything. They weren't locked in by a vendor. They locked themselves out.

What to standardize, what to marry

The split is clean, and it's the same split as every other platform decision.

Standardize the portable layers: evaluation, prompts, and telemetry. These are your assets. They encode your quality bar, your domain knowledge, and your operating history. They should be in formats that work anywhere — plain test files, plain prompt files, plain logs. These are the things you own, and the things that make switching possible. Invest here without guilt.

Marry the commoditized layers: the model APIs, the vector stores, the orchestration frameworks. These are interchangeable. If a vendor changes their price or their model, you should be able to swap them with a reasonable amount of work — and the reasonable amount is defined by your eval set and your prompt portability, not by an abstraction layer that tries to hide every vendor behind a fake-identical interface.

The abstraction layers that cause the most pain are the ones that try to make every vendor identical. They don't. They just add a layer of bugs, a layer of version drift, and a layer of teams who can't use the vendors' best features because the abstraction doesn't expose them. Build the thinnest possible integration to each vendor, keep your eval and your prompts portable, and treat the vendors as what they are: replaceable.

The test for your setup

Ask two questions. Can you run your evaluation against a different model this week? And does your team know the ecosystem tooling, or only your internal wrappers?

If the eval runs clean against another model, you're not locked in. If your team can walk into a new tool's docs without a training course, you're not locked out. The first question protects your future. The second protects your competence.

The model you use today will not be the model you use in two years. That's fine. What matters is whether the knowledge you've built — your eval set, your prompts, your operating practices — moves with you. Lock-in is a myth when you own your evaluation. Lock-out is real when you insulate yourself from the ecosystem.

Standardize what you own. Marry what's replaceable. And stop building the abstraction layer. It's protecting you from a fear that the eval set already solves.

Think this argument fits your event? Tell me about the room — the calendar is selective.