Agent memory should not turn a user preference into evidence
Suppose a user once tells an assistant, "I trust AtlasDB more than Northstar." Weeks later, they ask which database survived a published reliability test. The old statement may help personalize the response. It is not evidence about the test. An agent that retrieves the sentence at the right moment can still produce the wrong answer with unusual confidence.
Retrieval asks whether a memory is related to the current request. A reliable system must also decide what authority that memory has. Preferences can shape recommendations. Prior factual claims may need verification. Newer instructions can replace older ones. Current evidence must beat a remembered belief.
A July 2026 preprint, MemSyco-Bench, gives this failure a useful test structure. The paper is marked as work in progress, so its results should not be treated as a settled ranking of memory products. Its central distinction is practical: finding a memory and using it correctly are separate problems.
A remembered claim can make an answer worse
In the paper's preliminary paired study, the authors inserted an incorrect memory into the context of three models. Accuracy fell for all three. The largest reported change was for DeepSeek-V4-Flash: accuracy dropped from 56.1% to 40.2%, while the authors' sycophancy measure rose from 24.3% to 52.3%.
Those figures come from a controlled benchmark, not production traffic. The mechanism is easy to recognize. A sentence retrieved from memory looks like context supplied on purpose. A model may treat its presence as a reason to repeat or rationalize it, even when the current question supplies stronger evidence.
The benchmark's data card contains 1,550 examples split across five behaviors. Its policy labels work as a starting point for an agent memory contract:
ignore_as_evidence: a user's belief must not become proof of an objective claim.constrain_to_scope: a fact that was true in one place or situation should not spread beyond it.defer_to_evidence: current, stronger evidence should beat a conflicting memory.update: a newer preference or fact should replace the obsolete version.use: valid personal context should still improve a genuinely personalized response.
That final behavior matters. A system that ignores every memory whenever conflict is possible has not solved the problem. It must reject invalid authority while keeping useful personalization.
Give each memory a role, scope, and version
Many memory stores save text, an embedding, a timestamp, and perhaps an importance score. That is enough to retrieve a passage. It is not enough to decide how the passage may affect an answer.
A practical record might include fields like these:
content: "User prefers meetings before noon"
role: preference
scope: personal_schedule
valid_from: 2026-07-18
supersedes: memory_104
source: user_statement
authority: personalization_only
This schema is an engineering recommendation, not a format prescribed by MemSyco-Bench. Its job is to keep meaning attached to the text. role separates a preference from a verified fact. scope limits where it applies. supersedes provides an update path. authority prevents a preference from being cited as external evidence.
The generation step should receive the policy decision as well as the retrieved text. For example: "Use this memory only to tailor the recommendation. Do not use it to establish product performance." That instruction is narrower than a general warning to be careful with memory.
Successful retrieval can still produce the wrong answer
MemSyco-Bench includes a diagnostic that separates retrieval from reasoning. In valid evidence-conflict cases, A-Mem retrieved both the evidence and the conflicting memory every time, yet its reported answer accuracy was 25.91%. Mem0 reached 70.0% when it retrieved the evidence alone, but 36.36% when it retrieved both evidence and memory.
Update cases show a similar problem. A-Mem retrieved both the old and new memory in 98.57% of cases, while answer accuracy was 24.06%. For Mem0, accuracy was 53.06% when only the updated memory appeared and 26.38% when both versions appeared.
These are benchmark-specific observations, not universal product verdicts. They explain why a retrieval hit rate cannot stand in for memory quality. A trace should record which memories were selected, their roles and versions, whether they conflicted with current evidence, and which policy the agent applied. Our guide to agent traces covers the wider observability design.
A generic caution prompt has a cost
The researchers also tested a broad caution instruction. In one DeepSeek-V4-Flash setting using the full dialogue, conflict accuracy improved by 31.63 percentage points, while valid personalized-memory use fell by 17.01 points. The warning reduced agreement with bad memories, but it also made the model less willing to use good ones.
"Never trust memory" trades one blunt failure for another. A typed policy can say something more useful: use preferences for personalization, require evidence for objective claims, prefer the current version after an update, and keep local facts inside their original scope.
Run a memory-dose test for each model
IBM Research tested ALTK-Evolve, which distills guidelines from agent trajectories and retrieves relevant guidance for later tasks. Across eight models on AppWorld's 585 tasks, the useful amount of memory varied substantially.
For gpt-oss-120b, curated retrieval improved task goal completion by 16.1 percentage points while increasing token use from 110K to 116K, about 5%. Giving the model the full guideline set raised token use to 166K, about 51%, with a smaller gain. DeepSeek-V3.2 gained 9.5 points with the full set while token use rose from 148K to 263K, about 78%. GLM-5 showed no measurable gain in the reported runs.
The study used one simulated application benchmark, and its results do not isolate every difference in model capability, context handling, or available headroom. The useful conclusion is narrow: memory dosage is a model-and-task variable. The open-source ALTK-Evolve repository makes its guideline extraction, consolidation, and retrieval workflow inspectable.
Test four conditions on your own tasks:
- No memory beyond the current request.
- Raw recent dialogue.
- The complete stored memory or guideline set.
- A curated subset selected for the task.
Measure task success, token use, latency, evidence conflicts, stale-memory use, and valid personalization. Run the same cases through the models you actually deploy. A multi-provider endpoint such as api.ish.chat can make that comparison easier, but the evaluation set and grading rules should remain yours.
Put the policy between retrieval and generation
A safer memory path has a decision stage between search and response:
- Retrieve candidate memories and current evidence.
- Classify each candidate by role, scope, source, and version.
- Resolve updates before generation.
- Block preferences and unsupported claims from serving as factual evidence.
- Pass valid memories with an explicit usage policy.
- Log the selected policy and grade the final behavior as well as retrieval.
The systems paper Agent Memory: Characterization and System Implications of Stateful Long-Horizon Workloads also measures memory as a pipeline. It characterizes construction, retrieval, and generation as distinct phases with different costs across ten systems and two benchmark suites. Product tests need the same separation.
An agent should remember that a user prefers early meetings. It should not turn that preference into evidence that mornings make everyone more productive. Store the distinction, enforce it after retrieval, and put both good-memory use and bad-memory resistance in the release gate.
