Vendor lock-in used to mean your database — the thing your data lived in and couldn't easily leave. AI has a quieter version of the same problem. Your prompt formats, your function-call schemas, the proprietary features you leaned on — these are the parts that weld you to one provider. And because the model landscape moves fast, that weld gets expensive the moment a better option appears.
The new lock-in
Every major AI provider has its own way of doing things. Anthropic's system prompt conventions differ from OpenAI's. Tool-call schemas are encoded differently across providers. Proprietary features — built-in web search, caching quirks, vision handling — are designed for one platform and don't travel.
None of this is malicious. It's just how products evolve. The problem shows up later, when you want to switch. What felt like a small implementation detail turns into a rewrite of every prompt, every tool definition, and every integration test. Teams that didn't plan for portability end up frozen on a model long after a faster, cheaper, or more capable one is available.
Three patterns we use
These aren't theoretical — they're the patterns we apply on every AI system we build. Each one trades a small amount of upfront structure for the ability to move freely later.
1. A thin provider abstraction
Route every model call through one internal interface — a small module or service whose job is to know which provider to talk to and how. The rest of your codebase calls that interface and never touches a provider SDK directly. Swapping Anthropic for OpenAI, or either for a local model, becomes a config change, not a refactor. This layer stays intentionally thin: no business logic, just translation.
2. Standardize tools via MCP
The Model Context Protocol (MCP) is an open standard for defining the tools and context an AI agent can use. When you define your tools once in MCP format, they work across agents and models instead of being re-encoded for each vendor's function-calling API. Your tools become a portable asset the same way a REST API is portable — any compliant client can use them. This also pays dividends when you add a second agent or a second model to your stack.
3. Own your prompts and evals
Keep your prompts version-controlled, written in plain language, and free of provider-specific formatting tricks. Then build a small eval set — a collection of inputs with known good outputs — that you can run against any model. When a new model ships, you run the evals first. If they pass, you ship. If they don't, you know exactly what broke and why. Evals turn a model swap from a leap of faith into a checklist.
The practical upside
Model prices have dropped by orders of magnitude over the past two years. Teams with portable systems captured every price cut — they just updated a config and kept shipping. Teams locked to a provider's specific API shape often missed those savings entirely because the migration cost wasn't worth it yet.
The same logic applies to capability upgrades. When a model comes out that handles your use case better, portable teams test and adopt in days. The abstraction layer pays for itself the first time you use it.
- — Ride price drops without a migration project
- — Adopt better models as they ship, not when a rewrite is finally worth it
- — Run multiple models side-by-side (fast/cheap for simple tasks, capable for complex ones) without forking your codebase
- — Have a real fallback when a provider has an outage
Want to build AI systems that last?
Gain AI designs AI workflows — and builds the software, websites, web apps, and mobile apps around them. From a first automation to a shipped product, one team.