Navigating Vendor Lock-in and Keeping Control of your Data

AI assistance note: Hate reading AI slop? This article was rated 100% human written by Substack and Pangram. We used some AI assistance to structure our thoughts, but the ideas and opinions are entirely ours. Rest assured, you are not wasting your time reading slop.

Vendor lock-in is often viewed as something to avoid at all costs. But locking into a platform sometimes offers a good trade-off and is not necessarily a bad thing. Subscribing to a managed service gives you speed, reduces what you have to manage, and leaves the maintenance to someone else. So it's not about having zero lock-in, but rather being deliberate about it and knowing exactly what you are trading away.

The problem often occurs when you sign up for a platform without knowing what is exportable or portable if you ever want to leave and get accidentally locked-in. It is crucial to understand that “owning” your architecture does not always mean self-hosting. You can rent or subscribe to a managed service and still own your intellectual property, provided you can export it in the formats you need.

You also cannot solve the lock-in problem by simply selecting a vendor that advertises itself as “open”. While open tools are great, whether a platform is truly open depends entirely on what you walk away with when you decide to switch.

We look at the different layers of the architecture, where it is better to rent vs own and the questions to ask when making vendor decisions.

Consider a mid-size insurance company building a small claims triage agent. This agent reads incoming claims, summarizes them, flags suspicious ones, and drafts an initial response. Imagine they build this entirely on a single vendor’s platform, and the agent goes live and works well.

Two years later, a competing architecture hits the market that appears to do the same job just as accurately for roughly 40-50% less money. Because the company has a month-to-month contract, switching looks like a simple decision on paper. In reality, the switch is incredibly difficult. If their prompts were tuned to the original model, they have to figure out how to move them. If their data is stored in the vendor’s vector store, they need to know if they can export the embeddings or just the raw text. Without a solid set of evaluations, or “evals,” they also cannot easily prove that the new model will produce safe and accurate outputs.

Proving the new setup is safe would require re-tuning prompts, re-embedding two years of data, and building evals from scratch. This amounts to months of work before anyone can sign off on a system that is already live. Consequently, the company is trapped the moment a switch becomes too expensive to prove it is safe.

To avoid the trap of vendor lock-in, you have to check the different parts of your architecture and decide what to keep on your side. For example, if we look at an agent built with LangGraph, the framework handles the orchestration, branching, and tool calls. However, everything truly valuable sits outside of that framework.

You need to ask specific questions about each layer to determine what you should rent and what you should own.

• The Model (Rent it): You do not need to build your own large language model. Models are highly swappable, but only if you own the surrounding layers. Even a simple swap usually requires re-tuning prompts to the new model. This is less of an issue when your prompts are versioned locally and your evals can prove the quality holds.

• The Interface (Own it): Instead of calling a model directly from your code, put a gateway layer like LiteLLM in between. This turns a model switch into a simple configuration change. It also provides resilience, access control, and observability.

• Prompts and Context (Own it): Your prompts are your intellectual property, and it takes months of tuning to get them right. They need to be versioned and kept in a repository or database you control so they remain portable. Additionally, while a model has general knowledge like say accounting principles, it does not know your specific standard operating procedures (SOPs) like the specific way your company closes its books or prices a deal, the small shortcuts that make the process work etc. You must carefully decide how much of your specific business context you are willing to hand over.

• Data and Embeddings (Own it): This is the heaviest area of lock-in and the hardest thing to move. If you decide to leave a platform, you need to know if you can export the actual vector embeddings or just the raw text. If you only get the text, you will have to re-process and re-embed everything from scratch. You should keep your data in a store you can easily export from.

• Evaluations (Own it): Without a reliable eval suite, you cannot tell if switching models is safe. Your evals allow you to ascertain whether quality is retained during a switch. You must ensure you can download your eval set rather than being forced to manually copy and paste it if you leave an observability provider.

• Orchestration (Rent it): Frameworks like LangGraph or CrewAI save you a lot of time. Switching between them is not easy, but you will not do it very often. The key is to keep your prompts, data, and evals outside the framework so they remain in your control.

The approach companies take to these architectural choices often depends on the scale of the company. Larger companies tend to focus heavily on governance and security when making platform decisions. Major vendors like Amazon, Google, or Microsoft provide the compliance and security backing that enterprise decision-makers require, such as adherence to the EU AI Act. This reliance on governance creates its own kind of lock-in, as it forces companies to choose between a secure, governed architecture and the raw innovation of a smaller startup platform.

Conversely, smaller companies are often more pragmatic. They are highly focused on the final output and frequently use tools like n8n to integrate AI into specific workflows. While they still care about compliance, they prioritize getting results quickly.

You cannot own every part of your architecture from day one. You have to think about which parts are the most expensive to switch. Usually, data, evaluations, and prompts hold the most intellectual property and carry the highest switching costs.

To maintain control, you should ask three questions of any vendor:

• Can I export my vectors, or do I only get text?

• Can I take my prompts out as files?

• Do my evals run against another model, or only the one this framework uses?

If the vendor supports open standards, make sure that does not just mean data is portable only in their specific format. Do not over-engineer a massively portable system, but do deliberately accept the lock-in you choose. When you present your architecture and business case, you want to show that you made informed decisions, rather than discovering a painful lock-in months down the line.

This article grew out of a live Chai & AI session led by Jacob Chacko where practitioners dug into vendor lock-in in agentic systems, and where people shared exactly how it plays out inside large enterprises. These sessions happen regularly and they get intense. It’s invite-only for course alumni, but we’ll keep sharing highlights here every week.