The first version of assistant memory in most products is a transcript. Keep the conversation, feed it back next time, call it memory.
It works for about a week. Then the transcript is longer than the context window, and you are choosing what to drop. Which means you were building a memory system all along and had not admitted it yet.
Three questions, and only the third is hard
What should be remembered? Not everything anyone types. A question asked once is not a fact about a person. "Can you make me a board for the trip" tells you nothing durable; "I do not eat meat" tells you something forever.
How should it be stored? Not as raw text you search with keywords. As something you can retrieve by meaning, because the useful recall is "did they ever say anything about their brother's wedding", and no string match gets you there.
Both of those have known answers. Extract candidate facts, score them, embed them, retrieve by similarity blended with recency and importance. It is engineering, and it took a while, and none of it required a new idea.
Who decides what is kept? That is the one that matters.
The default answer is the wrong one
The default is: the system decides, silently, and the user finds out by inference. They notice the assistant knows something. They cannot see the list. They cannot correct an entry. They certainly cannot make it forget.
That is a bad deal even when the system is right, and when it is wrong it is worse than useless, because a false memory misleads every answer that touches it. An assistant confidently building on something you never said is harder to recover from than one that knows nothing.
So the memory is a screen. Everything the assistant durably believes about you is listed, in plain sentences, and every line can be edited or deleted. Not a settings toggle labelled "personalisation" — the actual contents, as sentences, in a list you can scroll.
That page changed how we build the rest of it. Once a person can read what the machine wrote down about them, you stop being willing to write down guesses.
What we got wrong on the way
We stored memories nobody could see for weeks. The embedding table was empty in production, and everything downstream degraded quietly into keyword search. Five separate bugs in a chain, each individually plausible, and every health check green throughout. Nothing was broken. It just was not there.
We remembered breakfast. The connection engine kept noticing that Tuesday's breakfast resembled Wednesday's breakfast, and reported it as an insight. It was correct and completely worthless. Recurrence is not meaning, and a system that cannot tell the difference floods the useful signal out of its own output.
We collapsed people into preferences. Restoring an imported memory dropped its type, so a person became a generic fact about you. The graph still worked. It just no longer knew that Sarah was a person.
The through-line in all three: memory fails politely. It does not crash. It returns something slightly worse, forever, until somebody looks at the actual rows.
Where the line sits now
The assistant remembers facts, routines, and things it has concluded, each with an importance and each traceable to where it came from. It re-reads its own memory as content changes, so an edited note updates what is believed rather than leaving a stale copy behind.
And there is a region it cannot see at all. The Vault holds content that is withheld from the assistant entirely while locked. Never retrieved, never embedded, never available to be paraphrased into a response about something adjacent. The filtering-at-the-end version of this promise was the obvious design and we rejected it, because a filter is a promise that holds until a bug, and not having the data is a property of the system.
I would like to claim the line is in the right place. What I can actually claim is that you can see where it is, move it, and check afterwards that it moved — which is the part every product I have used gets wrong, mine included, until somebody makes the list visible.