Memory & Personalization UX

Memory changes what the product is, and users notice before you do.

A stateless assistant is a tool. Something that accumulates facts about you across sessions is a party that keeps a record, and people apply an entirely different standard to it — one they did not agree to in your onboarding flow, because at that point the product was still a tool.

• The failure mode changes in kind, not degree. A stateless agent that is wrong produces a bad answer you discard. A remembering agent that is wrong produces a bad answer that persists, re-asserts itself across sessions, and is applied to decisions the user did not connect to the original conversation.
• Stored inferences are the part that reads as surveillance. A user who says "I'm vegetarian" expects that to be remembered. A user whose messages caused the system to record "probably going through a divorce" did not consent to an inference, and the gap between those two cases is where every memory scandal lives. Facts the user stated are a different category from facts you deduced, and the interface should treat them differently.
• Recall failures and recall successes are both trust events. Forgetting something the user explicitly asked you to keep reads as carelessness. Remembering something they mentioned in passing eighteen months ago reads as unsettling. The band between those is narrower than it looks and it is set by whether the user knew the write happened.
• The engineering literature is about the write path; this is about the disclosure path. What gets extracted, deduplicated and stored is covered in memory write path architectures. Everything here is about what the user is shown, and the two are usually designed by different people who never meet.

Make the write visible, in the moment, at low cost.

The single highest-return change available in memory UX is a receipt: a small, unobtrusive, in-conversation acknowledgement that something was saved. It sounds trivial and it converts the entire feature from something done to the user into something done with them.

• Show it where the conversation is, not in a notification centre. A one-line chip — "Remembered: you prefer metric units" — attached to the turn that caused it. The user is already looking there, has the context to judge it, and can dismiss it in one action.
• Make undo available at the receipt, immediately. Correcting a memory five minutes after it was written should not require finding a settings page. The cost of dismissing must be lower than the cost of tolerating, or people will tolerate — and resent it later.
• Distinguish stated from inferred, visibly. "You told me" and "I noticed" are different claims and deserve different presentation. Inferred memories should carry a lighter touch, a plainer statement of what they were derived from, and a lower default confidence in how they are applied.
• Do not batch the receipts into a digest. A weekly summary of everything learned arrives after the facts have already shaped a dozen answers, and it is read by almost nobody. Timeliness is the whole mechanism.
• Say what will not be remembered, once, credibly. A clear boundary — "I don't keep anything from incognito chats", "I don't store payment details" — is worth more than a general reassurance, because it is specific enough to be checkable, and checkable claims are what build the calibrated trust that designing for trust is about.

Surface the memory where it changes the answer, not in a settings page.

Every product with memory eventually ships a management screen listing what it knows. That screen is necessary and it is not sufficient, because approximately nobody opens it. The place a wrong memory can actually be caught is the moment it is used.

• Attribute the influence inline. "Based on your note that you fly out of Heathrow" turns an inexplicable answer into a checkable one, and it costs a clause. Without it, a user experiencing a strange recommendation has no way to trace it and concludes the agent is simply unreliable.
• Show it only when it changed something. Annotating every turn with the full memory set is noise, and noise gets ignored wholesale — including the annotation that mattered. Attribution belongs on the specific claim it shaped, which is the same discipline as progressive disclosure.
• Make the attribution a control, not a label. If the user can click "that's out of date" on the cited memory and get an immediately different answer, you have built the correction loop in the place where the user has both the motivation and the evidence to use it.
• Never let a memory silently override an explicit instruction in the current turn. If the stored preference and the request conflict, the request wins and the conflict is stated. Silent overriding of a live instruction by an old fact is the most infuriating memory bug there is, and it is common.
• Give the management screen a real job anyway. It is where a user goes after an incident, and what it needs is search, provenance (when and from what), and bulk deletion — not a pretty list.

Correction and forgetting have to be real, and they have three different meanings.

"Forget that" is one phrase covering three distinct operations, and a product that implements only one of them will feel broken in the other two cases.

• Forget this fact. Targeted removal of one item, findable by the user in the words they would use. Requires that memories be individually addressable rather than smeared into a summary blob — an architecture decision made long before the UX conversation.
• Forget this conversation. Everything derived from one session, including facts extracted from it that now live elsewhere. This is the one most systems get wrong: the session gets deleted and the derived memories remain, so the user watches the agent keep referencing a chat they just erased.
• Forget everything about me. A full reset the user can find and complete without contacting support. It should be as prominent as it is rare, and it should tell the user what it did.
• Deletion must reach the copies or you should not call it deletion. Derived summaries, embeddings in a vector index, evaluation sets built from real conversations, and the provider-side retention of the messages that produced the memory are all separate stores. The inventory problem is the same one in retention and legal hold, and here it determines whether a user-facing promise is true.
• Correction has to stick harder than the original write. A user who corrects a fact and sees the old version resurface next week has learned that correction does not work and will not try again. If your extraction pipeline can re-derive the wrong fact from the same history, a correction must be a durable veto over that history rather than an edit to one row.
• Wrong memories are sticky in the model, not just the store. Once a false fact is in the context it influences the turn regardless of how it got there. This is the user-visible face of memory poisoning — the mechanism is identical whether the bad fact arrived by attack or by a mishearing.

Memory crosses contexts the user keeps separate.

People maintain boundaries that are invisible to a single-user memory store: work and home, this client and that one, the version of themselves that is visible to colleagues. A memory system with one scope will eventually carry a fact across a boundary its owner cares about.

• Scope memory to the context it was learned in, by default. A preference stated in a work project should not surface in a personal one without a reason. Global memory is a decision, and it should be an opt-in one for anything beyond durable, uncontroversial preferences.
• Shared agents need a visible audience. When several people talk to the same agent, the user needs to know whether what they say becomes shared knowledge before they say it — not after a colleague hears it repeated. The mechanics are in shared and multi-user agents; the UX obligation is a persistent, unambiguous indicator of who else can see this.
• Screen-sharing and handoff are the moment memory embarrasses someone. An agent that volunteers personal context in a demo, a support session, or a shared screen has broken a boundary the user thought existed. A mode that suppresses personal memory is a small feature that prevents a category of incident.
• Some things should be excluded from extraction outright. Health, finances, relationships, immigration status, anything a user is discussing precisely because it is difficult — a memory system that quietly retains these is one bad recall away from real harm. Deliberate categorical exclusion at extraction is cheaper and more defensible than trying to be careful at recall.
• Offer an off switch that is honest about its cost. "Turn off memory — I'll be less useful and I won't keep anything" is a legitimate trade and users respect being offered it. A memory system with no off switch reads as one that was designed for the product's benefit rather than the user's, and it is.

The four numbers that tell you whether it is working.

Memory quality metrics are usually retrieval metrics, which measure whether the store returned the right row. These four measure whether the user is being served, and they are the ones that move before a trust problem becomes visible.

• Correction rate on surfaced memories. Of the memories shown at write or at use, how many does the user reject? Rising means extraction is over-eager; near zero may mean nobody is seeing them, so read it against surface rate.
• Deletion events, and what precedes them. A user deleting memories is giving you the clearest possible signal about where the boundary is. Look at the conversation before the deletion, every time — this is the densest qualitative feedback the feature emits, in the sense of production feedback signals.
• Share of turns where memory changed the answer. If it is very low the feature is decorative and you are carrying its risk for nothing. If it is very high, small extraction errors are being amplified across everything the agent says.
• Memory-attributed complaints and off-switch usage. The blunt instruments. Users turning memory off after using it are telling you something a satisfaction score will not, and the reason is almost always a specific recall they can name.

One qualitative check is worth as much as all four: read the stored memory set for ten real users and ask whether you would be comfortable showing it to them. If the honest answer is "we would want to explain a few of these first", those are the ones to stop writing.

Related: agent memory for what a memory system is, memory write path architectures for the extraction step this page constrains, transparency and explainability for the wider disclosure question, and data governance for agents for the obligations behind the delete button.