The Next Frontier: Memory That Moves Between Models, Not Just Sessions

The technical conclusion here is mildly disappointing and I think it is correct: the only representation we currently have that survives moving a memory from one model to another is natural language text plus structured metadata. Not embeddings, not attention states, not fine-tuned weights, not a clever compressed latent format. Plain strings with fields attached. After several years of progress on everything else, the portable format for machine memory is prose.

Worth working through why, because the reason is more interesting than the conclusion.

Embeddings are not a portable format

An embedding is a set of coordinates in a space that one specific model constructed during training. Voyage-3 and text-embedding-3-large both emit vectors; those vectors have no shared basis. Dimension 412 of one has no relationship to dimension 412 of the other. Cosine similarity between them is a number you can compute and it means nothing.

cosine(voyage_vec, openai_vec)   # type-checks, returns ~0.01, is meaningless
                                 # different bases, different training,
                                 # no alignment, no transform to recover one

There is no general invertible mapping between two embedding spaces. You can fit an approximate linear alignment if you have a large set of paired texts, and it degrades badly on anything out of distribution. So switching embedding models means re-embedding from scratch, which means the source text is the actual artifact and the vectors were always a derived index. This is worth internalizing because it inverts how a lot of systems are built: if you stored embeddings and treated the text as incidental, your data is coupled to a vendor's model version and you will discover this the day they deprecate it.

The same argument kills the more exotic options. KV cache state is tied to a specific architecture, layer count, and head dimension; it does not transfer between model families and often not between checkpoints of the same family. Fine-tuned weights are the least portable representation possible. Text is the only thing every model can read, because reading text is the one interface all of them implement.

Why nobody ships portability by default

Every major assistant now has a memory feature, and none of them export in a form another vendor can ingest. That is not an oversight. Memory accumulates, accumulated memory is switching cost, and switching cost is retention. A vendor building a memory feature is building a retention feature, and it happens to also be useful to the user. Portability is the one property that would make it purely a user feature, which is the same property that makes it strategically unappealing to ship.

I do not think this requires bad intent from anyone. The incentive gradient just does not point that direction, and features that require pushing uphill against the gradient tend to arrive from outside the incumbents or not at all. Which is the ordinary shape of how interop standards happen: they get built by whoever loses from lock-in.

What a portable memory record needs

Text alone is not enough. A pile of unordered sentences is a transcript. Four fields are the minimum that makes it a record another system can reason about.

Stable entity identifiers. "The ingestion service" in one memory and "the Go ingestion pipeline" in another need to resolve to the same thing, or the receiving model cannot tell which facts are about which subject. Without stable identifiers you cannot even detect that two memories are in conflict, let alone resolve it.

Temporal validity. Not just a created-at timestamp. A validity interval, and an explicit supersession link when one fact replaced another. A memory that says "uses Postgres" with valid_to set and superseded_by pointing at the ClickHouse memory is legible to any consumer. A memory that says "uses Postgres" with only a creation date makes every consumer re-derive the ordering by guessing.

Provenance. Which model, which session, which device, and whether the user asserted it or a model inferred it. This is the field that gets skipped and it is the one that determines trust. A fact the user typed and a fact GPT-4 guessed from context should not carry the same weight, and a receiving model has no way to distinguish them unless the record says so.

A transport any client can speak. Format without transport is a file you email to yourself.

{
  "id": "mem_7f3a",
  "text": "Ingestion service was rewritten in Go, replacing the Python version.",
  "entities": ["svc:ingestion", "lang:go", "lang:python"],
  "valid_from": "2026-06-02T00:00:00Z",
  "valid_to": null,
  "supersedes": "mem_2c19",
  "provenance": {
    "model": "claude-opus-4",
    "device": "ipad-01",
    "session": "sess_88b1",
    "assertion": "user_stated"
  }
}

Nothing in that record is model-specific. Any LLM can read the text field. Any client can filter on valid_to. The embedding is absent on purpose: it belongs to the store, gets recomputed when the store changes models, and never crosses a boundary.

The transport is where MCP earns its place

A format solves representation. It does not solve the N×M problem: four assistants times three memory stores is twelve integrations, none of which any vendor is motivated to write.

MCP is relevant here for an unglamorous reason. It defines a JSON-RPC tool interface with a capability handshake, and clients already implement the client half (the specification). So a memory store that exposes remember, recall, and continue_from as MCP tools is reachable from any conformant client with a config file change and zero code on the vendor side. The protocol does not know or care what a memory is, which is exactly why it works as a substrate: it moved the integration cost from N×M to N+M.

There is a real tension in relying on this. Protocols are only as portable as their adoption, and a standard maintained by one vendor is one product decision away from stopping being a standard. The honest position is that MCP is the best available answer today rather than a guaranteed one, and that building on it is a bet with an exit: because the memory records themselves are text plus metadata, they survive the protocol changing. That is the actual argument for keeping the representation dumb.

Session portability is a storage problem and it is solved. Model portability is a representation problem plus a protocol problem, and only the representation half has a clear answer.

The specific bet Unimatrix makes is that the boring representation wins: memories stored as text with entity, validity, and provenance fields, reachable over MCP from whichever model happens to be open. Starting on ChatGPT and continuing on Claude is not a feature so much as what falls out when nothing in the record is tied to either one. The tool surface is documented in the MCP reference.