An agent's memory is a user profile

An agent that remembers you across sessions has a store of things it learned, a way to decide what goes in, and a way to pull the relevant parts back at request time.

That is a user profile. The vocabulary is new — memory, retrieval, context — and the engineering problems are the ones personalization has been working on for twenty years, arriving in a slightly different order.

Here is the one that bites first.

Memory has a currency problem, and retrieval cannot fix it

Over a long relationship, most facts about a person change at least once. They move. They change jobs. The dietary preference from March is not the one from November.

A memory layer built the obvious way — embed each statement, store it, retrieve by similarity — keeps every version. And when the agent is asked where the user lives, the query embedding is close to all of them, because they are all sentences about where the user lives. Similarity has no opinion about which is true now, because being about the same subject is precisely what makes them similar.

The obvious patch is to prefer the newest entry, and it helps. It also fails whenever the newest mention is not the newest fact — someone reminiscing about their old flat, quoting an earlier message, or correcting something said two turns ago. Timestamp ordering is a heuristic over the write log, not a resolution of what is true.

Three write policies, one transcript

Below, 400 turns of conversation about 24 facts. Facts get stated and sometimes changed; the agent is periodically asked about one. Three policies see the identical transcript.

Answers against context spent. The horizontal axis is how many memory tokens are pasted into the prompt before the model answers. Purple is correct answers, amber is answers built on a fact that used to be true, and the faint lines are the write policies you are not looking at.

What the run says

At the defaults — five entries retrieved, 40% of statements being updates:

	entries stored	correct	stale
write everything	226	50%	48%
write what matters	99	40%	37%
merge and supersede	58	76%	19%

The smallest memory is the most accurate, by a wide margin, and it is not close.

Writing everything answers with a superseded fact almost as often as with a current one. Every update adds a competitor rather than replacing anything, and the retriever picks between them essentially at random.

Writing what matters — a salience filter that keeps 45% of statements — is the worst of the three. It has fewer stale entries because it has fewer entries, and it also throws away current ones. It shrinks the memory in the wrong dimension: it drops facts instead of resolving them.

Merge and supersede wins because it is doing the only thing that actually addresses the problem. Before writing, check whether this statement is about something already stored, and if it is, replace it. The simulation gives that matching step an 82% success rate — it is far from perfect, and it is still worth more than either alternative.

The write path is the whole system

This is the part worth taking away, because most engineering effort on agent memory goes to the retrieval side: better embeddings, hybrid search, reranking, larger .

Look at what larger buys. Going from 1 entry to 5 improves “write everything” from 43% to 50% and then it flattens completely — retrieving more only surfaces more versions of the same fact. The stale line does not fall at any . No retriever fixes this, because the ambiguity is in the store.

Now drag how often facts change. At 10% churn everything looks fine and the policies are within a few points of each other. At 80% the naive store answers correctly 36% of the time and wrongly 62%. The write policy only starts to matter when the world moves — which is to say, it only starts to matter once the product has been in someone’s life long enough to be useful.

What a real memory write should do

Extract a claim, not a sentence. “I moved to Dhaka last month” becomes a typed fact — subject, attribute, value, time — rather than a paragraph to embed.
Look for what it contradicts. Retrieve existing entries for the same attribute, and decide: is this new information, a restatement, or a change?
Resolve, then write. Replace on a change, discard on a restatement, append only when it is genuinely new. Keep the old version if you need an audit trail — but keep it out of the retrieval index.
Record provenance. Which turn it came from, and how confident the extraction was. Both are what makes the memory reviewable later.

Step 2 is the expensive one: it is a model call on the write path, where teams would rather not spend anything. It is also where the entire quality difference in the table above comes from.

The rest of the profile lessons transfer

Once memory is understood as a profile, the existing answers apply directly.

Forgetting should be a decay, not a purge Some facts are stable for years, others were true for a week. Weighting entries by age with a per-type half-life is exactly the profile-decay problem, and “half-life by attribute type” is a far better parameter than “delete after 90 days”.
The context window is a serving budget Every retrieved entry costs tokens on every turn, and the tokens are paid whether or not the memory was relevant. This is the reranking-depth trade in a different currency: quality rises with k, cost rises linearly, and quality flattens first.
The user needs an escape hatch Wrong memories are much worse than absent ones, because the agent states them confidently and the user cannot tell where they came from. “Show me what you remember, and let me delete it” is not a privacy feature — it is the correction mechanism the system needs to stay accurate.
Evaluate it as retrieval, with staleness as a metric Recall of the current fact and rate of superseded answers, tracked separately. A single “memory accuracy” number hides the difference between not knowing and being confidently wrong, and users react to those very differently.

The one genuinely new thing

Agents write their own memories, which recommender systems never did. A profile built from clicks is a record of behaviour; a memory built by a model is a record of what the model decided was worth keeping, including whatever it got wrong at extraction time.

That closes a loop. A misextracted fact is retrieved later, informs an answer, and the answer becomes part of the conversation the next extraction reads. It is the feedback loop from the recommender with a shorter cycle and no impression log to audit — and the same defence applies. Keep the raw transcript, so that whatever the memory layer concluded can be recomputed when you improve it.