What It Means for AI to Remember

The model inside your AI assistant doesn't remember you. It is the same file of numbers the day after your conversation as the day before. When an assistant "remembers" your daughter's birthday, something more ordinary happened: a piece of software wrote a note, found it again later, and put it in front of the model, which read it as if it were true.

That same machinery is why an assistant can remember the birthday perfectly and then insist your project launches on a date you moved weeks ago.

Here is the idea worth carrying away. Memory is three jobs sharing one name: storing a fact, finding it at the moment it matters, and deciding whether to trust it. Products are built and sold mostly around the first. The failures that hurt live in the other two, and they're hard to see because the answer still sounds informed.

Where an AI system keeps what it knows

There are three places, and they differ most in what it costs to change them and who gets to.

The weights. Everything the model learned in training is encoded in its parameters, the numbers that make up the model. It stops absorbing new facts at its training cutoff and stays fixed until the lab trains a new version. Researchers can edit single facts inside weights, but the edits don't travel: a 2023 benchmark of 5,000 edits found that leading editing methods "fail to introduce consistent changes in the model's knowledge", and that simply putting the new fact in the prompt worked best. For anyone outside a lab, weights are memory you can read and can't write.

The context. The context is everything the model receives for one response: instructions, the conversation, attached documents, tool results. It is working memory in the strict sense. The model can use all of it, and it vanishes when the response ends. The harness, the ordinary software around the model, decides what goes in.

External memory. Notes kept outside the model: saved preferences, summaries of past chats, project files, a team's decision log. This is what products advertise as memory (product memory, in the consumer version).

The crucial point is that external memory never reaches the model directly. It counts only when something retrieves a piece of it and inserts that piece into the context of a particular call. A model "with memory" is a model reading notes that some other piece of software decided to put in front of it.

Picture a consultant at a desk beside a filing cabinet. What she learned in school is the weights. The desk is the context, and in this office it's cleared after every question. The cabinet is external memory, and a clerk brings files to the desk when a question arrives. The picture breaks in two places, and almost every memory failure comes from those two gaps. The files the clerk brings are often summaries someone wrote earlier, minus whatever they dropped. And the clerk picks files by how closely they resemble the question, which is a weaker test than whether they answer it.

How the clerk decides

Every memory product follows four steps: capture, store, retrieve, insert. Retrieval is where designs differ. In one family, the harness pushes: before the model sees your question, it searches memory and inserts the top results. The search usually compares embeddings, lists of numbers that represent meaning, so notes "close in meaning" to the question rank highest. In the other family, the model pulls: it gets a search tool and decides when to use it. OpenAI's help page says ChatGPT does not search your history for every response, only "when it is likely to improve a response".

Either way, a scoring rule decides what counts as relevant, and that rule is a judgment. One research system, Generative Agents (2023), published its rule. Each memory got three scores: recency, which decayed by a factor of 0.995 for every simulated hour since the memory was last used; importance, rated 1 to 10 by the model when the memory was written; and relevance, how similar its meaning was to the question. The three were added with equal weight. Every memory product makes some version of that choice, rarely in public.

Three jobs, three ways to fail

One invented example shows all three failures. A software team's shared assistant has memory turned on, and over the spring it has captured four notes about a release called Atlas:

1. Mar 3    Atlas ships June 12.                 (planning meeting summary)
2. Mar 3    Release sign-off for Atlas: Luis.    (planning meeting summary)
3. May 20   We slipped three weeks; QA found the payment bug.   (team chat)
4. May 28   Thinking of moving Priya off Atlas, keep this between us.
                                                  (manager's private chat)

In June, a support lead asks: "When does Atlas ship, and who signs off?"

One failure happened before anyone asked. Luis moved to another team in April, and the meeting where Ana took over sign-off was never summarized. No retrieval can find what was never written. That's storage failing. The other two failures are subtler.

Scroll sideways to see the whole figure

Stored, but not found

Note 1 resembles the question most: same project name, same verb, and the kind of answer the question wants, a date. The correct answer depends on note 3, which contains no "ship" and no date, and states a change relative to a date it doesn't repeat. A search that ranks by resemblance should put note 1 at or near the top and note 3 lower, possibly below the cutoff. Nobody ran this through a real system; it's what the mechanism predicts.

The gap between resemblance and relevance is widest for the notes that matter most, because corrections, exceptions and reversals are written in different words from the facts they modify. "We slipped three weeks" has no base date in it. "Except for enterprise customers" means nothing without the rule it qualifies. A store can hold every fact a question needs and still hand the model the outdated one.

The best public measurement is a benchmark called LongMemEval, published in 2025: 500 questions about long chat histories, including whether the user's information has changed. GPT-4o answered 87 percent correctly when given only the relevant sessions and 61 percent when given the whole history, same model, same questions. In a 2024 test, ChatGPT's memory feature scored 58 percent on a smaller set, against 92 percent when GPT-4o simply read the same histories. Products have changed since, but the gaps were real in shipping systems.

The fix starts at capture. A correction written to stand on its own, "Atlas release moved from June 12 to July 3, decided May 20", resembles the questions it answers.

Found, but no longer true

Note 1 was true when it was written, and nothing in stored text expires by itself. Without a date on each note, the model sees two claims with equal apparent authority and has to guess which is current.

The tempting fix is deletion, which erases history and, in products that derive memory from conversations, can leave other copies behind. OpenAI's help page says that deleting a chat "does not necessarily delete a separate saved memory created from that chat"; Anthropic says the same of Claude.

Superseding works better. The old note stays, marked as replaced by a newer one, and retrieval excludes or demotes replaced notes. Software teams already do this with decision records.

"Newest wins" is the obvious shortcut, and Anthropic's tool for consolidating agent memory replaces "stale or contradicted entries" with the latest value. It fails exactly when the newer note is a rumor ("I heard Atlas might slip again") and the older one is a decision. Authority comes from the source. A fact with an official home, here the release calendar, is true in one place, and a memory note about it is a claim someone made at some time.

A memory note is a claim someone made at a particular time. Where a fact has an official home, memory should point there instead of competing with it.

Found by the wrong person

Note 4 was said in private and captured into a store the whole team's assistant reads. Two different leaks are possible.

The read-side leak is the familiar one: retrieval returns a note without checking whether the person asking may see it. The fix is permission-aware retrieval, where every item carries the access rules of its source and the system filters by the asker's identity before ranking (Data Access Is the Real Integration Project).

The write-side leak is particular to memory. A document index copies documents that already had owners and permissions. An automatic note-taker creates new records and decides their scope as it writes them. When it errs toward sharing, a private remark becomes team knowledge with no permission to inherit.

Writing can also be attacked. Memory poisoning is a prompt injection, hostile instructions hidden in content the model reads, that writes to memory instead of acting immediately. In 2024 the security researcher Johann Rehberger showed that a malicious web page could make ChatGPT store attacker-written memories whose instructions then applied to future chats. Anthropic's documentation for agent memory states the general risk: "later sessions then read that content as trusted memory."

A note sitting in the context gives the model no evidence that it deserves belief. The harness has to decide which writes are allowed and which notes carry authority.

What a memory worth trusting looks like

Every failure above points to something the note itself was missing. Here is note 3 rewritten as a record a team could rely on:

Atlas release date: July 3, 2026.
Moved from June 12 after QA found a payment bug; the team chose
to fix it before launch rather than ship with a workaround.

source:         release review, 2026-05-20 (minutes linked)
recorded:       2026-05-20 by the assistant; confirmed by the release manager
owner:          release manager
scope:          team: Atlas
status:         current; supersedes the note of 2026-03-03
authoritative:  release calendar (check before quoting a date)

Scroll sideways to see the whole figure

The record has two parts, read by different things. The prose at the top is for the model: a self-contained claim with its reason, worded like the questions it should answer. The fields below are for the harness. Scope is checked before ranking, so a support lead never sees a manager's private note. Superseded records drop out. Confirmed records outrank merely captured ones. The date goes to the model so it can say "as of May 20".

The model can be told a date and asked to weigh it. It shouldn't be the component that enforces scope, because anything in its context, including injected text, can argue with an instruction.

When memory belongs to a team

For one person, a folder of plain notes is close to ideal. A team adds conflicting writers, readers with different rights, and a harder question: who decides what's true?

When one person's assistant notes a preference, the person is the authority. When an agent writes "Atlas ships July 3" into a team store, nobody has agreed yet that this is the team's position. My rule: treat an agent's write to shared memory as a proposal until someone who owns that fact confirms it, or until it's checked against the official source. Moving a note from personal to shared scope should be a deliberate act by a person, never a side effect of capture.

The second-order consequence lands on organizations. A shared memory nobody curates degrades; Anthropic's own documentation says agent memory stores accumulate "duplicates, contradictions, and stale entries" over time. Someone has to own the facts, review what agents propose, and retire what's obsolete. That's ongoing work, closer to keeping a ledger than to installing a feature. And it matters more with each model generation, because a better model turns accurate notes into better answers and misleading notes into more convincing wrong ones (Write for the Model That Doesn't Exist Yet).

"Bigger windows will make all this unnecessary"

The strongest objection deserves its best form. Frontier models now accept about a million tokens of context. If the whole history fits, why build a fragile retrieval step? Put everything in and let the model read it.

It runs into three limits. Size: someone with ten conversations a week averaging 3,000 tokens passes a million tokens in under eight months, and a team of twenty passes it in under two weeks. Use: LongMemEval's full-history condition is exactly the "put everything in" design, and it cost GPT-4o about 30 percent of its accuracy against giving it only the relevant sessions (What Fits Versus What Gets Used). Trust, the decisive one: if notes 1 and 3 both sit in the context with no dates, the model still has to guess which is current, and note 4 is exposed to the support lead whether it arrived by retrieval or by brute force.

The concession is real: bigger windows make retrieval more forgiving, and for one person's project a long context may beat a brittle retrieval pipeline. Permissions still have to be enforced before the text reaches the model.

Where a fact lives decides whether it can be forgotten

A fact in external memory can be dated, corrected and erased, provided erasure reaches the summaries, embeddings and caches derived from it. A fact in the weights has no clean equivalent. That's one more reason to keep personal and changeable facts in external memory rather than anywhere they might be trained into a model.

What to do

If you use an assistant with memory, look at what it has stored; the settings page or a direct question ("what do you remember about me?") shows most of it. Correct outdated facts with a date, so the system treats them as changes. Use a temporary or incognito chat for sensitive conversations. Remember that deleting a chat and deleting a memory are separate actions. And when a long conversation keeps returning to a wrong assumption, start fresh with a short, correct brief, because the wrong assumption is now in the context and every answer reads it again.

If you build memory into a product, store each note with its source, the date it was true, an owner and a scope. Filter by scope and status before ranking. Supersede instead of deleting, and point to the official source for facts that have one. Don't let untrusted inputs write into memory that later sessions trust. Then test retrieval with real cases whose right answer depends on a correction, an exception or a scope boundary, and check whether the right record reached the context separately from whether the answer looked good (Build an Evaluation From Your Own Work). A fluent answer from the wrong note looks exactly like a fluent answer from the right one.

If you lead a team, decide who owns which facts before an assistant starts capturing them. Memory without owners preserves whatever was said last.

Memory features will keep changing. The division of labor won't: the model reads, and something else decides what it reads. No model, however capable, can tell from the text alone whether a note is current, sourced and meant for the person asking. Those things have to be stored with the note when it's written, and kept true by the people who own the facts.

Check yourself

Why can the right note be stored and still never reach the model?

Retrieval ranks by resemblance to the question. Corrections and reversals are written in different words from the facts they change, so the outdated note can outrank them.

Why is "newest wins" not enough to keep memory true?

It fails when the newer note is a rumor and the older one is a decision. Authority comes from the source, so memory should point to the official home of a fact.

Why should scope be enforced by the harness and not by an instruction in the prompt?

Anything in the model's context, including injected text, can argue with an instruction. Scope has to be checked before the text reaches the model.