An AI companion can bring up the birthday you mentioned once, months ago, and in the same conversation contradict the correction you made yesterday. That combination is only strange if you picture memory as one growing notebook. In the memory systems researchers and vendors have documented, it is a pipeline, and each stage of the pipeline can fail on its own.
Memory is a pipeline
A language model works on a bounded window of text: your recent messages plus whatever the app chooses to inject. For any single turn, that window is the model’s entire active world. Everything outside it has to be stored elsewhere and brought back deliberately.
The MemGPT architecture makes the mechanics explicit. It treats the context window the way an operating system treats fast memory: retrieving historical data that is missing from the window and evicting less relevant material to external storage. The Generative Agents work takes a different route to the same shape, recording each agent’s experience as a timestamped stream of natural-language memories and retrieving from that stream by scoring relevance, recency, and importance.
These are research systems, not a census of the consumer market, and a given companion app will rarely tell you which of these layers it has or how they are tuned. What the documented systems establish is the shape: an active context, persistent records outside it, and retrieval and update logic connecting the two. What you experience as “memory” is the output of that whole path.
A large context window is not the same as memory
Context-window size is the most advertised memory-adjacent number, and it measures something real: a bigger window lets more conversation stay active within a session, which genuinely helps continuity. Two research results caution against reading it as recall.
Lost in the Middle tested how models use long inputs in controlled retrieval and question-answering settings and found strong position effects: information near the beginning or end of the input was used more reliably than information in the middle, and performance often declined as inputs grew. RULER built a broader battery of long-context tasks, arguing that a model can pass a simple find-the-needle retrieval test while demonstrating only shallow use of a long input. The distinction I take from both: a stated context length is a specification. How well a model uses a full window has to be measured.
Neither result says long context is useless. They say a fact can be present in active context and still fail to shape the reply the model composes from it. And a context window of any size says nothing about what persists between sessions, which is where companion memory claims live.
What useful memory has to do
When researchers evaluate long-term conversational memory, they do not measure one thing. LongMemEval scores chat assistants on five separated abilities: information extraction (was the fact captured from conversation at all), multi-session reasoning (can facts stated weeks apart be combined), temporal reasoning (which version was true when), knowledge updates (does new information supersede old), and selective forgetting (does retracted information stop being used). LoCoMo evaluates very long-term conversational memory through question answering, event summarization, and multimodal dialogue generation across long multi-session conversations.
The design is the point: the people who measure memory professionally treat it as a bundle of separable abilities that fail independently. A system can extract well and update badly. It can answer direct questions and stumble on “what changed since June.” No single number summarizes that bundle, least of all a count of stored memories.
Where memory fails
Reading the architecture papers alongside the benchmarks, I group the ways companion memory goes wrong into four failure modes. The grouping is my interpretation, not a taxonomy from any one paper.
Storage is a property of a database. Reliable recall is a behavior of the whole pipeline—and the behavior is the only part you ever meet.
| Failure mode | Stage at fault | What it looks like in chat |
|---|---|---|
| Never stored | Store | A fact mentioned once is simply gone; no phrasing brings it back |
| Stored but not retrieved | Retrieve | The fact surfaces some days and not others, depending on how you ask |
| Stale or contradictory | Update | An old version resurfaces after a correction, or old and new blur together |
| Confidently inferred | Any stage; surfaces at compose | The app “recalls” something you never said, stated as though you had |
The first three are ordinary engineering failures with visible symptoms. The fourth needs careful labeling. Extraction and summarization mean a stored record can itself be an inference rather than a quote; retrieval can surface a plausible but wrong record; and the model composes fluent prose either way, with no built-in marker separating a verbatim fact from a guess. The literature I reviewed shows why this failure is possible and treats the adjacent abilities (updates, forgetting, declining to answer) as testable. It does not measure how often consumer companions fabricate history. I flag it because it is the failure a user is least equipped to notice: forgetting is comparatively easy to catch once you go looking, while a confident invention reads exactly like a memory.
One more distinction hides inside the third row: storing a correction and behaving on it are different properties. A system can display your updated fact in a memory panel and still retrieve and act on the older version.
A six-step test you can run
You cannot inspect an app’s architecture, but you can test its behavior. The protocol below is my proposed method, assembled from what the memory benchmarks measure. It is not a published benchmark, and I am not reporting results from running it here. It follows the evidence boundaries in my testing methodology.
- Write a test card. Pick eight to twelve items, foils included: a stable preference, a temporary plan, a dated event, a fact you plan to correct later, a fact you will mention only once (more than one item per category is fine), and two or three plausible items you will never say. Keep the card, with dates, as your ground truth.
- Spread the items across sessions. Introduce them days apart, with ordinary unrelated conversation between, so recall cannot ride on one recent transcript.
- Ask sideways. Probe later with paraphrases and indirect questions rather than your original wording. Verbatim echoes can be matched superficially; rephrased questions test whether the fact was kept, not the string.
- Run a correction. State a fact, later replace it, then ask for the current value, the old value, and what changed. Score each separately, and watch for answers that blend the two.
- Probe the foils. Ask about the never-stated items without hinting at an answer. The best response is uncertainty or a clarifying question. A fluent, confident answer is a false-recall failure, whatever else the app gets right.
- Test forgetting. If the product offers a delete or forget control, use it on one item, then probe for that item directly and indirectly in later sessions.
Score the categories separately (recall, false recall, update accuracy, temporal accuracy, deletion behavior) and note the app version and date, because these products change.
Deletion is its own test
Deletion feels like the final stage of memory, but it is a separate system with separate promises, and step six above can only probe part of it. One documented example: OpenAI’s help documentation, as I read it in September 2026, describes saved memories and reference to chat history as distinct mechanisms with distinct user controls, and notes that deleted saved memories may be retained for up to 30 days for safety and debugging. I cite this as one vendor’s documented design, not a market pattern or an effectiveness claim.
The general lesson: a chat that no longer surfaces a fact tells you about retrieval, not storage. Whether derived summaries, logs, or backups still hold the fact is a retention-policy question you cannot answer from inside the conversation. Evaluate deletion twice: behaviorally, with the probe in step six, and contractually, by reading what the privacy documentation promises about backend copies.
The question to ask
When a companion app shows you a stored-memory count or a context-window figure, neither number describes behavior. Ask behavioral questions instead. Does it find the fact when you phrase it differently? Does the correction beat the original? Does it know which version is current? Does it decline to remember what you never said? Does deleted mean gone, and according to which document? An app that answers those well with a modest store is doing memory. An app with ten thousand saved memories that fails them is doing storage.