Why Most "AI Memory" Products Are Just Chat History With a Better Name

Here is a falsifiable version of the complaint. If a system stores raw conversation turns and answers queries by running embedding similarity over those turns, it is transcript search. Calling it memory adds a word and no capability. The two properties that would make it something else are a write policy (a decision about what not to store) and a supersession model (a representation for "this fact replaced that one, on this date"). Neither is implied by having a vector index.

That claim is testable in about ten minutes against any product. Four questions do it.

1. Does retrieval cross session boundaries?

Open a new conversation. Ask about something you established two conversations ago, using different words than you originally used. If nothing comes back, the "memory" is a context window with a scrollbar.

A passing implementation stores memories in a scope larger than the session and attaches the session only as provenance metadata, not as a retrieval filter. Read path looks roughly like:

SELECT id, content, written_at, source_session
FROM memories
WHERE user_id = $1                    -- scope is the user, not the session
  AND superseded_by IS NULL
ORDER BY score(embedding, $2, written_at) DESC
LIMIT 8;

Most products pass this one. It is the easy question, and it is the one marketing pages are written about.

2. Can it say that a fact replaced an earlier fact, with a date?

This is where the category fails, nearly across the board, and it is the question that actually matters.

Tell the system you use Postgres. Later, in a different session, tell it you migrated to ClickHouse. Then ask what database you use. Three outcomes are possible. It says Postgres (wrong, and it has no way to know it is wrong). It says "you mentioned Postgres and also ClickHouse" (both facts retrieved, no ordering, the model is left to guess). Or it says ClickHouse, and can tell you when that changed and what it replaced.

Only the third is a memory system. Getting there requires something an embedding index cannot express, because vector similarity has no ordering relation and no notion of contradiction. Two statements about the same entity with opposite content sit near each other in embedding space, which is precisely backwards from what you need. You need an edge, written at insert time:

-- on write, look for existing memories about the same entity/predicate
existing = find_by_entity(entity="database", predicate="in_use")

if existing and contradicts(existing, candidate):
    mark_superseded(existing.id,
                    by=candidate.id,
                    at=now())        # old row is kept, not deleted
insert(candidate)

Two details make this workable rather than theoretical. The old row is retained, so "what did I use before?" still answers and provenance survives an incorrect supersession. And the decision happens on the write path, where there is one candidate and time to reason about it, rather than on the read path, where you are latency-bound and have k retrieved rows with no idea which is current.

A system that skips this is not slightly worse at recall. It is structurally incapable of representing change, which means every long-lived fact it holds decays into a liability.

3. Does it decide what not to store?

Store-everything is the default because it is easy and because it looks generous. It is neither cheap nor harmless. Conversational text restates the same handful of facts constantly, so an unfiltered store fills with paraphrases, and then top-k retrieval returns five wordings of one fact and spends the context budget on redundancy.

A passing implementation has an explicit policy with observable behavior. Minimum viable version: near-duplicate detection at write time (nearest neighbor above roughly 0.95 cosine merges instead of inserting), plus a filter that rejects transient content. "Can you make that shorter" is not a memory. "I prefer terse commit messages" is. The test is whether you can find any input the product refuses to store. If you cannot, there is no policy.

4. Does the memory move to a different model?

Export your memories. Point a different vendor's model at them. Ask the same question you asked before and see whether you get the same context back.

A JSON dump is necessary and not sufficient. Portability needs a representation that survives the switch, which in practice means natural-language text plus structured metadata, because embeddings are model-specific and mutually incomparable. It also needs a transport the new client can speak without a custom integration, which is the part MCP addresses and the reason it matters more than it looks. The tool surface is in the MCP reference.

Being fair about the category

Per-vendor memory features do real work. ChatGPT's memory genuinely improves ChatGPT. If you use one assistant and intend to keep using it, a vendor-native feature is well integrated, requires no setup, and will beat a bolted-on layer on latency. That is a real product, honestly scoped, and dismissing it is not a serious position.

Mem0 and MemGPT deserve more specific credit. MemGPT's contribution was treating the context window as a paging problem, with the model itself issuing calls to move information between a small fast tier and a large slow one, and the MemGPT paper is a genuine architectural idea rather than a wrapper. Mem0 ships an extraction and consolidation pipeline that does try to decide what is worth keeping, which is question 3 taken seriously. Both clear more of these bars than the average product does.

Where the category as a whole comes up short is question 4, and the reason is structural rather than technical. Memory that is locked to one vendor produces switching costs, and switching costs are exactly what a vendor wants from a memory feature. Nobody has to be cynical about it for the incentive to work; the gradient just does not point toward portability by default.

Cross-session retrieval is table stakes. A supersession model with dates is the line between memory and search. Portability across vendors is the line between a feature and infrastructure.

Unimatrix is built around questions 2 and 4 specifically, because they are the two nobody solves by accident: supersession is enforced on the write path, and memories are stored as text plus metadata so they survive being read by a different model on a different device. The other two questions are table stakes, and they should be.