Lock-in is a trade-off. Choose it on purpose
Leon
Ask a CIO about vendor lock-in and you hear about an exit. A migration that took a year. A renewal price that went up because leaving cost more than paying. So when an AI platform decision comes around, the first instinct is to avoid commitment: wait for the market to settle, or build it yourself from open frameworks.
Our new whitepaper, The vendor lock-in you always wish you had, is written for CIOs and enterprise architects. Its claim: every option locks you in somewhere, so lock-in is a trade-off. Choose it on purpose. The first half of this post is about platforms in general. The second half is how Curiosity handles each trade-off.
Every option locks you in
Any useful system collects your work: records joined across systems, rules for who sees what, tools people rely on. That includes the two ways of avoiding a vendor.
Waiting locks you into the backlog you have today.
Building it yourself locks you in twice. First, you are locked into maintaining what you built. Your team has to run it, patch it, upgrade it and fix it when something around it changes. The connectors, the permissions and the audit trail are yours to build and keep working. Second, you are locked into every part you chose, open source included. Open source means you can read, change and run the code. It does not mean anyone keeps it up to date. You depend on the maintainers to fix security problems and support new versions of the parts around it. If they slow down or stop, you take over the work yourself or change your system.
Gregor Hohpe made the general point in 2019 in Don't get locked up into avoiding lock-in: "avoiding being locked into one aspect often locks you into another."
Five layers, one test
The paper splits an AI platform into five layers where your work builds up, plus the evaluation that comes before any of them. This table is general: it applies to any platform.
| Layer | What builds up | Lock-in to avoid | What to look for |
|---|---|---|---|
| Model | Prompts, tuning, habits | One provider's roadmap | Any model, as a setting |
| Data | Records and their links | Their cloud, their format | A synced copy, readable export |
| Permissions | Who may see what | A second set of grants | Synced from each source |
| Logic | Schemas, tools, agents | Only inside their sandbox | Files in your git remote |
| Runtime | Servers, keys, operations | Their cloud, their key | Your servers, your key |
| Evaluation | Proof that it works | A services phase first | A free install, your data |
The test for each row: would you stay if leaving were free? Good lock-in passes. You stay because the system does its job. Bad lock-in fails. You stay because leaving means a migration, a second set of permissions to rebuild, and tools that only ran in someone else's environment.
How Curiosity handles each layer
From here on, this is Curiosity Studio only.
The model is a setting. Curiosity is not the model. It gives the model context. Providers built into Studio include OpenAI, Anthropic, Google, Mistral, Azure OpenAI, AWS Bedrock and Ollama for open weights on your own servers. Any endpoint that speaks the OpenAI API works, and you can write a provider in C# for any other API. Changing the model does not change the graph, the permissions or the tools your teams built.
Your data exports in a readable format. Customer data belongs to the customer. Vendors hold it in three common ways: proprietary formats, interfaces that make export slow ("download one record at a time"), and contract terms that claim the schema as the vendor's property. In Curiosity, your data and your schemas can always be exported in full, in a format a person can read, such as JSON. The same goes for what you build on top: connectors, endpoints and front ends are files you can take and run elsewhere.
Your source systems stay the system of record. Connecting a system copies what you map and keeps that copy in step. Each node links back to its source. Your ticketing system, your SharePoint and your network drives are never switched off, so nothing was migrated in and nothing has to be migrated out. Access is synced from each source and checked per record when a query runs, so there is no second set of grants to drift. On premises, the copy stays in your environment and Curiosity holds none of it. You supply the encryption key and the certificate.
What you build lives in your git. Studio commits every configuration change to a git repository and can push it to your remote. Schemas, endpoints, the tools agents may call, agents and their prompts, and scheduled jobs are files you can review and import back. Extensions are kept as source and compiled by Studio, so an upgrade that breaks one shows a compile error, not a silent failure.
You will still be locked in. After a year your graph joins tickets to part records to supplier notices, across systems that never shared a key. Rebuilding that elsewhere is work, and work costs money. With Curiosity, the cost of leaving is made of the value you built. Your records stay in their source systems, and your data and schemas export in a format you can read.
Six questions for any vendor
Ask these during the evaluation, not at the renewal. Ask us too.
| Ask the vendor | An answer that should worry you | Curiosity's answer |
|---|---|---|
| Can we change the model? | A new contract | A setting |
| Where does our data live? | In our cloud, in our format | Your servers, readable export |
| Who decides who sees what? | A second set of grants | Your source systems |
| Where is what we built? | In our environment | Your git remote |
| Can we try it first? | After a services phase | Free, no time limit |
| What happens if we leave? | A migration project | Your sources never moved |
The developer version of Studio is free for up to ten test users, with no time limit for
development use. On macOS and Linux, curl -fsSL https://curiosity.ai/install.sh | bash starts it
in a container, and Windows has an installer. The paper suggests three steps: install it on one
machine you control, connect one system your teams already argue about, then change the model and
export a dataset to check that nothing else changed.
The paper has the record to answer path step by step and a checklist for before you start. Read it on its page, or download the PDF directly.
Further reading
- Don't get locked up into avoiding lock-in, Gregor Hohpe on martinfowler.com. Lock-in broken into eight kinds, two simple models, and the economics of paying to lower a switching cost.
Read next
Articles on context graphs, enterprise search and industrial AI
