You will be locked into something. Decide where it lands

Leon

• 2026-04-16

Ask a CIO about vendor lock-in and you hear about an exit. A migration that took a year. A renewal price that rose because leaving would have cost more than paying. So when the next platform decision comes around, in this case an AI platform, the instinct is to avoid commitment. Wait for the market to settle. Or build it yourself from open frameworks.

Neither one avoids lock-in. Waiting locks you into the backlog you have today. Building it yourself locks you into code your own team now has to run, connectors and permissions included. Any system that is useful collects your work: records joined across systems, rules for who sees what, tools people come to rely on.

That is the starting point of our new whitepaper, The vendor lock-in you always wish you had. It is written for CIOs and enterprise architects. Its claim is simple: lock-in is not optional, but where it lands is.

Avoiding lock-in is a lock-in too

This is not a new idea, and it is not ours. In 2019 Gregor Hohpe wrote Don't get locked up into avoiding lock-in on Martin Fowler's site. His point is that "avoiding being locked into one aspect often locks you into another." Choose Kubernetes over a proprietary container service and you are now locked into Kubernetes and its YAML files. He breaks lock-in into vendor, product, version, architecture, platform, skills, legal and mental lock-in. He also notes that open source can reduce the first of those, while most of the rest remain.

His sharpest point is economic. Lowering a switching cost is an option you pay for up front. If a switch has a 5% chance of happening and would cost $50,000, spending a lot more than $2,500 to bring that cost to zero is paying for insurance you do not need.

The argument keeps coming back on Hacker News. Peter Pistorius's SaaS is just vendor lock-in with better branding lists the taxes you pay for every service you bolt on and concludes: "No matter what choice you make, it's always going to be vendor-locked in." His fix is to pick one platform for everything. Several comments in the discussion under it point out that this is also lock-in, only more of it.

So the useful question is not whether you are locked in. It is what you are locked into, and whether you would mind.

Five layers, one test

The paper splits an AI platform into five layers where your work collects, plus the evaluation that comes before any of them:

Layer	What builds up	Lock-in to avoid	Lock-in worth having
Model	Prompts, tuning, habits	One provider's roadmap	Any model, as a setting
Data	Records and their links	Moved into their cloud	A synced copy, your servers
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 third column is where leaving costs you your own assets. The last column is where leaving costs only the work you chose to build. Every row has a cost. Only one kind holds your assets hostage.

The test the paper applies to 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.

This maps closely onto one of Hohpe's two by two models, which plots switching cost against unique utility. The paper's version is narrower. It asks which part of the switching cost is your own property.

The model should be the cheapest thing to change

New models arrive every few months, from different providers, in different regions. A platform built around one model inherits that model's roadmap, price and regions. Curiosity is not the model. It is what gives the model context, so in Curiosity Studio the model is configuration. Providers built in include OpenAI, Anthropic, Google, Mistral, Azure OpenAI, AWS Bedrock, and Ollama for open weights on your own servers. Anything else fits through an endpoint that speaks the OpenAI API, or a provider you write in C#.

Changing the model does not change the graph, the permissions or the tools your teams built. Permissions are resolved before the model is called, so Studio's built in tools only hand the model records the person asking may see, whichever model that is.

Nothing migrated in, nothing to migrate out

The data layer is where the year long migrations come from. In the paper's design, connecting a system copies what you map, keeps that copy in step, and links each node back to its source. Your ticketing system, your SharePoint and your network drives stay the system of record, with their own validation and audit trail. Nothing is switched off.

That changes what leaving means. Nothing was migrated in, so nothing has to be migrated out. Permissions follow the same rule: access is synced from each source and checked per record at query time. There is no second set of grants to drift while you stay, and none to rebuild when you go.

The runtime is the same choice. On premises, the copy stays in your environment and Curiosity holds none of it. You supply the encryption key and the certificate. With an offline license, local models and usage reporting switched off, a deployment can run air gapped. Whether renting or owning servers is cheaper is a separate question. David Heinemeier Hansson made the case against renting for companies with steady load in Why we're leaving the cloud. That is an opinion piece, and the cloud still suits plenty of workloads. The paper's point is narrower: you should decide where the runtime lives.

What you build lives in your git

The logic layer is the one people forget until they try to leave. Studio commits every configuration change to a git repository and can push it to your remote. Schemas, REST endpoints, the tools agents may call, agents and their prompts, and scheduled jobs all become files you can review, version 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. The audit trail is yours too: admins choose what is logged, and the files carry a hash chain you can verify and convert to CSV or JSON.

The objection: you will still be stuck

Here is the strongest objection, and Hohpe states it himself. The ideal quadrant of his matrix, high utility and easy to leave, is "a bit of an oxymoron." If a system gives you something no one else does, leaving it is hard by definition.

The paper does not dodge this. After a year your graph joins tickets to part records to supplier notices, across systems that never shared a key. Enrichment has pulled the identifiers out of field reports. Teams rely on tools they described in a sentence. Rebuilding that elsewhere is work, and work costs money. We would rather say so than claim there is no switching cost.

What the paper changes is what the cost is made of. Your records never left their source systems. Your permissions still live where they were set. Your graph runs on your servers under your key. Your schemas and agents are files in your git remote. So the cost of leaving is the value you built, and none of it is your data held hostage. That is the lock-in the title means.

Test the exit before you sign

The last chapter turns this into six questions to ask any vendor, us included:

Ask the vendor	The answer to worry about
Can we change the model?	A new contract
Where does our data live?	In our cloud
Who decides who sees what?	A second set of grants
Where is what we built?	In our environment
Can we try it first?	After a services phase
What happens if we leave?	A migration project

Ask them during the evaluation, not at the renewal. Then test the answers yourself. 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 check that nothing else changed.

The paper also has the record to answer path step by step, Curiosity's answer to each of the six questions, and a checklist for before you start. Read it on its page, or download the PDF. Stay because it works, not because you cannot leave.

Read the whitepaper (PDF)