I once turned off ChatGPT’s memory because it kept applying an outdated dietary preference. When it remembered correctly, I simply explained myself a little less and hardly noticed. When it remembered wrong, it carried that same wrong preference into new responses for weeks.
There is a clear gap between this experience and existing memory benchmarks. Many public evaluations first give a system a batch of history, then ask whether it can retrieve and correctly use it. Real products have to make an earlier decision: which pieces of information deserve to enter long-term state. Benchmarks care about whether a given history gets used; users will ask a different question — why was this sentence saved.
Missing a useful piece of information usually only makes the user repeat themselves once. Storing a wrong, outdated, or irrelevant piece of information can resurface across many subsequent sessions. The consequences of the two types of errors are not symmetric. Memory products should bias toward precision at write time — better to store less, prioritizing the reduction of false writes.
The recently published PASB study tested whether agents save sycophantic speech as long-term state and carry it into later, unrelated tasks. The researchers generated 1,600 test tasks from 100 base entries and ran 12 foundation models on two frameworks, Hermes-Agent and OpenClaw. The experiment code is also public. Each task first induced the agent into a sycophantic opinion through five rounds of conversation, then posed three new questions to observe whether the earlier judgment still influenced subsequent answers.
The data was split into two groups. In one group, the information stayed in the original session, and the mean per-round failure rate across four rounds was 45.0%. In the other group, the agent wrote the information into long-term state, and the mean was 71.9% — a difference of 27.0 percentage points. However, the two groups were divided based on the agent’s autonomous decision to write or not, rather than through a randomized controlled experiment, so this gap only shows that writing correlates with later failures and should not be interpreted directly as a causal effect.
The product significance of this result goes beyond the rise in failure rate. Errors that stay within a single session usually do not enter new sessions. Once written into long-term state, the same error can reappear again and again. Getting information right typically saves only a few lines of explanation; getting it wrong forces the user to constantly check and correct during subsequent use.
Existing benchmarks already go beyond simple Q&A. LongMemEval covers information extraction, cross-session reasoning, temporal reasoning, knowledge updating, and refusal, and also separately analyzes indexing, retrieval, and reading. MemoryArena further observes whether historical experience helps agents complete subsequent actions. STATE-Bench also places task results, reliability, cost, user effort, and informed consent into a simulated environment.
These evaluations are getting closer to products, but they still start from a batch of pre-prepared history or state. They can judge whether a system can find, update, and use information, but they rarely test whether a single sentence from daily conversation should become long-term memory. The write decisions where products are most prone to error are often already completed before the benchmark begins.
I have not found a public memory benchmark that covers the complete online closed loop. Existing evaluations do not have real users using the system continuously for weeks, nor can they see how many times a wrong memory made a user correct it, whether it reappeared after deletion, whether it crossed project boundaries, or what effect it had on long-term retention and paid conversion. Technical evaluations answer whether the system remembers well; products also need to answer whether users are willing to let it remember, and whether remembering ultimately reduced work or added hassle.
Borrowing from information retrieval, missing a piece of information that might be useful later is a false negative. Reducing such misses raises recall. Writing a piece of information that should not be stored long-term is a false positive. Reducing such mis-writes raises write precision. Real products should not give the two types of errors equal weight, because a miss usually leads to one extra round of clarification, while a mis-write can affect many subsequent uses.
Automatic saving further amplifies this asymmetry. A system can extract a large amount of potentially useful information from a single conversation, but what users actually want to carry forward is usually only a small fraction of it. For instance, if I mention on a business trip that I am in Berlin this week, that sentence can help arrange my immediate itinerary, but it does not mean I have moved there. If the system automatically saves Berlin as my long-term location, it may still tailor recommendations to Berlin weeks later. Web pages and materials we hand to AI for analysis can also be mistaken for the user’s own long-term opinions.
One study collected 2,050 memory records from 80 ChatGPT users. The researchers found that 96% of the content was proactively created by the system, while only 4% came from explicit user requests. 28% of the records involved personal privacy data, 52% contained inferences about the user’s psychological state, and 84% could be traced back to specific conversational context. This small sample does not represent all users, and 96% is not equivalent to the error rate, but it shows that the content of user profiles is largely determined by the system, with users only able to inspect and modify after the fact.
A deployment case from Mem0 shows the gap between storing more and storing precisely in even more direct terms. One user accumulated 10,134 memories over 32 days. After manual cleanup, only 224 were kept, and of those, only 38 required no modification. A single case cannot represent a system’s average performance, but it illustrates that accurately extracting a sentence and judging whether that sentence deserves long-term storage are two different tasks.
When the same mis-stored piece of information enters a larger scope of effect, the consequences continue to expand. Suppose a user says in one conversation that they dislike security checks. If it stays in the current session, it might only affect the reminder for that round. If it enters the cross-session profile, it can affect multiple projects. If it then becomes a reusable skill, the agent may be influenced when deploying or modifying files. The sentence has not changed, but the duration, scope, and capacity for action it can affect have all changed.
The low approval rate of candidate memories should not be masked by automatic saving either. It could stem from friction in the confirmation interface, or it could indicate that the information extracted by the system lacks sufficient long-term value. Product teams need to measure the two causes separately. If users consistently reject most candidates, removing confirmation entirely only raises write volume and cannot prove that these memories are genuinely useful.
There is currently no public data that shows whether AI memory has led to product-level success. ChatGPT, Claude, and Gemini are all expanding cross-session memory capabilities, but none of the three companies have published feature adoption rates, the proportion of sessions in which memory actually participates, incremental D30 retention, paid conversion rates, or how frequently users correct or delete memories.
When introducing the Dreaming architecture, OpenAI shared a set of internal evaluations. Factual recall success rose from 41.5% to 82.8%, preference compliance from 31.4% to 71.3%, and temporal state update success from 9.4% to 75.1%. These numbers show that the system has become better at retrieving and updating information, but they cannot show whether users are willing to let the system automatically save. Claude’s memory also launched for Team and Enterprise in 2025, gradually expanded to Pro, Max, and free users, and added project isolation, visible summaries, edit controls, and temporary conversations. Vendor investment in this feature and user acceptance of automatic writing need to be measured separately.
Product teams can first compare the no-memory condition against an ideal condition where correct and relevant memories are manually provided, to determine the maximum value personalization can bring in a given scenario. If the two sets of results are close, there is little point in continuing to optimize memory. Once it is confirmed that personalization is indeed useful, comparing three modes — automatic writing, AI-proposed with user confirmation, and entirely user-initiated saving — reveals which truly reduces the user’s workload.
Experiments of this kind should first measure write precision. Candidate approval rates, the frequency of user-initiated saving, and correction and deletion rates can help determine whether what the system saves aligns with user intent. The reappearance of outdated information, cross-project invocations, and incorrect actions reflect the downstream harm caused by mis-writes. On the other side, one must also measure how much repeated explanation memory saves, whether it improves task completion rates, and its effect on D30 retention and paid conversion. Only by placing the benefits alongside the losses from mis-writes can product teams know the net value of memory.
Biasing toward precision does not mean abandoning automation. AI can still discover candidate information, organize expressions, and suggest scope and expiration. Users only need to approve, modify, or reject. Long-term state takes effect only after user confirmation, and subsequent retrieval and updating can still be done automatically.
Explicit saving also cannot guarantee that a piece of information will remain correct forever. GitHub Copilot’s agent memory records specific code references when storing codebase memories, and reads the latest content from the current branch before use. Confirmed by the user at write time and checked by the system for validity at read time, the two steps address different problems.
Reliable memory should store less, store precisely, and let users know where each piece of long-term state came from and how to modify and undo it. How much is remembered is a secondary concern.