The moment a system remembers you, it takes on a responsibility it did not have before. What it recalls, what it forgets, and whether you can see and change either is not a storage problem. It is the place trust is won or quietly lost. This is no longer a fringe concern. The major labs have all shipped memory, and the way they built it tells you where the line sits.
Why memory is worth the risk
Memory is what turns a generic assistant into a product that feels like it knows you, and the commercial pull toward it is strong. The investors at a16z make the case that personalization is what lets an assistant approximate a real relationship, and that the products which learn you over time build the deepest hold on a market. That is their bet, not a measured result, and it is the reason the risk is worth designing for rather than ducking. The same recall that helps is the recall that can overstep.
Appropriate flow, not secrecy
The cleanest way to think about the line comes from the philosopher Helen Nissenbaum, whose framework of contextual integrity holds that privacy is not secrecy but the appropriate flow of information. Every context carries norms about who may know a thing and on what terms. A health worry told to a clinician is in place. The same worry surfaced to an employer is a violation, even though nothing was ever "secret." What changed is not the information, it is the flow.
That reframe matters for a memory system, because a memory system is a flow engine. It takes something a user shared under one set of norms and moves it into a later context under different ones. So the question is never just "may we store this," it is "into which contexts may this travel, and under what principle." A casual aside offered while venting is not consent to have it raised months later in a goal-setting session.
Models do not hold that boundary on their own. On a benchmark called ConfAIde, built directly on contextual integrity, GPT-4 and ChatGPT revealed private information in contexts people would not 39 and 57 percent of the time, and the leakage held even when the prompt told them to keep it private. Telling the model to be careful is not a control, because the model that leaks is the same model you are asking to police itself. Legible, controllable memory, enforced outside the model, is what keeps recall inside the context it was meant for.
Make it legible
Let users see what is remembered and change it. The labs have landed here in their own products. OpenAI's memory ships with controls to ask what it knows, tell it to forget, and turn it off. Anthropic built a memory summary you can read and edit, scoped per project so work does not bleed across contexts, plus an incognito mode that saves nothing.
Simon Willison, comparing the two, points to visibility as the deeper question. Claude exposes memory as tool calls you can watch it make, while a system that silently folds your past into every chat is harder to predict and to trust. The mechanism is the whole difference. Recall you can see happening is recall you can question, correct, and switch off. Recall injected invisibly is a set of decisions made about the user that they can neither inspect nor appeal. Legible, editable memory is the line between a product that feels attentive and one that feels surveilled.
Forgetting is a feature with legal weight
What a system forgets matters as much as what it keeps, and this is not only good manners. Under the GDPR's right to erasure, a person can require that their data be deleted, which means deletion has to be something your memory can actually do on request, not a promise you make and cannot keep.
Deletion is harder than a delete button, and the difficulty is architectural. A fact a user shared rarely lives in one place. It gets copied into rolling summaries, embedded into a vector index, and folded into derived state, so a single "forget this" has to reach all of them. Harder still, if that conversation fed model training, the fact can persist in weights that a delete request cannot touch, which is exactly why what you retain and train on is a decision to make before you collect, not after.
The architecture that makes erasure tractable already exists. The research system MemGPT treats memory as explicit, inspectable tiers a system pages in and out, rather than one opaque blob, which is the shape that lets you find every copy of a fact and remove it. Memory built as legible records is memory you can actually delete. Memory smeared across summaries and embeddings is memory you can only promise to.
Design the recall and the controls together
The thing that makes memory valuable is the same thing that makes it risky, so you design both at once, the recall that helps and the controls that keep it trustworthy. That is one half of a larger promise the product is making. The other halves are that it will not overstep by remembering more than it should, that its stored context cannot be turned into an attack on the user, and that it meets the rules it ships into. Memory is where a person hands you the most, so it is where you prove you can be trusted with it.
Sources and further reading
Work with Hunter Green