# Vendor Lock-In

> Wiring your agent directly to one provider's SDK — so switching providers costs you a rewrite.

- **Category**: Agentic AI
- **Subcategory**: Anti-Patterns
- **Canonical URL**: https://designpattern.fyi/patterns/vendor_lock_in/

---

## Description
**Intent**: Calling one provider''s SDK directly throughout application code — request shapes, streaming format, tool-call contracts — with no adapter layer.

**Context**: One provider offers a useful feature, the SDK is right there, and there''s "no immediate plan for a second provider." Fast-forward 18 months: the provider has an outage, raises prices, or a better model ships elsewhere. Switching is now a rewrite.

**Solution**: Use a provider-agnostic abstraction from day one: Vercel AI SDK, LiteLLM, Mastra''s provider/model string, or OpenAI-API-compatible adapters. Keep provider-specific features behind capability flags, isolated in feature modules — not threaded through the agent loop. See provider-string-routing, provider-fallback, multi-model-routing.



## Use Cases
- Never as a deliberate choice; if you must bind to one provider for a feature, isolate the binding behind a feature module.
- Treat the provider as a swappable adapter from the first commit; retrofitting abstraction later is expensive.
- Even single-provider deployments benefit from an adapter — outages and price changes do happen.






## Trade-offs




### Considerations & Drawbacks

- Provider outage = full application outage with no fallback

- Benchmarking against rival providers is a fork-and-rewrite project

- Compliance moves (regional providers, sovereign inference) require invasive rewrites

- Negotiating leverage with your incumbent erodes as switching cost grows







---
**Reference**: [Original Source](https://www.agentpatternscatalog.org/patterns/vendor-lock-in/)