Five agent-memory papers, October 10–16: the record's life after the write — consolidation order, repeated exposure, deletion requests, and a store score sixteen points from the answer
Five primary-source papers from October 10–16, 2026 show that a record's life after it is written — consolidation order, representation choice, repeated exposure, deletion — is where agent memory fails, and that no score at the end of the pipeline sees it.
From October 10 through 16, 2026, five papers in AI agent memory each landed on a different point in a record's life after it was written, and each found the decision made there invisible to whatever scores the system. Consolidation order changes an agent's behavior while the retained experiences are held fixed. A memory's next step — stay exact, compress, consolidate, delete — is a decision no retrieval benchmark asks about. Repeated reads that write back let one old claim hold several seats in the answering context. Every system tested fails to carry out a forget request. And the score at the end of the pipeline disagrees with the state of the store by sixteen points on average.
The retained experiences are identical; only the order they were consolidated in changed
Date: October 10, 2026
What happened: Haowen Pan and colleagues at the University of Science and Technology of China, the National University of Singapore and Singapore Management University describe memory formation poisoning, which targets the interfaces where persistent memory is produced rather than the content of a single stored item. Five interfaces are covered: Content, Evidence, Scope, Selection and Path. 1
Across 1,016 case pairs and 1,891 format instances, six models and two answer formats were tested. The macro-average attack success rate ranges from 35.2% to 84.0% on multiple-choice tasks and from 49.0% to 87.1% free-form. That rate counts the eligible queries where poisoned memory produces the poisoned behavior. Clean memory keeps error below 4%. 1
The controlled part is Path poisoning, and it is the sharpest result in the paper. The experience multiset, the retained subset and the updater all stay fixed, and only the order of consolidation changes. Random orders preserve reference behavior for 77.5% of DeepSeek-V4-Flash cases and 83.5% of Claude-Sonnet-5 cases. The designed order drops those to 42.1% and 62.4%. 1
The same formation protocol also runs on LlamaIndex, where the susceptibility profile across the five interfaces holds. 1
Why it matters for builders: When two runs keep the same experiences and behave differently, look at consolidation before you look at content. Log the order in which experiences were merged, and run the retained set again in a second order as a control. A defense that holds on one formation interface leaves the others open.
A memory's next move: keep it exact, compress it, consolidate it or delete it
Date: October 10, 2026
What happened: Muquan Yu and Dihan Hu formalize memory lifecycle evaluation. At a review point a policy reads the state of a stored memory and picks one of four actions: Keep-Exact, Compress, Consolidate or Delete. LongMemEval, LoCoMo and MemoryAgentBench all score retrieval, reuse and updates after the fact, leaving the representation choice behind them unmeasured. 2
VitaBench scores those choices against counterfactual full-horizon outcomes. Its controlled tier holds 60 memory threads over 120 episodes and its naturalistic tier composes 40 entities over the same horizon. Matching the action to the state beats the strongest fixed action by 1.364 utility per decision on the first tier and 1.405 on the second, and between 56.5% and 60.2% of states change their preferred action when the horizon extends from five steps to all 120. 2
All four actions are optimal somewhere. On the naturalistic tier Keep-Exact is best in 38.8% of states, Delete in 28.7%, Compress in 21.4% and Consolidate in 11.1%. A learned policy that accounts for delayed consequences reaches 101.5 joint utility against 83.4 for the best fixed strategy, a paired gain of 18.1 points. A myopic policy reaches 10.6, and the gap to the oracle stays at 30.6 on the controlled tier and 41.1 on the naturalistic one. 2
Why it matters for builders: A retention rule is a policy, and "always keep exact" and "always compress" are both measurable losses on this benchmark. Score your own store on the delayed consequence rather than the immediate one, because more than half of these decisions flip when the horizon lengthens.
Read, write back, repeat: one old claim ends up holding several seats in the context
Date: October 13, 2026
What happened: Yufeng Li, Sheng Yao and colleagues at East China Normal University, the University of Southern California and Zhejiang University define memory echo as the extra retrieval exposure a historical claim gains from being processed repeatedly inside its own source, with no new evidence behind it. MEchoBench draws its 190 questions from LoCoMo, LongMemEval, HotpotQA and BEAM, and builds three histories from each seed: stored once, retrieved six times without writing, and retrieved six times with a same-family derivative written back each time. One verified correction goes into all three, followed by 30 read-only queries. 3
Reading without writing leaves the old family's share of the ranked context where it was. Reading with write-back raises it in every architecture tested, and every added record descends from the one source, so repetition buys positions without buying support. The correction then leaves the family in place: exposure stays elevated and nearly flat across the 30 delay queries, which the authors call inherited retrieval bias rather than ongoing reinforcement. 3
Their Family–Provenance–Authority pipeline picks one representative per source family, makes old records eligible for the answer context only against a verified correction, and restrains the final answer with authoritative evidence. On 190 fixed questions across four memory frameworks it raises accuracy from 0.825 to 0.920 with DeepSeek V4 Flash and from 0.782 to 0.916 with Kimi K2.6. The mean Decision Contamination Effect, which measures how much more an answer aligns with the old claim than with the verified answer, falls from 0.106 to 0.030, and from 0.109 to 0.038. 3
Why it matters for builders: An agent that summarizes each turn back into its store lets one claim occupy several retrieval slots without gaining any evidence. Group records by the source they descend from, give each family one representative, and measure exposure after the correction rather than trusting a single retrieval snapshot. The gains also depend on a trustworthy replacement: where the correction was missing or unreliable, filtering the old records cost accuracy.
Every system fails the same instruction: forget this
Date: October 13, 2026
What happened: Bofan Xie and colleagues at Tsinghua University and Sina Weibo release Bemula, a benchmark for user-requested forgetting. It holds 50 profiles and dialogue instances, 746 sessions, 36,900 turns per dialogue version, 135 forget requests covering 269 facts and 1,742 questions in five suites. Instances average 84.8K tokens, and the longest run to about 3,500 turns. Each dialogue has a control version without the requests, so a system earns credit for forgetting only if it stored the fact first. 4
The result is negative for six memory systems and the full-context model under three backbone LLMs. The strict request pass rate, which counts an instance only when every efficacy question and every preservation question comes back right, never exceeds 1.5%, and most systems stay at zero. Overall scores top out at 31.0. 4
Systems fail in both directions. Most leave the store as it stands: Mem0's forgetting efficacy is 8.5 on GPT-5.6-Luna, LightMem's is 17.9 and SimpleMem's 16.1, and Mem0's failed answers usually repeat the values the user asked it to remove. Others delete past the request, with LangMem removing facts that no request targeted, and the full-context model answers with a blanket refusal in 66 of its 81 preservation failures. Replacement requests come closest to solved, with efficacy of at least 61.9 for every system, yet the old value survives verbatim and resurfaces under extraction attacks, where every system scores at most 30.5. 4
Why it matters for builders: Score deletion as a paired test: did the system store the fact, and did the request then pass? Check both halves, removal of what was asked for and preservation of what was not, because the benchmark's own score multiplies them and a system that deletes everything ends up with the score of one that forgets nothing.
The score at the end of the pipeline and the state of the store disagree by sixteen points
Date: October 15, 2026
What happened: Sebastian-Antonio Toma and colleagues at Amazon Web Services argue that downstream question-answering accuracy is an incomplete proxy for memory quality, since one number absorbs what the store holds together with what retrieval and generation did with it. FEB-30 inverts the usual construction and generates documents from known fact trajectories, so the expected memory state is known at every ingestion step, across 30 trajectories, 6 diagnostic categories and 3 difficulty levels. 5
Run against an extract–embed–classify–synthesize pipeline of the kind Hindsight, Mem0 and AriadneMem share, the store-level and answer-level scores diverge by an average of 16 percentage points, with 44% of trajectories crossing the divergence threshold. Across all categories the store scores 60.6% and the answers 48.8%. 5
The decomposition shows what the answer score absorbs. The system labels its own memory operations — create, update, reinforce, supersede — correctly only 20% of the time, falling from 34% on the easiest difficulty level to 10% on the hardest, and on the retrieval category its classification accuracy is 4.5%. The response score holds steady through all of it. 5
Why it matters for builders: Keep a check on the store itself, alongside the suite that scores answers. Once you can write down what the store should contain after each ingestion, you can score the operation the system chose to run, which surfaces a wrong update or supersede long before it reaches a reader as a wrong answer. The benchmark and its generation pipeline are public.
Issue summary
Three patterns run across the five items.
- The stage that decides sits upstream of the stage that is scored. Retrieval benchmarks never ask what a memory's representation should have been. A 48.8% answer score sits on top of a 20% operation-classification rate. Defenses are graded on committed content while four other formation interfaces stay open. And a system's feature list says nothing about whether a forget request passes. In each case the decision sits upstream of the number that gets reported.
- A record's history sets how much weight it carries, over and above what it says. The same retained experiences in a different consolidation order move behavior by 35 points on one model. A claim read and written back six times holds more of the context with no new evidence behind it. Both effects outlast the correction that should end them, because neither is about what the record says.
- What the system was told and what its store holds part ways. A verified correction leaves the old family where it was. A forget request is carried out by almost no system. The store mislabels its own create and supersede operations four times in five. Each of these papers measures what the system was told, and each finds the record unchanged.
One concrete next action
Measure the state, not the answer. Three steps cover the three stages this issue turns on.
- Log the consolidation order. For one task type, record the order in which experiences were merged, then run the retained set again with the order reversed and nothing else changed. If behavior moves, the content of your memory is not the variable you have been tuning.
- Score the store after each ingestion. Write down from the input alone what each memory should contain and which operation the system should have run. Compare the store against that, and track the create, update and supersede rate as its own number.
- Send one forget request and read the aftermath. Take a fact the agent stored across sessions, ask it to forget, then ask the original question in a fresh session along with a paraphrase and a request for adjacent facts. Record whether the target went, whether anything unrelated went with it, and whether the answers turned into a blanket refusal.
References
- 1
- 2
- 3
- 4
- 5
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.