Models are rented. Memory should be owned.

Summary

Frontier AI changes fast enough that the best model for a given job today is unlikely to be the best a year from now. Meanwhile, AI assistants increasingly keep long-term memory about the people who use them, and that memory is becoming the main cost of switching. We argue that vendors should compete on the quality of their models and the tools around them, and that the memory a person builds while using those tools should belong to the person, in a form they can move.

The economics literature has a blunt description of what switching costs do to a market: firms compete hard to win new customers, then charge more to the ones who can't easily leave [1]. Nothing about AI changes that logic. If anything, memory is a stronger lock than most, because it grows every day a person uses the product and is hard to rebuild by hand.

Memory is the new switching cost

Economists have long studied how switching costs create lock-in: once a customer has invested in learning or data tied to one supplier, the supplier can charge more or improve less [1]. In AI assistants, the investment is increasingly memory: preferences, projects, people and history that make the assistant useful. The longer you use one, the more it costs to leave.

Some vendors are starting to acknowledge this. Anthropic, for example, lets people bring memory over from other assistants by exporting it as text and importing it into Claude [2]. That helps, but a text summary exported from a vendor's internal store is lossy and chosen by the vendor. It isn't the same as owning the memory in the first place.

The frontier keeps moving

In the span of a couple of years, leadership on public model rankings has changed hands between labs repeatedly, context windows have grown by orders of magnitude, and the price of a given level of capability has fallen sharply. A choice of model that was right a year ago is a guess today. Anyone building on AI should assume they will want to change models more than once.

That makes long-lived memory and short-lived models a mismatch. The memory is meant to last decades. The model it sits beside may be the best option for a few months.

A worked example

Consider a family that has used an AI assistant for two years. Its memory holds the children's school schedules, the contractor who fixed the roof and what he charged, why they chose one insurance policy over another, gift ideas for every relative, and hundreds of small preferences. Then a different vendor releases a clearly better model.

If that memory lives inside the old vendor, switching means one of three things: losing two years of context, paying the old vendor to keep it while using the new one, or rebuilding it by hand. Most families will simply stay. The old vendor keeps the customer without having kept the lead.

A legitimate moat and an illegitimate one

A vendor's legitimate moat is being better: smarter models, faster tools, a harness that gets more done with fewer mistakes. An illegitimate moat is holding a person's accumulated context hostage, so that leaving means starting over even when a better option exists. The first rewards progress. The second taxes it.

Principles we build on

• Local-first software: Kleppmann and colleagues argue that people should own their data, keep working without the vendor's servers, and be able to use it for decades [3].
• A legal floor: Europe's GDPR gives people the right to receive their personal data in a structured, machine-readable format and move it to another provider [4].
• Open protocols for tools: the Model Context Protocol lets the same tools and data sources connect to different models [5], so the harness doesn't have to be rebuilt to change models.

How an Island is built

An Island's memory lives in places the customer already controls: their email archive, their document folders, their notes and a knowledge base in a repository they own. The rules that route their work are written in plain text. The model is a component, chosen for the job and replaceable by configuration. Moving to a different model should take an afternoon, and nothing learned should be left behind.

If you can't take your memory to another model, it isn't your memory.

What portability actually requires

• Open formats for the memory itself: email in standard formats, documents as files, notes as plain text or Markdown.
• Rules as readable text, not settings buried in one vendor's interface.
• Search indexes treated as a cache. Embeddings depend on the model that made them; they should be rebuilt on a switch, never treated as the memory.
• Tool connections through open protocols, so the harness survives a change of model.
• Exports that are tested on a schedule, because an export path nobody uses quietly breaks.

The third point is the one most systems get wrong. A vector index is not your memory. It's a disposable view of it, tied to one model's way of representing meaning.

What we ask of every vendor, including ourselves

• Export everything a person has given you, and everything you inferred about them, in open formats.
• Document the structure of that export so another system can actually read it.
• Delete on request, completely, including derived data such as search indexes.
• Never train on a person's memory without explicit, revocable consent.
• Compete on being better, not on being hard to leave.

The vendors' best argument

The strongest case for keeping memory inside the vendor is quality. A vendor can design how memory is stored, summarized and retrieved together with its model, test the whole system end to end, and improve both at once. A portable format, by contrast, tends to freeze at the lowest common denominator, and standards bodies move slower than labs.

We think this is a real cost, and we accept it. The memory formats we use are the ones people already rely on: email, files, plain-text notes. They are not optimized for any model, and that is the point. Retrieval tricks, indexes and summaries can be as model-specific as a vendor likes, as long as they are built on top of memory the person owns and can be thrown away and rebuilt.

Continuity, not just choice

Portability is usually argued as freedom to pick a better model. For a business it is also continuity. Vendors change prices, retire products, change terms and occasionally go down. A business whose operating memory lives in its own accounts can absorb any of those events in an afternoon. One whose memory lives inside a vendor has to absorb them on the vendor's schedule.

Where we might be wrong

• Integration may be worth the lock-in. Memory designed together with a specific model, its embeddings and its tools, may simply work better than a portable format.
• Portability creates risk. Every copy and every export path is another place for private data to leak.
• Most people never switch. Portability is an option many will never use, and building for the lowest common denominator has costs.

What we're measuring

• The swap test: on a schedule, run the same Island against models from two different vendors and compare routing agreement and answer quality.
• Time to migrate: how long it takes to move an Island to a new model end to end.
• Loss on migration: questions the Island could answer before a move but not after.