Persistent memory without vendor lock-in: why your AI shouldn't rent its memory
Most AI products rent their memory from the same vendor that provides the model. That's a dependency and a risk. There's an alternative.

Most AI applications have a blind spot: they rent their memory from the same vendor that gives them the model. The history, the context, what the system "knows" about the user, lives within the vendor's platform. It works—until it doesn't.
The model is commodity; the memory is yours
Models are becoming interchangeable and increasingly cheaper. What isn't commodity is what your system accumulated: the memory, the context, the continuity with each user. That's the part that delivers value and costs to rebuild. Having it in your own infrastructure—your database, your vectors—changes the entire equation.
What you gain when the memory is yours
It's not ideology; these are concrete benefits:
- Portability. If memory lives in your infra, you switch models—cloud to local, one provider to another—without losing what the system learned. The model becomes a replaceable piece.
- Data sovereignty. Memory usually contains the most sensitive information: what the user shared, what the system inferred. Having it in your infrastructure is a privacy and compliance decision, not just a technical one.
- Durability. If tomorrow a provider raises prices, changes policies, or shuts down, your memory survives. You don't depend on a third party continuing to exist.
- Cost control. With memory decoupled, you route to the cheapest model that fits and reserve the expensive ones for what truly needs them.
- Continuity. Changing models isn't starting from scratch. The entity remains the same because its memory—not its model—is what defines it.
If your AI "forgets everything" when you switch providers, you didn't have memory: you had a dependency.
The cost of not doing it
Lock-in rarely feels bad on day one. It hits when the vendor changes something you don't control—a price, a limit, a policy—and you discover that all your continuity was hosted in their house, not yours. Migrating then isn't switching an API: it's trying to recover a memory that was never fully yours.
The questions this opens
- As models improve generation after generation, how do you version and migrate a memory so it survives any model?
- What's the right architecture for a memory layer designed to outlast the model that queries it?
- If memory is the durable asset and the model is replaceable, where's the real moat of an AI product?
Our bet—and we built it this way, local-first—is that the answer starts with not renting what you shouldn't: your memory, your identity, your continuity. Rent the model. Keep the memory yours.
