Is AI memory actually a moat? Only the part that cannot be written down. In March 2026, OpenAI, Google and Anthropic each shipped memory export or import within roughly a month of each other. The transfer mechanism is a prompt: the source assistant writes a plain-language summary of what it holds about you, and the destination reads it in.
That detail decides the argument. Whatever survives that round trip is something a user could have dictated in a paragraph, and a paragraph was never a switching cost. What stays behind is the accumulated model of how you actually work, the project state, the recent context. The residue is the moat, and on most products it is far smaller than the roadmap assumes.
For 2 years the answer to "what is your moat" in AI has been converging on 1 word. Models commoditize, features get copied in a weekend, distribution belongs to whoever already has it, so the defensible thing must be what the product remembers. Sequoia said it from a stage. Forbes ran the council post. Every seed deck has the slide.
Then, in a single month, the 3 companies with the most accumulated memory to protect all shipped tools for taking it somewhere else.
What actually happened
Across March 2026, OpenAI added a memory export, Google added memory export through Takeout plus import tools that pull from ChatGPT, Claude and Perplexity, and Anthropic shipped structured export from Claude alongside an import that reads from ChatGPT, Gemini, Grok and Copilot. Anthropic made Claude's memory available to free accounts in the same window.
Two forces are usually credited. GDPR Article 20 gives EU users a right to data portability, and compliance work landed on all 3 at once. And competitive pressure: users had started keeping context in a neutral layer outside any platform, which is a worse outcome for a vendor than losing a switch.
There is a third reading that gets less attention and explains the timing better. A moat only benefits whoever is already inside it. For everyone else it is a barrier to acquisition, so the challenger has every reason to build the bridge. Google's import tooling is not a concession. It is a customer acquisition feature aimed at accounts that spent a year training somebody else's assistant.
What transfers, and what quietly does not
The imports move explicit stored facts: name, role, location. Stated preferences about format and length. Professional context. Named goals and ongoing projects.
They do not move the rest, and the rest is most of it. No major provider has published a standardized memory export schema, so the transfer runs through natural language: the source writes a summary, the destination interprets it. That makes the result lossy by construction and frozen at the moment it was taken. These are one-time snapshots, not a sync. Revise the profile and you re-import it by hand. Anthropic's own documentation notes the imports are experimental and may not always incorporate successfully.
So the test a product team should run is uncomfortable and cheap. Whatever survives a plain-English round trip was never proprietary. It was a settings page the user filled in slowly.
Then what was the switching cost?
Everything with no natural-language summary. The corrections a user made that changed how the system behaves rather than what it stores. The workflow that became the official record, so leaving means reconstructing history rather than re-stating preferences. The evaluation set assembled from that specific account's real failures. The decisions the product holds that nobody wrote down anywhere else.
Those hold because they are not facts about the user. They are facts about the work, and they accumulate as a byproduct of doing it. That is the same asymmetry I described in Time to First Dollar, where the metric worth building around is the one that compounds rather than the one that is easy to count.
The half nobody instruments
Here is where the moat framing does active damage. It tells teams that accumulation is the goal, so they ship storage and retrieval and call it a memory feature. A switching cost that the user cannot perceive is not a switching cost. It is a database.
People leave products over what they can feel. If a year of accumulated context never visibly changes an answer, never gets referenced, never saves a step the user notices, then the account churns exactly as fast as an account with no memory at all, and the migration cost the deck promised never shows up in the numbers.
Which makes this an instrumentation problem before it is a strategy problem, and the instrumentation has to exist before the churn does. That argument is Building Retention Before You Need It applied to a newer surface.
The counterweight
Two things cut against the argument and both are real.
The imports are bad enough that friction survives in practice. A lossy one-time snapshot with no sync is not a clean migration path, and for a user with genuinely deep accumulated context the copy will feel thin. Switching got cheaper. It did not get free.
And enterprise runs on different rules. Server-side conversation state and hosted memory banks do not move between vendors, an auditor cannot subpoena a cache, and large organizations increasingly want to be multi-model by design. Portability is a procurement requirement there rather than a consumer convenience, which is the shape of buyer I described in Going Enterprise Without Killing Self-Serve.
Worth noting too that Google's import tools launched without availability in the EEA, UK and Switzerland. A feature partly attributed to European portability law arrived everywhere except Europe, which is a reminder that regulatory pressure and regulatory clearance are different clocks. Regulation shaping a product surface is becoming its own pattern, and I worked through the sharpest current case in The Transparency Tax.
What growth owns here
Make the accumulation visible. A user who cannot see what the product knows cannot value it, and cannot correct it either. The visible version does double duty, since it is also the trust surface I argued for in The AI Trust Gap: a system that shows its working gets believed, and a memory the user has corrected is a memory they are invested in.
Measure recall, not storage. The number that matters is the share of sessions where stored context was retrieved and changed the outcome. Storage volume measures a bill. Correction rate is worth tracking beside it, because a user who edits a stored memory is telling you the feature is real enough to argue with.
Build the export before you are asked. Article 20 already requires it for EU users, procurement will ask for it, and a competitor will build the bridge whether or not you do. Doing it deliberately means you decide what the export looks like, which is a better position than having a rival's prompt define it for you.
Move the accumulation toward work, not preferences. If the roadmap item is "remember what the user tells us," it is building the exportable half. The durable half is the record of what was decided, what failed, and what got corrected, and that only accrues if the product is where the work happens.
The paragraph test
Write down everything your product knows about your best customer in a paragraph a competitor could paste into their own onboarding. Most teams find it takes 4 or 5 sentences.
What is left over after that paragraph is the actual moat. It is usually narrower and more specific than the strategy deck claims, it is almost never the thing labeled "memory" on the roadmap, and it is the only part worth defending.