Portable AI Memory or Permanent Lock-In

Picture a team that has spent 18 months working inside Claude Projects. Hundreds of conversations, project instructions refined over dozens of iterations, an accumulated body of context about the codebase, the customers, the decisions already made and why. Then leadership asks a reasonable question: should we evaluate Gemini? And the honest answer from whoever owns the AI stack is uncomfortable. The subscription is easy to cancel. The 18 months of accumulated context has no migration path. You can export your conversations as JSON and your memory as a text summary, but nothing on the other side can reconstruct what the tool actually knew about you. AI memory portability, as a practical capability, does not exist in July 2026. Starting over is the migration plan.

Here is what changed this summer: the first vendors have noticed. One open-sourced its entire memory engine so customers can inspect and self-host what their agents know. Another ships memory with git semantics - commit, branch, merge, push, pull - and markets itself as the portable memory layer. Both moves are real progress, and I will give both full credit below. Both also illustrate, precisely, what is still missing. A format that only one product writes is not portability. It is a well-documented dialect.

The thesis of this piece is simple to state and has a decade of consequences: memory is the new vendor lock-in, memory portability is the architectural decision of the decade, and the category needs a neutral interchange standard that no single vendor owns. Nobody is building that standard yet. This is the argument for why someone must, what it has to contain, and why the regulatory clock in Europe has already started.

The new lock-in is at the memory layer#

The models themselves stopped being the switching cost some time in the last two years. Frontier models leapfrog each other every few months, the API shapes are near-identical, and swapping providers behind a well-built abstraction layer is an afternoon of work. If you doubt how replaceable models have become, June just ran the experiment for us. On June 12, the US government issued an export control directive that forced Anthropic to pull its newest flagship models offline worldwide within hours. Teams that had adopted them fell back to older models within days and kept shipping. Access was restored on July 1, nineteen days later. A frontier model - the most capable one on the market - vanished for nearly three weeks, and the ecosystem absorbed it. Try to imagine absorbing the overnight loss of everything your AI tools have learned about your team. That thought experiment is the whole argument.

So differentiation moved up the stack. What a platform knows about you is the one asset a competitor cannot replicate by shipping a better model, and every major vendor understands this. The pattern I laid out in why AI agents forget by design - and where the captured context lives now has a second act: the same context that applications painstakingly rebuild on every stateless API call is now being captured, persistently, inside each platform’s own memory features. The capture is genuinely useful. It is also, structurally, a moat.

The clearest current example arrived on June 23, when Anthropic launched Claude Tag: Claude as a persistent teammate inside Slack, with channel-scoped memory that accumulates as it works and can extend across an organization’s channels when granted permission. It is an impressive product. It is also memory that lives bound to the Slack workspace and to Anthropic, with no documented export. Every week it runs, it learns more about how a company works - and every week, the cost of ever using anything else grows. Nobody had to design that as a trap for it to function as one.

The economics here are old. Databases, ERPs and cloud data warehouses all ran the same play: the product is replaceable, the accumulated state is not, and the state is priced into the exit. What is new is the breadth of what gets captured. A data warehouse holds your tables. An AI memory layer holds how your organization thinks - preferences, decisions, conventions, the reasoning behind choices, who said what and when. The switching cost is no longer your data. It is your institutional knowledge, in a shape only one vendor can read.

The inversion in one picture. Model switching cost keeps falling - June 2026 proved a flagship can vanish for nineteen days and teams just swap. Memory switching cost compounds with every week on the platform, and the widening gap between the curves is the moat.

Three kinds of lock-in your AI memory creates#

It helps to be precise about what accumulates, because the three kinds of memory lock in differently and hurt differently when you try to leave.

Behavioral lock-in is the learned layer: your preferences, your style, the corrections you have made a hundred times. ChatGPT’s Memory is the canonical consumer example, and it is also the canonical one-way door. OpenAI’s own Memory FAQ covers viewing, managing and deleting memories - there is no export. The account-level data export gives you your conversation history; the distilled memory the product actually uses to personalize responses stays inside. What the system learned about you over a year of daily use is, by construction, not yours to take.

Context lock-in is the working-state layer: project history, established facts, decisions and their rationale, the running state of everything in flight. This is the layer teams feel first when they evaluate a switch, because it is the layer that makes the tool useful on Monday morning without a briefing. It is also where the industry’s one genuine interoperability precedent lives. Anthropic ships a memory import that accepts memories brought over from ChatGPT, Gemini or Grok, and Google answered with a ZIP-based import of its own. Credit where due: these are real doors between platforms, and they mattered enough to trigger a minor migration wave this spring. But look at the mechanism. The user runs a prompt that asks the old assistant to write out what it remembers, then pastes or uploads the prose into the new one. It is an on-ramp built by the vendor who benefits from the traffic, it flattens everything to text, and it moves in whichever direction the importing vendor built. An on-ramp is not a standard.

Relationship lock-in is the layer almost nobody prices in, because it only exists in team settings: who established which fact, who decided what and when, which person’s correction superseded whose earlier claim. This is provenance, and it is what turns a pile of remembered facts into organizational memory you can trust and audit. It is also the layer that shared, channel-scoped memory products accumulate fastest and expose least. When memory becomes a teammate rather than a personal notebook, the who-said-what-when graph becomes the most valuable and least exportable thing in the building. It is also the layer auditors and legal teams will eventually ask about, because a decision trail you cannot export is a decision trail you cannot produce on request.

Three kinds of lock-in, three different exit costs. Behavioral memory is annoying to lose, context memory is expensive to lose, and relationship memory - the provenance graph of who established what - is the one organizations cannot rebuild from an export of plain text.

Each layer compounds on the previous one. And the compounding is the point: none of this is a bug a vendor will fix under competitive pressure, because the pressure runs the other way. Retention economics reward capture. Only two forces push against it - customers who demand portability in procurement, and regulators who mandate it. Both are covered below. First, the vendors who deserve credit for moving early.

The vendors who noticed (and why it’s not enough yet)#

Two products shipped this year that take memory ownership seriously, and the honest version of this argument has to start by steelmanning them.

Cognee 1.0 launched on June 26 as a fully open-source memory engine: a typed knowledge graph you can run on a single Postgres instance, with an API built around four verbs - remember, recall, improve, forget - and an export path to its own COGX archive format. The launch post is explicit about why: teams were not going to hand the memory of their business to, in Cognee’s words, “a black box they couldn’t inspect, host themselves, or take with them.” That is the correct diagnosis, stated by a vendor, in public. Self-hosting means your memory sits in your database. Open source means you can read every line of the code that writes it. If every memory product met this bar, half of this article would be unnecessary.

ByteRover attacks the same problem from the developer-tools side and calls itself the portable memory layer for coding agents. Its memory is a hierarchical context tree stored as plain markdown, versioned with git semantics - you commit memory changes, branch them, merge them, push and pull them between machines and teammates. Anyone who has watched a team lose a month of agent context to a laptop swap understands immediately why this is the right shape. Files you can read in any editor, with history, that move the way code moves. As a design instinct about who should hold memory, it is exactly right.

Both vendors get full credit for moving first, and neither has solved portability - because a single implementation cannot. Open source makes a format inspectable; it does not make memory portable between vendors. Portability is a property of an ecosystem, not of a codebase. A COGX archive is readable by Cognee. A ByteRover context tree is meaningful to ByteRover. If either company disappeared tomorrow, your memory would be legible - a real improvement over the incumbents - but it would still be stranded, because nothing else writes or reads that shape natively. A format only one implementation writes is a dialect, not a standard. And to be clear, this is an argument neither vendor can rebut without arguing against their own openness, which is exactly why it is the right test.

The demand signal extends beyond vendors. In the first half of 2026 alone, at least three independent interchange proposals appeared: MIF, an individual developer’s memory interchange spec; memorywire, an academic wire-format proposal for memory operations; and the community-driven Open Memory Protocol, which describes itself as vendor-neutral. Add COGX, a vendor’s own export format, and you have four different answers to the same question in six months. None of them has institutional governance, a second independent implementation, or vendor adoption. I am not reviewing them here, and that is deliberate: the wave matters more than any entry in it. When four unrelated parties independently invent the same missing piece, the piece is missing.

So the gap, precisely stated: it is not that nobody has proposed a format. It is that no format has been placed under neutral governance and implemented, independently, twice. That gap has a well-known shape, and the industry has closed it before.

Why portability is harder than an export button#

Every platform’s answer to portability criticism is the same: we have data export. And every one of those exports fails the same way, because a memory archive that preserves the text but discards the structure has exported the words while deleting the knowledge. Real portability has six technical requirements, and it is worth being concrete about each, because this list is what separates an export button from an exit.

Structure. Memory is typed. A fact about a customer, a decision with a rationale, a preference, an event with participants - these are different kinds of objects with different fields and different lifecycle rules. An export that flattens them into paragraphs of prose forces the importing system to re-extract structure with a language model, which m

[truncated for AI cost control]