The conversation your leadership team is having about AI vendor lock-in is probably the wrong conversation. It's focused on the model layer — OpenAI's pricing, Anthropic's API reliability, the risk of a single provider dependency. That's a real concern. It's also roughly five years behind where the actual problem has moved.
The lock-in that will cost you a full architecture rewrite isn't happening at the model layer. It's happening underneath it, in the orchestration runtimes, memory stores, tool-calling schemas, and embedding pipelines that your agents depend on to function. By the time it becomes visible — when you try to migrate a model, deprecate an agent workflow, or switch cloud providers — you won't be negotiating a contract term. You'll be staring at a system where your operational intelligence is stored in formats you don't fully control, your workflow logic is entangled with a framework's proprietary idioms, and the path forward costs three to five times what building it right would have.
Model providers understand this. Margins on inference are compressing, open-source alternatives are closing the capability gap faster than anyone predicted, and no one has a durable lock on model quality. So they're building the stack beneath your stack. AWS Bedrock's agent framework, Google's Vertex AI Agent Builder, Microsoft's Azure AI Foundry: these aren't convenience wrappers. They're infrastructure-level hooks designed so that by the time you want to swap the model, the model is the least of your migration problems.
Why Agentic Systems Are Structurally Different
Most of the intuitions engineers carry about LLM integration were formed in the era of stateless API calls. You send a prompt, you get a response. The model is interchangeable in roughly the same way a REST endpoint is interchangeable — change the URL, update the auth headers, adjust the response parsing, done.
Agentic systems break every part of that mental model.
An agent running a multi-step workflow maintains memory across sessions, executes against a tool registry it consults to decide what actions are available, carries a plan it's executing across potentially dozens of sequential steps, and has been behaviorally tuned through months of prompt engineering to act in ways specific to your domain. None of that state is ephemeral. It lives somewhere. And where it lives, in what format, and under whose control determines whether you actually own the operational system you think you're building.
The agentic stack has five distinct layers, each with its own lock-in profile:
| Layer | Lock-in Risk | Why |
|---|---|---|
| Compute | Medium | Similar to cloud infrastructure migration — painful but well-understood |
| Orchestration | High | Tool definitions, agent logic, and task sequencing are written to framework-specific idioms that don't transfer cleanly |
| Context (memory, RAG, embeddings) | Highest | Data formats and embedding schemas representing your operational knowledge are often tied to a specific provider's model |
| Observability | Medium–High | Tracing and eval pipelines built around one provider's telemetry schema become migration blockers |
| Security & access control | Medium–High | Agent permission models vary significantly across frameworks; almost universally underprioritized at build time |
Most companies, when they think about vendor risk, are thinking about one of these layers. Usually compute. The other four are accumulating switching costs while no one is watching.
The Invisible Assets You're Accumulating
In traditional software, your intellectual property lives in code you own, version-control, and can inspect. In agentic systems, a meaningful portion of your operational intelligence lives outside that category entirely — and most engineering organizations haven't updated their build decisions to reflect that.
Consider what's actually accumulated after six to twelve months of running a serious agentic system:
- System prompts and prompt chains tuned specifically to one model's response characteristics
- Agent memory stores persisted in a provider's proprietary schema
- Tool definitions written to a specific orchestration framework's spec
- Workflow state stored in a format with no documented export path
The embedding problem is the sharpest illustration of this. If your RAG pipeline was indexed using a provider-managed embedding model and that model is deprecated — or you determine a better one has emerged — you cannot reuse your existing vector index. You have to re-embed your entire corpus. If the original model was proprietary and you no longer have efficient bulk inference access to it, even the re-embedding process becomes a migration dependency. The knowledge base your agents rely on, the thing that makes them useful for your specific domain, is now contingent on a model you don't control, stored in a format that's meaningless without it.
This is not a theoretical edge case. AWS deprecated Titan Embeddings v1 in 2024. Model deprecation cycles are measured in months to a few years, not decades.
The Patterns That Preserve Portability
None of this means you should avoid building agentic systems, or that every architectural decision requires maximum defensiveness. Some integration depth is strategically rational — companies building durable competitive advantages are doing so through deep integration of AI into proprietary workflows and data feedback loops. The question isn't whether to allow any lock-in. It's which layers to allow it in.
The answer: accept integration depth in the layers that are differentiating for your business — your proprietary data, your domain-specific evaluation pipelines, your custom prompt engineering. Preserve portability in the commodity infrastructure layers — model selection, vector storage, orchestration runtime.
Two patterns make this operational.
The abstraction layer pattern is the most important one to implement early, and almost no one implements it early because it doesn't feel urgent until it is.
Rather than calling provider APIs directly from business logic, you build a thin internal interface between your application and the provider. Your business logic calls your interface in your schema. Provider adapters implement that interface for each vendor. Switching providers — or running two simultaneously for A/B comparison — means writing a new adapter, not refactoring application logic.
The upfront cost is one to two weeks of engineering for a team building their first serious agentic system. The payoff is full model-layer portability and protection against deprecations. It's the Repository Pattern applied to AI infrastructure: a well-understood principle that almost never feels urgent to implement and almost always costs more when skipped.
A minimal version looks like this:
# Your internal interface — business logic calls this, nothing else
class EmbeddingProvider(Protocol):
def embed(self, texts: list[str]) -> list[list[float]]: ...
# Adapters implement the interface, not the other way around
class OpenAIEmbeddingAdapter:
def embed(self, texts: list[str]) -> list[list[float]]:
return openai_client.embeddings.create(input=texts, model="text-embedding-3-large")
class CohereEmbeddingAdapter:
def embed(self, texts: list[str]) -> list[list[float]]:
return cohere_client.embed(texts=texts, model="embed-english-v3.0")When Cohere releases a better model, or OpenAI deprecates theirs, you write a new adapter. Your application logic is untouched.
The provider-agnostic memory architecture addresses the context layer, where the highest lock-in risk lives. The structure is straightforward:
- Raw source data always lives in storage you own — your database, your object store
- Embedding logic sits behind an interface, with the embedding model tracked as a versioned dependency, not an assumed constant
- The vector store is either self-hosted (pgvector, Weaviate, and Qdrant are all production-viable) or a managed service with a clean, documented bulk-export API
- Agents call an internal retrieval interface, not a vector store SDK directly
Neither of these patterns is exotic. Both require deliberate upfront decisions that feel unnecessary when you're trying to ship a demo. Both become obvious in retrospect when you're staring at a migration.
The Contractual Layer No One Is Reviewing
There's a dimension of this problem almost entirely absent from technical conversations about agentic infrastructure: the legal layer.
Enterprises spent the better part of a decade learning — through expensive mistakes — how to negotiate cloud infrastructure contracts: egress fees, data sovereignty clauses, SLA carve-outs, audit rights. Almost none of that institutional knowledge is being applied to AI infrastructure agreements. The questions that will matter when you try to migrate, when a vendor is acquired, or when a regulator asks for execution logs, are being answered right now in contract terms that procurement teams are signing without understanding what an agentic orchestration layer is.
The specific questions your legal and technical teams should be answering together before signature:
- Model weights: Who owns fine-tuned weights, and under what conditions can you export them?
- Memory store contents: Who has rights to the data persisted in agent memory, and what's the bulk export mechanism?
- Execution logs: What are your audit rights on agent execution traces? Are they retained, and for how long?
- Acquisition scenarios: What contractual protections govern your data and access rights if the vendor is acquired?
- Deprecation terms: What is the contractual notice period for model deprecation, and what SLA governs the transition window?
The Self-Optimizing Stack Problem
One more risk worth naming explicitly, because it's being actively marketed as a feature: agentic infrastructure that manages itself.
Major cloud providers are building AI-native tooling that can, in their framing, refactor dependencies, adjust routing, and optimize resource placement autonomously. The pitch is compelling. Who wants to manage infrastructure manually when the system can optimize itself?
The lock-in implication is structural, not incidental. If your infrastructure is self-assembling using a specific provider's agentic reasoning, the architectural decisions being made about your stack are being made by a system with no incentive to recommend portability and significant embedded incentive to deepen integration with that provider's own services. A system that optimizes for performance within a provider's ecosystem will, by definition, optimize for integration within that ecosystem. That's what optimization means when the optimization surface is bounded by one vendor's service catalog.
This is the current product direction of major cloud providers' AI-native infrastructure tooling. It deserves considerably more scrutiny than the industry is currently giving it.
What to Do This Week
If you're running agentic systems or actively building toward them, the most valuable thing you can do this week is an honest audit of where your current architecture sits on the portability spectrum — not the model layer, the other four.
Three specific questions to answer for each system:
1. Where does persistent state live? Identify every place your agents write or read state across sessions. Is it stored in a format you can export? In a system you can migrate away from without re-processing your source data?
2. What's your embedding dependency? Which embedding models are in use? Are they provider-managed? Do you have a documented path to re-embed your corpus if the model is deprecated or replaced?
3. What do your AI vendor contracts actually say? Pull the agreements and look specifically for bulk export rights, deprecation notice periods, and data ownership clauses for fine-tuned assets.
The abstraction layer and provider-agnostic memory architecture don't require an overhaul to start. They require a decision — made before you're under pressure — to treat AI infrastructure with the same engineering rigor you'd apply to any other dependency with real migration costs.
The teams that make that decision now will spend engineering time building. The ones that make it after a forced migration will spend it explaining to leadership why they're rebuilding something they already paid to build once.