When you start building an AI agent, the path of least resistance is to call one model’s API directly. OpenAI’s SDK is right there. Anthropic’s is simple. You’re moving fast, the demo looks good, and coupling to a specific provider feels like a problem for future-you.
Future-you will not be happy.
Why provider lock-in hurts
Model capabilities change fast. The best model for your use case in January might not be the best in June — and it almost certainly won’t be in two years. If your agent is tightly coupled to a specific provider, every model switch becomes a refactor.
Pricing changes too. Inference costs have dropped dramatically year-over-year, but not uniformly across providers. If you can’t swap models without touching core logic, you can’t optimize costs without risk.
Then there’s reliability. No provider has 100% uptime. When Claude is slow or GPT has an outage, a model-agnostic system can fail over. A provider-locked system just fails.
The abstraction you need
Model-agnostic design means one thing: your agent’s core logic never imports a provider SDK directly. Instead, it talks to an interface — call it a model client, a provider adapter, whatever you like — and that interface handles the translation.
The interface should cover three things:
1. Completion — send messages, get a response. The shape of the input/output should be the same regardless of provider.
2. Tool calling — send tools (function definitions), get back tool calls. Every major provider supports this now, but the schemas differ. The adapter normalizes them.
3. Streaming — if you need it. Delta format varies across providers; the adapter smooths that out too.
With this in place, switching from Claude to GPT to Llama is a config change, not a rewrite.
MCP and the connector layer
The Model Context Protocol takes this further. MCP is a standard for how models talk to tools — not just a convention in your codebase, but a protocol that any compliant model and tool can speak.
If your agent’s tool connections are MCP-native, they’re automatically compatible with any model that supports MCP. You’re not just abstracting the model layer; you’re abstracting the entire integration surface.
This is the direction the ecosystem is heading. Building MCP-first now is the same bet as building REST-first was in 2010: the standard will win, and early adoption compounds.
The practical rule
Write your agent logic so it knows nothing about which model is running it. The model name should appear in exactly one place: configuration.
If you ever find yourself writing if model == "claude" in your agent’s reasoning loop, stop. That’s the lock-in growing. Put it in the adapter, or better, fix the abstraction so the condition isn’t necessary.
Your agent’s job is to reason and act. The model’s job is to do the reasoning. Keep those concerns separated and you’ll thank yourself every time a better model ships.