September 7, 2026 — Suppose you swap the model behind an agent that has been accumulating memory for six months. The database is still there, the vector index still loads, retrieval still returns eight chunks, and a spot check looks fine. What did that check actually establish? Three papers examine what can go wrong even when the store and retrieval system still run.
Can the new model still use the old memory?
Does Your Agent’s Memory Survive a Model Upgrade? starts by refusing to treat “memory” as one thing. It splits the system into four roles: the actor that generates experience, the writer that saves it, the reader that later uses it, and the embedder that powers vector search. An upgrade touches one of these, and which one it touches determines what breaks.
The distinction that matters most operationally is reader versus embedder. Swapping the reader while the embedder stays fixed requires no re-indexing, because the vectors only route text to the reader; the reader never inspects them. Swapping the embedder is a different animal. Old and new vectors sit in different geometric spaces even when the dimension count is identical, so a partial migration leaves you with one index containing two incompatible coordinate systems — and no error to tell you.
To measure inheritance rather than survival, the authors hold the conversation history fixed and vary only the component under test, then score the new reader on an inherited store against that same reader’s score on a store it built itself. That ratio is their Retained Performance After Swap (RPAS), reported alongside the raw accuracy gap, and used only when the own-store score clears chance by at least 0.20 — a floor every primary configuration passed, so it filtered nothing. Directions are reported separately, because migrating A→B and B→A can behave differently.
The empirical results then localize the damage. In their single-stage dense RAG setup — event-based chunks, cosine top-k=8, no reranker, no lexical search — search surfaced the necessary evidence only about 60% of the time regardless of which reader was asked, and that miss accounted for 81% of RAG’s pooled accuracy deficit. The reader was rarely the problem: once the correct chunk was handed over, both readers usually used it. On the embedder side, fully re-embedding with the newer model gained 11.90 accuracy points over the old index, while a 50/50 mixed index gained only 4.96 — despite both models emitting 1024-dimensional vectors, so nothing crashed. For repair, keeping the original transcript beat rewriting the compact notes by 8.9 points on average, because a note can’t recreate a fact the writer omitted; but that advantage materialized only where the repair model could finish the job, and one tested repair model hit its output-token limit on every attempt.
Read the numbers for what they establish rather than as constants. The 40% miss rate belongs to that retrieval configuration, the mixed-index penalty to that specific v1.0-to-v1.5 pair, and the whole study to two similarly sized readers on a scripted objective workload whose histories fit both context windows. What generalizes is the diagnostic order: before attributing a post-upgrade regression to the new model, check whether the evidence was retrieved at all, and never mix embedding spaces in one index on the strength of matching dimensions. The raw-history repair path is real but conditional — it depends on policy permitting retention, and it creates privacy, security, retention, and deletion obligations you now own.
Freshness: does a stale note outrank a live tool?
Having memory and benefiting from memory are different measurements, and The Memory Trust Gap builds its benchmark around that gap. Its Benefit suite poses tasks unsolvable without the stored fact, so the no-memory baseline sits at chance and you can only observe over-trust. Its Safety suite is the interesting one: an authoritative tool holds the correct current value in every condition, so the no-memory baseline is high, and net harm becomes measurable — following a stale memory below the accuracy you’d have had with no memory at all. Across 150 Safety scenarios and four memory conditions (no memory, clean, stale, explicit conflict), the paper reports stale-value reliance as a behavior and the paired outcome change against baseline as a separate quantity. Actions are closed-set and scored by exact, regex, or canonical match rather than an LLM judge, with option orders cyclically rotated and averaged to remove position priors.
Why report both? Because reliance can sit near 1.0 while net harm looks small, simply because the baseline was weak. A capable model has more accuracy to lose when it over-trusts. Collapsing the two into one “memory helps” number hides exactly the case you care about.
The mitigation results are where the mental model has to change. At the tested +1-day recency threshold, structurally marking the authoritative item while leaving the stale note in place cut stale reliance sharply for the 4B and 8B models (+.42 and +.33 versus a raw frame) and did essentially nothing for the 0.6B and 1.7B checkpoints (+.06 and +.00). Annotating every item with provenance and timestamp improved the larger checkpoints’ accuracy; the two smallest recovered only under a representation where supersession had already been applied and the stale item removed before inference. A purely verbal “prefer the newest authoritative source” instruction had little effect and in some settings increased reliance.
Several caveats change how far this travels. A control that framed the identical wrong item as a memory, a document, or an earlier message found no consistent memory-specific advantage — a stale document was trusted more at the three smaller scales — so this is a stale-evidence problem, not a memory-label problem. The primary scale series is one model family, with cross-family reproduction only on capable Llama sizes, and the study measures conflict at consumption time rather than across an end-to-end write/update/retrieve loop. Still, the design implication is concrete: if a small model consumes your memory, metadata is not a control. For a pipeline routing retrieval into a sub-2B model, I would resolve supersession in the retrieval layer and drop the superseded item before the prompt is built, because the evidence here shows those checkpoints did not act on freshness cues they could see.
Integrity: can an outsider check the mutation log without trusting it?
The third question is different in kind. MutMem-V2 asks whether someone handed a copy of a persistent-memory system’s mutation evidence can determine that the recorded changes were authorized and complete — without holding producer credentials and without trusting the bundle.
The machinery follows from that constraint. Every object is serialized to deterministic canonical bytes with domain separation and length framing, so any field change alters its commitment. The verifier checks that required records are present exactly once, that results are complete and ordered, and that the records belong to the correct subject. Malformed bundles fail before any signature is checked. The ordered descriptors are committed with a Merkle tree construction, and a terminal event binds the request, authority, root, evidence list, projection, and result count. Authority chains are checked against an externally selected master fingerprint and release identity: a bundle cannot nominate its own trust root. The declared adversary controls transport and may edit copied evidence but cannot break SHA-256 collision resistance or Ed25519 unforgeability.
Given that, the security argument is straightforward. Editing a committed field changes the object commitment and the root; omitting or duplicating a mandatory object fails the membership check; substituting an identity or grant fails signature verification against the external anchor; reordering results or replacing the terminal projection is detectable because ordinals and kind order feed the root.
The non-goals are stated with unusual bluntness, and they matter more than the mechanism for anyone tempted to market this as memory safety. Passing verification establishes tamper evidence under the stated assumptions — not that signed content is true, not availability, not confidentiality, not semantic validation, not detection of every harmful input. A storage administrator can still destroy the evidence. An adversary who replaces all evidence and every independent anchor is outside the threat model. On the empirical side, the current V2 source does not rerun utility, mutation-performance, PoisonedRAG, ablation, or human-agreement experiments; those remain historical V1 results. The independent Node and Python verifier implementations agree, but no outside team has repeated the experiments. The canary detection result covers explicit marker traversal only, and the clean-install qualification covers one macOS installation on Node v26.8.1.
What to take from reading these together
The three papers examine separate properties of memory. Passing one test does not establish that the others will pass. Portability metrics say nothing about byte persistence alone; stale-value reliance alone does not show how much accuracy was lost relative to having correct current information and no memory; cryptographic tamper evidence says nothing about whether the memory is true.
That gives you three separable reviews for an upgrade checklist. When a component changes, identify which component and measure the new reader on an inherited store against its own-store performance, rebuilding indexes rather than blending vector spaces, and test the actual repair model against its real output limits. When conflict handling changes, score stale reliance separately from net harm and pick an intervention matched to the capability of whatever consumes the memory. When the implementation or custody of the store changes, verify canonical, ordered, signed, externally anchored mutation evidence — and keep truth, availability, and confidentiality explicitly outside that claim. A green light on any one of these is not evidence about the other two.