Memory: decide what your product remembers

Every memory decision sits on two axes

Nothing in that demo needs better engineering; it needs a policy. The policy becomes writable once you sort any memory feature with two questions: does the record survive the conversation or die with it (session versus durable), and did the user hand the fact over or did the product deduce it from behavior (explicit versus inferred)? The two questions make four quadrants, and each quadrant carries a different obligation.

• Session and explicit. You paste your travel dates into a trip planner, and it uses them until the conversation ends, which is ordinary context that surprises nobody.
• Session and inferred. A writing assistant infers from your edits that you want shorter sentences and tightens its style for the rest of the draft. The stakes stay low because the deduction dies with the session.
• Durable and explicit. You tell an email assistant to always sign off with your first name, and next month it still does. The user handed the fact over expecting it to be kept, so keeping it is the feature working.
• Durable and inferred. A support product concludes from months of billing questions that a customer is probably in financial trouble, stores that conclusion, and works it into a later answer. The user never said it, never saw it stored, and meets it for the first time when the product repeats it back.

The last quadrant is where the demo went wrong and where the creepiness lives, and teams enable it by accident because "learn from user behavior" reads as a personalization win right up until a user watches their own file being read back to them.

Memory is a pipeline of stored records, not model recall

Precision about the mechanics matters, because it makes the policy writable. The model stores nothing between calls; every request starts from an empty window. What products call memory is a pipeline the product runs:

• Write. After a conversation, the product writes a record: a stated preference, a fact about the account, a summary of what happened.
• Store. It stores the record in a database, usually with an index entry so it can be found by meaning later.
• Retrieve and inject. At the start of a future conversation, it retrieves whichever records look relevant and injects them into the prompt, and the model is handed them like any other context.

These are the mechanics from Retrieval: let the product look things up before it answers, pointed at the user's own history instead of your knowledge base. MemGPT, a 2023 research system, formalized the same picture by treating the context window as scarce working storage backed by a larger external store.

The pipeline framing turns an ethics question into engineering decisions. Every stage is a decision you own: what gets written down at all, how long it is kept, what gets retrieved, and what gets injected in front of which audience. If memory were a property of the model, you could not govern it. Because it is a series of product decisions, a one-page policy can cover all of them.

Consent design: let users see, edit, and delete

Memory is a consent feature before it is a capability: what the product remembers is a promise you make in the interface, not a database default.

The mainstream assistants set the bar. ChatGPT's memory controls and Claude's both give the user a page listing every stored record, the ability to edit or delete individual entries, and a switch that turns memory off entirely, and both tell the user when something new is saved. Whatever your product stores should pass the same three tests without a support ticket: the user can see the full list, change any entry, and remove any entry.

Announcement is the half of consent that teams skip. A product that says "I've noted that you prefer bullet summaries" spends one line of interface and collects consent at the moment the record is written; a silent product stores the same record and turns it into a surprise months later. Whether that surprise delights or alarms depends on the user's mental model of the product, the picture Mental models: show people what the system can do teaches you to manage. A drafting tool that keeps your style preferences is doing exactly what an assistant is expected to do, so the memory reads as service. The same move in anything health- or money-adjacent reads as monitoring, because nobody's mental model of a billing bot includes keeping a file on their situation.

Retention and deletion are product features, not cleanup

Forgetting is a feature you design, not a maintenance task.

Forgetting on request. "Forget that" has to work as a first-class command, both in the conversation and from settings, and it has to work the first time. GDPR's right to erasure makes this a legal obligation for users in much of the world, so treat the regulation as the floor and design above it.

Expiry by default for sensitive classes. Records touching health, finances, legal matters, or other people should expire on a short clock unless the user explicitly asks the product to keep them. The demo failure was an old record that had no business outliving the week it was created.

Deletion that actually deletes.

Deletion must remove the record and everything derived from it: the stored entry, the index entry that makes it findable, and any summary or profile computed from it.

A memory that disappears from the visible list but persists in an embedding index or a weekly profile summary is not deleted, it is hidden, and retrieval will eventually bring it back. Trace every copy the pipeline makes, the same exercise you ran in Data: what flows in and what leaks out, and make the deletion path cover all of them.

Write your memory policy

You now have everything the policy needs, and it fits on one page.

• The quadrant rules. Write one line per quadrant: session-explicit is always allowed, session-inferred expires with the conversation, durable-explicit requires an announcement when the record is written, and durable-inferred requires the user's confirmation or does not exist.
• The visibility rule. Write it as one sentence: the user can see, edit, and delete every stored record from inside the product.
• The retention table. Give each class of record a row covering how long it is kept by default and what its deletion path removes, with the sensitive classes on the shortest clocks.

These lines drop straight into the Knowledge Charter, the part's capstone artifact you will complete in Write your Knowledge Charter and ship a product that knows its facts; the fillable version has a section waiting for them.

Try it now

This drill takes about 20 minutes and costs nothing.

Open two products that keep memory. Pick two AI products you use that carry facts across conversations; the mainstream assistants all expose their controls in settings, as do most memory-keeping writing and meeting tools.

Read what each says it remembers. Find the memory or personalization page and read the stored list end to end, noting how much of it you knew was there.

Find one inferred entry. Look for something you never typed as a fact: a preference deduced from your behavior, a topic you were filed under, a detail assembled from several conversations, and note whether the product told you when it was saved.

Check the exits. Edit one entry, delete another, and find the switch that turns memory off entirely. Then open a fresh conversation and probe whether the deleted entry is really gone.

Write the policy you would ship. Draft one page for your own product: the quadrant rules, the visibility rule, and the retention table with its deletion path. Keep it; it feeds the Knowledge Charter directly.

Chapter Summary

• Sort every memory decision along two axes: does the record survive the conversation (session versus durable), and did the user state the fact or did the product deduce it (explicit versus inferred).
• Durable inferred memory is where the creepiness lives, because the user meets a fact they never stated at a moment they did not choose. Keep that quadrant off by default.
• The model stores nothing between calls. Memory is a pipeline your product runs: write a record, store it, retrieve it later, and inject it into the prompt.
• Because every stage of that pipeline is a product decision, a one-page policy can govern all of it.
• Memory is a consent feature before it is a capability: announce what is saved when it is saved, and give users a full list they can see, edit, and delete.
• The same remembered fact delights in a drafting tool and alarms in anything health- or money-adjacent, because it either fits or breaks the user's mental model of the product.
• Give sensitive record classes short default lifetimes, and make "forget that" work as a first-class command.
• Deletion must remove the record, its index entry, and everything derived from it, or the memory is hidden rather than gone.
• Everything you keep still has to fit into a finite prompt at answer time, which is where Context budgets: fit the right facts into a finite window picks up.

Sources

• Packer, C., Wooders, S., Lin, K., Fang, V., Patil, S. G., Stoica, I., and Gonzalez, J. E. (2023). MemGPT: Towards LLMs as Operating Systems. arXiv preprint.
• OpenAI. Memory and controls in ChatGPT, help documentation (last verified July 2026).
• Anthropic. Memory in Claude, help documentation (last verified July 2026).
• European Union (2016). General Data Protection Regulation, Article 17: Right to erasure.