Why AI memory should be something you can see and delete

Every assistant that remembers you eventually gets the same compliment, and it is meant as one: it feels like it really knows me. That is a lovely sentence and a useless test. The interesting question is narrower. Can you open the list?

A memory you cannot inspect is indistinguishable from a rumour about yourself, and the difference between the two is whether you can check. We build Merrin as an on-device companion whose whole argument is that your private history stays private. That argument only holds up if the history is also legible to the person it describes. The alternative, a system that keeps opinions about you and shows them only as behaviour, is how an assistant turns into a stranger who finishes your sentences.

So this post is about the boring half: what a memory record contains, what each control actually does, what happens to an answer after you delete the memory it used, and the part most memory systems skip entirely.

An AI that remembers you is only useful if you can inspect what it kept

The reason to care about long-term memory is not that an assistant can mention your dog. It is that a decision six months from now can be sharper because the reasoning from six months ago is still available. That only works if you can tell the difference between what the system knows and what it inferred.

Invisible memory fails both halves of that. You cannot audit it, so you cannot correct it. You cannot correct it, so a wrong record becomes a stable trait. Anyone who has used an assistant with a memory feature knows the specific irritation: it brings up something you mentioned once, with the confidence of a fact, and there is no screen where you can say that is not what I meant.

The fix is not more memory. It is a record with parts, and controls that act on those parts. If you want the retrieval side of this, the engineering deep dive covers how a memory loop is budgeted and why saving a fact is the easy half. If you want to know what the other assistants do with the history they keep, we put every major policy in one dated table, and the short version is that a server-side copy is a policy question while a copy that never left your phone is not.

A memory should carry its receipt

A useful record answers four questions without you going hunting. What does it say? What kind of thing is it? Where did it come from? And is it still standing?

That last one is where most systems give up, and it is the part we spend the most design time on. A memory is not a permanent fact. It is a claim that was true when it was written, and it should be able to lose its standing without disappearing from your history.

The receipt matters for a reason that has nothing to do with privacy. A wrong memory with a visible source is a bug you can report to yourself in ten seconds. A wrong memory with no source is a mood.

What you can do to a memory, and what each control does

Screenshots of control lists tend to look more generous than they are, so here is the table instead. The right-hand column is what the control has to do for the left-hand one to mean anything.

Two of these are usually faked. Delete that quietly keeps a copy, and exclude that only hides the conversation from search while still feeding extraction. We treat both as failures of the product, not of the user’s patience.

What happens to an answer after you delete the memory it used

This is the part worth walking through slowly, because it is the difference between a control and an animation. The scenario: you told Merrin in April that a friend, Alex, lives in Tokyo. In October Alex moves to Lisbon. Now you ask something that touches that memory.

1. Before the correction. The memory says Alex lives in Tokyo. An answer that mentions where Alex lives uses that record, and can point back to the conversation that produced it.

2. You correct it. Either you edit the record, or you say in conversation that Alex moved. If you say it, that statement becomes the newer claim.

3. The old record loses its standing. It is superseded, not deleted. It stays visible in your history as something you said, which is honest: it was true in April. What changes is that it is no longer used to answer questions about Alex.

4. Retrieval stops selecting it. A future question pulls the standing record, and the superseded one stays out of the context window. The answer changes because the input changed, not because the model was told to be careful.

5. Deleting instead of correcting. If you delete the record outright, step four happens and there is nothing to supersede. The answer has no memory of Alex’s city to offer, and it says so rather than guessing, until you tell it again.

The reason to care about step three is the honest part. Memory that silently overwrites itself is easy to build and impossible to audit. You would never be able to tell whether you said something or the system decided you had moved on.

Supersede, expire, resolve: the write contract most memory systems skip

This came up in a reply to us, and it is the sharpest framing of the problem we have seen from outside the product:

That supersede/expire/resolve trio is the write contract most memory decks skip. If contradictions only stack, retrieval keeps serving two truths. Owned resolution is what keeps standing state from turning into a polite museum.

a reply on X

Stacked contradictions are the default failure mode of append-only memory, and it presents as a personality problem rather than a data problem. The assistant is not confused. It is being handed two records and no rule for choosing. Three write operations do the work, and all three have to be owned by something, which is the part the reply calls out:

Supersede. A newer claim replaces an older one for the purpose of answering, while the older one keeps its place in your history. This is the operation that stops a memory from being a wall of true statements in the wrong order.

Expire. Some things are true for a week. A trip, a deadline, a temporary feeling about a job. Those records need to stop being standing state on their own, or the user becomes the garbage collector for a system that never forgets a deadline you missed.

Resolve. Two standing records that contradict each other cannot both be served. Either you decide, or a visible rule decides, but the outcome has to be one standing state. If nobody owns the resolution, retrieval serves both truths and the assistant looks confidently wrong. The build story has the development version of this failure: saved is not the same as remembered.

The user-facing half of that contract is smaller than the engineering half, and it is the half that matters for trust. You can see which records are standing. You can see what a correction replaced. You can reverse a resolution you disagree with. A museum preserves everything and means nothing. A memory that resolves keeps a small current picture and an archive beside it, clearly labelled.

What should it remember six months in?

The second reply we got was a question rather than a claim, and it is the right question:

Private space is a good way to put it. What do you want it to remember six months in that would make a real difference?

a reply on X

The answer is not everything you said. A six-month test filters hard, and passing it is the design constraint. What survives should be the things you would still defend:

• The people and why they matter. Not a contact list. Alex is a close friend from the Tokyo years, and that context is what makes a suggestion about calling him land differently in a hard week.
• Decisions with the reasons you gave. You chose to finish the project before changing jobs, because shipping mattered more than the offer. Six months later, the reasoning is the useful part, especially when the circumstances changed and you want to know what you were optimizing for.
• Promises and open loops. Things you said you would do, to other people and to yourself. Most of these are not tasks. They are standing facts about what you care about.
• Recurring themes. The topics that come back in different clothes, which is the thing you cannot see from inside a single conversation.
• The arc. A project’s shape, a relationship’s weather, a year of a job. This is what Merrin’s understanding demo is reaching for, and what the deep dive describes as connecting experiences over months rather than retrieving a fact.

And what should not survive: the mood of a Tuesday, the phrasing of a complaint, the half-formed thing you said out loud once and never again. Not because those are secret, but because keeping them makes the useful records harder to find. The honest limit is that a system remembering too much becomes noise, and a system remembering too little stops being personal. We have a strong default, not a solved problem, which is exactly why the controls exist.

Where this argument stops

Three limits worth stating plainly, because a memory feature invites you to expect more than software can hold.

It will be wrong sometimes, and the controls are how you fix that rather than a promise that it will not happen. It is not a therapist, a doctor, or an emergency service, and remembering you is not the same as understanding you. And because the memory lives on your device, losing the phone means losing the history unless you keep a backup, which is the trade the privacy policy describes in full, including the small set of things that do use a connection, such as model downloads and purchases.

If the objection you arrived with was that an AI remembering you is creepy, that instinct is correct. The answer is not to ask you to trust it. It is to give you the list, the receipt, and the delete key, and to make the last one change what the assistant says next.