Memory, context management and persistent state, 6 of 26
Close the conversation.
It still knows you.
A client asks how you would architect the memory for somebody who has spent a hundred hours talking to their coach over six months. The usual answer is to put the transcript in a vector store, which retrieves what is similar to the current message and never notices a fact that stopped being true.
This keeps facts instead, eight at a time. Tell it something, start a new conversation, and ask.
Say something, or press one of the lines above.
What it knows, 0 of 8
Nothing yet.
Four things to try
01Tell it your name and where you live, then press the button that starts a new conversation.
02Ask it where you live. It has no transcript, so the answer comes from the memory or not at all.
03Tell it you moved. Watch the row change rather than a second one appear.
04Say nine unrelated things and watch what it decides to lose.
Four decisions
The reply never sees the conversation
Two model calls. One decides what is worth keeping out of what you just said. The other writes the reply and is given the surviving memories and nothing else. An agent handed the transcript will always sound like it remembers, because the answer is sitting in the prompt, and taking the transcript away is what turns remembering into a claim that can fail.
A correction replaces, it does not accumulate
"I work at Acme" and later "I left Acme" are one fact and its correction. A store that appends both will eventually tell somebody they work somewhere they quit a year ago, and it will be just as confident about it. Same key, one row, and the old value is written into the log rather than kept as a second truth.
Eight things, and the eviction is on the screen
Memory that grows forever is memory nobody can reason about, and something that quietly drops the oldest item is worse than something that says what it dropped. When a ninth fact arrives it is scored against what is already there. Worth more, and the weakest thing goes. Worth less, and the new one is refused, which is how a peanut allergy stopped being evicted to make room for somebody being on a train.
A name outlives a train journey
Each kind decays at its own rate. Identity does not decay at all, a preference halves in six months, a plain fact in three, and "I am on the train" halves in two hours. Repetition raises the score and cannot raise an ephemeral above a name, or the agent ends up certain about the train and vague about who it is talking to.
Tested without a model
38 tests on the policy, none of which call anything: the correction that must not become a second row, the eviction that must run before the write rather than after it, a year old name beating a fresh sandwich, repetition failing to raise a sandwich above the name, and the train journey that is refused rather than allowed to push out an allergy.
npx tsx lib/memory/policy.test.ts
Where this breaks
Everything here rests on the key. Two facts about the same thing filed under different names never meet, so the correction lands beside the original instead of on top of it, and both survive. A model picks those keys, and it is the part of this that would need a fixed vocabulary before anybody trusted it with six months of somebody's life.
Eight memories is also a demonstration size, chosen so the eviction happens while you are watching. A real one holds hundreds and needs search over them, which is where the vector store finally earns its place: not as the memory, but as the index into it.
The endpoint takes the same messages. The retrieval page is the vector store doing the job it is actually good at. The tool loop is what this would plug into. The whole list is 41 requirements from 114 job posts.