Why AI memory needs an interchange layer

Start with the zip file

There is a 718MB file on my laptop called conversations.json. It came out of my Claude export zip: every conversation I have had with the assistant I use most, downloaded from settings the way the button intends.

Here is the complete list of things that file could do, until recently: sit there. No other assistant reads it. Nothing ingests it without one-off glue code written against one vendor's current dump format. It is the record of me, printed in a format nothing else speaks natively.

So I ran one command against it:

npx memvelope conversations.json

About twenty seconds later I had a receipt: 607 conversations read, 368 kept (the other 239 had no prose to keep), 46,433 messages, one 67MB envelope.

The output is a single JSON file. Abridged, it looks like this:

{
  "memvelope": "envelope-v0",
  "meta": {
    "source_provider": "claude",
    "conversation_count": 368,
    "message_count": 46433
  },
  "conversations": [
    {
      "messages": [
        { "id": "…", "role": "user", "ts": "2026-05-11T14:02:09.000Z", "text": "…" },
        { "id": "…", "role": "assistant", "ts": "2026-05-11T14:02:31.000Z", "text": "…" }
      ]
    }
  ]
}

(Abridged. The real file is 67MB of exactly this shape.)

That is the whole artifact: a deterministic parse of the export every user already has, into a shape anything can read. The rest of this essay is the argument for why that boring conversion is the missing layer in AI memory, why five previous calls for the same idea stalled, and what a standard has to look like to get adopted rather than admired.

Paste-buffer diplomacy

Every AI lets you export your chats. None of them can read each other's.

That is the state of the art in July 2026, and it deserves a moment of plain description. If you want to move your accumulated context from Claude to a rival, or the reverse, the official procedure is: ask the model to write out its memories of you, copy the text, and paste it into the other assistant. That is not a paraphrase. It is Claude's documented export flow: prompt the assistant to produce your memories verbatim, then carry the blob across by hand.

What survives that trip: whatever the model chose to write down. What doesn't: provenance (which conversations produced which fact), dating (when you actually said the thing), attribution (whether that was your claim or the model's inference), and any way to verify fidelity. You get a summary of a summary, moved between vendors by paste buffer.

Meanwhile, importing is becoming a product feature. Import gets engineers; export gets a support article. That asymmetry is the shape of the whole problem, and it is worth understanding why it exists before proposing anything.

The record of you is the moat

Memory is becoming the reason you can't switch. Not the model. Models leapfrog each other every quarter, and the market treats them as increasingly interchangeable. The accumulated record is different: your preferences, your projects, your history of decisions, the context that makes an assistant useful on the first message instead of the fortieth. It compounds, it doesn't transfer, and it lives inside products designed to keep it.

None of this is villainy. Lock-in is the rational strategy for an incumbent with a good product; you don't need a conspiracy to explain why nobody ships a real memory export, you just need a spreadsheet. But that is exactly the point. The neutral layer will not come from the vendors — vendors standardize complements all the time, but nobody standardizes their own moat. Funding your own commoditization is not a strategy any incumbent can rationally choose. The vendors build the summary. The record should be yours to keep. Your memory of you shouldn't be a feature flag inside someone else's product.

The bar to aim for is what I think of as the .ics test. Nobody thinks about who wrote the line of code that makes a calendar invite move between Google and Apple. The invite just moves. That invisibility is what winning looks like for an interchange layer: not a product, not a brand, a boring file format that works so reliably it disappears.

Five calls, fifteen stars

The idea is not new, and pretending otherwise would be the fastest way to lose anyone who knows better.

Ashley Mayer asked for "a kind of single sign-on for your context" in May 2025. Torch Capital published the case for portable AI memory in September 2025, arguing users need tools to "control, manage, and carry their AI memories with them across platforms." "The Memory Wars" (Brcic, arXiv, August 2025) named the cognitive-moat dynamic precisely and made memory portability its first policy pillar.

And two people did more than call for it; they wrote specs. MIF, by Robert Allen, who put the thesis better than I can when he introduced it: "your AI memories should outlive the tools that create them." PAM, by Daniel Gines, pitched as "vCard for AI memories." Both are serious documents by people who saw the problem early, and both deserve engagement rather than the startup habit of pretending prior art doesn't exist.

So the honest accounting: the idea has been called for five times over. What is missing is not the idea. It is adoption. Two single-author specs with about fifteen GitHub stars between them is, as of July 2026, the entire current state of the AI memory interchange layer.

That number should bother anyone who wants this problem solved. It bothered me enough to ask why.

The on-ramp nobody standardized

Here is what I think happened. The prior specs standardize the end-state: the shape of a memory store. Schemas for facts, entities, relationships, the distilled representation of a person. That is the hard part. It is contested, because every memory engine has opinions about representation. It is model-mediated, because facts are extracted by inference, so two faithful implementations of the same spec will produce different files from the same input. You cannot conformance-test it with a diff, because there is no single right answer for what a model should have extracted. Format-first asks implementers to agree on the most opinionated thing first. That is why it stalls at fifteen stars.

Nobody standardized the on-ramp: the export zip every real user already has.

The on-ramp has none of those problems. Parsing a vendor export is deterministic. Not "deterministic" in the aspirational sense the AI industry uses the word, but actually deterministic: parsing, not inference. Same input, same output, byte for byte. It can be implemented in an afternoon, in any language, with no API key and no model. And the users are already there: anyone with an AI subscription can produce an export today.

Standards win when the first step is trivial and the users are already standing at it. The specs that demand agreement on the deepest questions first get admired, cited, and ignored.

There is a second reason the on-ramp is the right first standard. The cold-start problem isn't building the brain, it's filling it, and every memory system that will ever exist needs backfill from somewhere. The export zip is the universal backfill. A standard on-ramp is not a nice-to-have for the memory ecosystem; it is the front door every participant needs anyway.

Two layers, one honest boundary

memvelope, the standard I steward, is built around exactly that split.

Layer 1 is the envelope: a deterministic, lossless-prose archive of what your AI conversations actually were. It is a pure function of the export. The same export in produces the byte-for-byte identical envelope out, in any conforming implementation, in any language. Conformance is not a judgment call or a certification program; it is an exact diff against public golden fixtures. Either your implementation produces the reference bytes or it doesn't.

Determinism costs you things, and the spec pays gladly. There is no converted_at timestamp in the envelope, because a wall-clock field would make two otherwise identical conversions differ. If a field can't be reproduced from the input alone, it doesn't exist. It is a small detail, and it is the kind of detail that tells you whether determinism is a slogan or a constraint.

Layer 2 is the memory file: distilled, durable facts. This is what people usually mean by AI memory: who you are, what you're working on, what you've decided. It is typically produced by a model, which means it is not deterministic and not lossless, and the spec says so out loud instead of pretending otherwise. It's a reading, not a record.

Because losslessness is impossible at Layer 2, the standard holds it to a different discipline: provenance. Every fact carries whose fact it is (subject attribution), how it arrived (a distilled file is marked as distilled), and honest dating. The memory layer in the current spec is deliberately early; the principles are the commitment, and the vocabulary is expected to evolve in public.

The determinism boundary between the two layers is normative, and it is the adoption mechanism. An implementer can ship Layer 1 this afternoon while taking no position at all on the contested questions. The archive is useful on day one, with no model, no key, and no faith in anyone's ecosystem. Layer 2 can then evolve the way contested layers should: on top of a substrate everyone already agrees about, because a diff said so.

Honesty as conformance, not vibes

A memory format lives or dies on whether you can trust what's in the file. So the spec makes several honesty properties conformance matters rather than aspirations.

Dates. When we measured, model-asserted dates were wrong 25 to 30 percent of the time, across every model we tested. A model reading "last Tuesday" in an old conversation will confidently emit a date, and it will confidently be wrong a quarter of the time. So the spec forbids a model's recalled or inferred date from ever becoming the queryable date: a date can enter that field only from the source text or from the conversation's own timestamps — and the file marks which, permanently. A query over your memory should hit evidence, not confidence.

Supersession. People change, and facts about them expire. A memory file that silently rewrites its own history isn't a record; it's a press release about you. So the standard's rule is that a revision supersedes, it never silently deletes: the old fact remains, marked as superseded by the new one. The memory layer shipping today is deliberately early and doesn't yet carry the supersession vocabulary — it lands with memory-v0, and the rule it will enforce is already fixed, because it's the difference between a memory that can answer "what did I believe last year" and one that quietly rewrites you into whoever you are this week. Note what the rule binds, and what it doesn't: it governs the file, not your architecture. A system with no versioned memory of its own can still read and write conforming files — it just can't silently rewrite one.

Open vocabulary, small registered core. Closed enums are how standards die. The moment a real system needs a type the committee didn't anticipate, it either forks the spec or lies to it. The envelope already lives by this: provider names are a small registered list a converter must not guess beyond, and readers must ignore unknown fields rather than fail on them. The memory layer's category vocabulary is closed in today's deliberately-early shape; opening it — a small registered core, everything else free — is a design commitment for memory-v0, stated here so it can be held against us.

Voice is prose. In my ChatGPT export, exactly half the conversations — 70 of 140 — were voice. Transcripts are prose, and the envelope keeps them as prose, in the same stream as everything typed. A standard that drops the phone calls drops the person.

Analogies, including where they break

Pieces like this usually reach for an analogy and then die on it, so here are three with the misfits stated.

LSP and MCP. Language servers turned the editors-times-languages problem from M×N into M+N: implement one protocol, interoperate with everything. Assistants-times-memory-stores is the same shape. And this industry has already run the playbook, in-domain, at speed: MCP launched in November 2024, OpenAI adopted it in March 2025, and it was donated to the Linux Foundation in December 2025. Months, not decades. The misfit: LSP and MCP are live protocols, pipes between running processes. Memory needs the file, not just the pipe: an at-rest format you still own when the process is gone. And LSP won partly on VS Code's distribution, which no memory format has.

vCard and iCal. Small, user-owned, personally identifying records that outlived every application that ever produced them. That is exactly the durability target, and it is why PAM's "vCard for AI memories" framing is a good one. The misfit: contacts have a stable, enumerable schema (name, phone, email); memory does not. And vendors adopted vCard because contacts were never the moat. Memory is the moat, which is why the adoption path has to route around the incumbents rather than wait on them.

ONNX, as the cautionary tale. A real interchange standard for ML models, where the big frameworks export but do not reliably import. Export-without-import asymmetry is precisely the failure mode already visible in AI memory: import is a product feature, export is a paste. A memory standard that only ever gets written and never gets read would be ONNX all over again. This is why the reference tooling leads with the reader's side of the bargain: an archive you can actually open and use, not a writer-side promise.

The objections

"Long context kills memory." The strong version: windows are growing so fast you'll eventually paste your whole history into the prompt. Two problems. Context quality degrades well before window limits; Chroma's Context Rot research documents models getting measurably worse at using information as context grows, long before it stops fitting. And the vendors themselves voted the other way: background memory synthesis, distilling conversations into compact durable state, is now standard product architecture across the major assistants. The market's answer to "just use long context" was no.

"Memory is embedding-bound, not portable." Embeddings don't survive a change of model, so the argument goes the memory doesn't either. But the at-rest substance of every shipping memory system is text: facts, summaries, preferences. Embeddings are derived indexes, and derived indexes get rebuilt. You do not migrate a database by shipping its B-trees; you ship the rows and re-index on arrival. Same here: you re-embed on import. ChatGPT's injected memory state has been shown to be plain text. Text is the substance. Text ports.

"Vendors will never adopt this." A challenger already did. Anthropic shipped memory import from rival assistants in March 2026, for free users, as an acquisition funnel. Read that as the compliment it is: a major lab looked at natural-language memory transfer and decided it works well enough to bet a growth funnel on. It is also, structurally, the ONNX asymmetry arriving on schedule: import as product, export as paste. Challengers adopt portability because it moves users toward them; the import button is how an empty brain gets filled. Incumbents follow when a standard commodifies a complement, which is the MCP story, and that took months. There is also regulatory tailwind, and one paragraph of it is enough: GDPR Article 20 already promises your data in a "structured, commonly used and machine-readable format," and the EU Data Act's switching provisions began applying in September 2025. Brussels is tailwind, not thesis. The thesis is builder-led adoption, because when your context becomes portable, the model becomes a commodity, and every vendor not currently in first place has an interest in that world.

"Specs are a graveyard." Fully conceded. Most interchange specs die, single-author specs die faster, and the base rate is the strongest argument against everything in this essay. The answer is not optimism; it is the wedge. Layer 1 is a free tool that is useful today, at zero adoption. Run the converter and your export becomes a readable, portable, diffable archive even if no vendor ever adopts anything and every spec document rots. A standard that requires collective faith before it delivers individual value is a graveyard candidate. A standard that delivers individual value first rides utility instead of asking for faith.

"Transcripts aren't memory." The freshest pressure, from a sharp piece from July 2026: transcripts are noise, and the real asset is curated, distilled state. Correct. And it is an argument for the two-layer design, not against it. The envelope does not pretend to be your memory. It is the provenance substrate your memory can be derived from, audited against, and re-derived from when better distillers exist, which they will. The memory file is the curated state. The standard's one job at that boundary is keeping it honest: derived state that knows it is derived, pointing back at a record that can't be argued with.

What exists today

The ledger, in first person, as of July 2026.

memvelope.com is an in-browser converter: drop your export, get your envelope. Nothing is uploaded to any server; the conversion runs in the page. The spec, JSON Schema, golden fixtures, and CLI live at github.com/memvelope/memvelope, MIT-licensed, and the CLI is on npm as npx memvelope. Converters exist for two providers' exports: Claude and ChatGPT.

My own record is the receipt. I ran my real Claude export — a 718MB conversations.json — through the CLI: 607 conversations read, 368 kept, 239 skipped as prose-free, 46,433 messages, one 67MB envelope, about twenty seconds.

A reference importer exists for one self-hosted open-source memory engine, as a worked example of mapping an envelope into a file-based reader. One known limitation is filed as a public issue on the repo rather than kept quiet.

And the disclosure, once, plainly: I also build Virgil, a hosted memory product. The same team stewards this standard, and the spec doesn't privilege it; Virgil is one reader among any you might choose or build.

That is the whole ledger. No adoption claims, no ecosystem page, no partner logos. What exists is a working tool, a small spec with a hard conformance test, and an argument, which is what every standard looks like the day before it becomes one, and also the day before it doesn't.

The death clause

The last property worth stating is what happens if all of this fails.

An envelope file self-declares its version in its first key and is plain JSON. If every steward of this standard vanished tomorrow (site down, repo deleted, company gone), your archive would still open in a text editor, and a stranger in 2040 could work out what it is from the file alone. A standard should fail gracefully. This one is designed to: the worst case is that you are left holding a clean, readable, self-describing archive of your own history, which is already better than the zip.

And the door is open. Layer 1 is an afternoon of work in any language: parse an export, emit deterministic JSON, diff against the fixtures. The spec, schemas, and golden fixtures are public, and conformance is a diff, not a committee. If you build a memory system, the envelope is your backfill format for free. If you build nothing, the converter still turns your export into an archive you actually own. The ask is not faith in a standard, and it is certainly not faith in me. It is smaller than that: stop letting the record of you die in a zip file.

- Sean