← Blog

AI Long-Term Memory: Similar Is Not the Same as Known

September 26, 2026

中文

The default recipe for AI long-term memory is: chunk the conversation, embed the chunks, store them in a vector database, and retrieve by similarity next time. Chapter 8 of the AI Agent book walks through how to build exactly that.

It is good at "what have we talked about that's related?" But when users actually lean on memory, they tend to ask a different kind of question: "Does my car need gas?" "How many weddings did I go to this year?" "Which university does my advisor teach at?" Those questions want facts, not similar passages.

For the past few months I have been building a personal memory system on top of Tensor Logic. This post is about one experiment that made me change the design, and the engineering rules that came out of it.

The experiment: the location was right, the knowledge didn't follow

The system first learns shared common sense from synthetic data. I had a language model generate 1,800 small worlds, about 1.27 million relations in total: which things belong to which kinds, and what each kind typically has, is used for, and depends on.

Then a new thing X arrives. The system knows exactly one fact about it: "X is a K."

I asked two questions:

  1. Does the right kind rank first?
  2. Does X inherit the facts already written down for K? If the system knows "K is used for cooking," X should be used for cooking too.
QuestionEmbedding scoreWritten rule
Right kind ranked first14 of 16—
Inherit the 24 facts written for K2 of 2424 of 24, each with its reasons
40 other facts with no record in the system1 of 40 guessed right"No evidence" for all 40

For the embedding column, a hit means the correct candidate ranked first. The ranker always returns a top candidate and has no abstain state; the rule column executes explicit inheritance. This is therefore not a contest between two equally tasked algorithms. It asks a narrower engineering question: can this ranking path substitute for inheritance? In this audit, it cannot.

The first row needs a careful reading. In 14 of 16 cases the right kind ranks first, and those 16 cases are a small check. The vectors are not close to the kind itself: the mean cosine is −0.18. The second row is the problem. Ranking the kind first is not the same as having K's facts. A vector gives a ranking, not a list of facts. Being filed under "hospital" does not make you a doctor.

A tempting shortcut is to set X's vector equal to K's. That makes this particular score perfect, but amounts to declaring that X is K. It breaks the moment X belongs to two kinds, as an electric car is both a car and an appliance. Compositional and multi-vector designs can avoid that exact shortcut; they still need a separate test of whether ranking implements the required inheritance semantics.

The third row matters just as much. Those 40 facts are true, but I deliberately left them out of the system. The rule path answered "no evidence," which is correct: it doesn't know. The embedding path produced an answer every time and was right once. A memory that confidently answers what it doesn't know is much harder to live with than one that says "I don't know."

Here is what the rule looks like, schematically:

X is a K               ← the user said so (with source)
K is used for cooking  ← shared common sense (admitted)
───────────────────────
X is used for cooking  ← derived; the two lines above are its evidence

No magic. The reasoning is just written down.

Split the work: look up, then derive, then guess

That result is why my memory system now sorts every answer into one of three tiers, and every answer says which tier it came from:

TierSourceHow it answers
RecordedSomething the user actually saidReturned as is, with its source
DerivedUser facts + shared common sense + a written ruleThe conclusion plus the full chain of reasons
GuessedNone of the above; a genuine gapCandidates are allowed, labelled "model guess," never promoted to fact

There is a fourth legitimate answer: no evidence. It is not a failure. It is the system describing its own boundary honestly.

Embeddings are not thrown away. They change jobs: proposing candidates, fuzzy recall ("what was the name of my friend who works on chips?"), and ranking genuine gaps. They just stop being the source of truth.

Four rules I adopted after the experiment

1. Settle "who is this?" before any reasoning. Most memory errors are not reasoning errors. They come from treating two things as one, or one thing as two. So a name binds only to an exact name or a registered alias; fuzzy matches can suggest candidates but never bind. "Paris" and "Paris Hilton" must not merge because they look alike, and "巴黎" joins "Paris" only when the user has made clear they are the same place. If the system can't tell who someone is, it says so.

2. Let code do the counting. "How many weddings did I go to this year?" is not a job for a language model. Each wedding is an event with a date, and code counts them. If a few events have no date and can't be placed in this year, the answer is "at least N, and a few are undated," not a confident wrong number. Repeated updates to one state, like a weight logged three times between March and May, collapse into one current value rather than counting as three things.

3. Never write derived conclusions back as facts. This is the easiest rule to skip. If today's derived "X is used for cooking" is stored as a fact, tomorrow it becomes evidence for something else, and the day after it may be propping up itself. That is how an error turns into "common knowledge." Derived conclusions are recomputed every time; the fact store holds only what was actually said and checked.

4. Use the language model offline only. Extracting facts from conversations and consolidating entities is done by a large model in the background. Answering a question makes no model call. The same question gets the same answer every time, and every answer can be traced to where it came from.

Rules are equations, but for now people still write them

Building this framework means writing inheritance down as an equation. Once that equation is explicit, a large block of weights is not needed to learn the same step.

In memory, that is almost literal. "X is a K, K has property P, so X has property P" is an equation. Written once, it passes all 24 facts down correctly, with reasons. Asking embeddings to learn inheritance got 2 of them.

The next question is who writes the equations. I tried having a large model write facts, rules, applicability conditions, and sources in one pass. None of the 12 rules from the first version survived independent review. Later versions sometimes passed format checks and still failed semantic review. So the current practice is: few rules, written by people, reviewed; the model proposes candidate facts into a review queue and cannot write to the fact store directly.

That does not mean models can never write rules. It means that in the one place where whatever is written down will be treated as true, a person can't be taken out of the loop yet.

Conclusion

The core question for AI long-term memory is not "how similar is it?" but "how do you know?" Similarity answers the first. Splitting answers into recorded, derived, and guessed answers the second.

Almost a year ago, in Tensor Logic: A Brain-Like Architecture, I wrote that logic and learning can run on the same substrate. Looking back, the more accurate version is that they can share a substrate but need different jobs: logic is responsible for knowing, and learning for guessing a bit better.

An earlier synthetic corpus produced a bigger-is-worse result on transfer. That is the next post: One Transfer Experiment: Bigger Fits Better, Transfers Worse.