Rent the Engine, Own the Fuel
08 Jul 2026There’s a discipline I’m trying to enforce on how we use AI, and the vendor makes it inconvenient on purpose: keep the context in a tool they don’t own.
We’ve built out a lot of AI infrastructure: routines, agents, a whole knowledge layer our tools read from every morning. The path of least resistance is to keep all of it inside the AI vendor’s own ecosystem. Their projects, their memory, their storage. It’s right there, it’s integrated, it’s easy.
Every week the easy path tempts us, and every week we try to hold the line.
Everything that matters (the project context, the decisions, the accumulated knowledge) lives in a neutral tool instead, and our AI reads from there. Not because that tool is perfect, but because the day we want to swap out our AI vendor, or run a second one alongside it, or the pricing changes, or something better comes along, we don’t want to lose our entire operational memory on the way out.
I want to make the case for why, and then show you the actual mechanics, because the mechanics are the part that turns this from a nice principle into something you can walk away with.
The lock-in we already know
We talk a lot about vendor lock-in with databases and cloud providers. You know the shape of it: your data goes in, and getting it back out is technically possible but expensive, slow, and full of little incompatibilities that make you think twice. You stay not because it’s best, but because leaving costs more than tolerating.
We’re about to relearn every one of those lessons with AI, except faster and with higher switching costs. And here’s the part that’s different, the part I think a lot of people are going to miss until they’re already stuck: this time the vendor doesn’t just hold your data. It holds the context that makes your workflows work.
Data lock-in vs. context lock-in
Database lock-in is about rows and schemas. Painful, but at least it’s tangible; you can export a table.
Context lock-in is stickier, because the valuable thing isn’t a file you can dump. It’s the accumulated layer your AI reads from to be useful: the project background, the decisions and why you made them, the way your team talks, the standing instructions, the “here’s how we do things here” that took months to build up. When that lives inside a vendor’s projects-and-memory features, you can maybe export the raw text, but you can’t export the wiring: the retrieval, the way it’s structured for the model to use, the connections between your tools and that knowledge. Leave, and you’re rebuilding all of it from scratch inside the next vendor’s ecosystem.
That’s the trap. It doesn’t feel like lock-in while you’re in it, because everything’s convenient. It only reveals itself the day you try to leave, and by then the context is deep enough that leaving feels impossible. That’s the difference between “we switched” and “we can’t switch.”
The practice
Two moving parts, and the second is the one that matters.
One: the brain lives in a neutral tool. For us that’s Notion. All the project context, decisions, and accumulated knowledge live there, not in any AI vendor’s project or memory feature. Notion isn’t perfect and it isn’t some libre ideal; it’s a proprietary SaaS, and I want to be honest about that. But it’s neutral in the one way that counts here: it doesn’t belong to our model vendor. Our AI reads from it; it doesn’t live inside it.
Two (and this is the real unlock): the AI connects to that brain over an open protocol, not a proprietary integration. The protocol is MCP, and all you really need to know about it is what it does: it’s the standard connector that lets any AI client plug into our Notion brain and read from it. Think USB-C for AI. Because it’s an open standard rather than one vendor’s private wiring, the connection doesn’t belong to any one model vendor.
That’s the whole ballgame. The day we add a second model alongside the first, or switch entirely, the new client plugs into the same brain through the same connector, and all the context comes along for free. No rebuild. No re-wiring. No re-teaching.
And that’s the difference between keeping your data somewhere neutral (good, but not enough on its own) and keeping your access pattern neutral too (the actual escape hatch). Plenty of people store their data outside the vendor and still get locked in, because the way the AI reaches that data lives inside the vendor’s ecosystem. An open connector moves that part out into the open.
The bonus: humans can read it too
Here’s a benefit I didn’t fully anticipate until we were living in it. When your context lives in a normal tool like Notion instead of inside an AI’s opaque memory, people can use it directly, not just the model.
We can open the brain and read it. We can review what’s in there, correct something that’s wrong, and see exactly what our agents are working from. We can share a page with a teammate who doesn’t touch the AI at all. New folks can onboard by reading the same knowledge base the agents read. It’s version-able, linkable, searchable by a human on a Tuesday afternoon.
Compare that to context trapped in a vendor’s memory feature: you often can’t see all of it, can’t easily audit it, can’t hand a clean copy to a colleague. The knowledge exists only as fuel for one model, in a form only that model consumes.
Putting the brain in a human-readable, human-editable tool means it serves double duty: operational memory for the AI, and living documentation for the team. That alone might justify the setup even if portability never mattered.
Yes, it’s less convenient. On purpose.
I won’t pretend this is free, and this is exactly why it has to be a discipline rather than a one-time setup. Staying inside one vendor’s ecosystem is genuinely easier; it’s integrated, it’s one login, the memory “just works.” What we’re doing is slightly less convenient every single day. There’s a little more setup, a little more plumbing, a few things that would be one click if we’d just surrendered to the walled garden. The pull toward the easy path never goes away, which is why holding the line has to be a habit, not a decision you make once and forget.
The obvious objection is that this is premature optimization, that we’re paying a daily tax to hedge against a switch that might never come.
Here’s why I’ll take that trade anyway. The frontier model we use today probably won’t be the one we use in two years. I’d bet real money on that. The pace of change makes vendor churn not a tail risk but close to a certainty. So we’re not hedging against something unlikely; we’re preparing for something we expect to happen. A small, steady cost now versus a catastrophic, can’t-actually-do-it cost later is an easy call once you believe the switch is coming. And I do.
So we treat our AI vendor as an interchangeable engine and keep the fuel somewhere neutral. The engine can be the best one on the market this quarter and a different one next quarter. The fuel (the context that makes any of it useful) stays ours.
The question worth sitting with
Are you building your AI stack so you could walk away from it? Or are you quietly locking yourself in one click at a time?
If you’re not sure, here’s the test: imagine your vendor doubles their price tomorrow, or a clearly better model ships from someone else. Could you move by the end of the week with your context intact? Or would moving mean rebuilding months of accumulated knowledge from scratch?
Your answer to that is your real lock-in status. Everything else is convenience talking.