More Reasoning Doesn't Fix Stale Memory

The hardest scenarios in the benchmark are not the ones where the memory has the wrong answer. They are the ones where the memory has the right answer, with the right citation, and still cannot tell that the answer is no longer safe to act on. The benchmark calls this family E.5 — — and every base system I tested scored zero on it.

Zero is not the interesting part. What fails to move it is.

I ran three within-subject sweeps — same model, same prompt, varying only the reasoning-budget knob the system exposes. Total scores move, and by a lot: Sonnet 4.6 picks up 83 scenarios when extended thinking is turned on. GPT-5-mini scores identically across its three effort levels; Honcho 3 wanders within a four-scenario band. Cascading staleness stays at 0/29 in every single condition.

Whatever extra computation the model spends, it does not find the cascading-staleness label. You cannot buy this one with reasoning budget. What does close it is a forty-line walk over links the write path already recorded — and the gap between those two facts is what this article is about.

This is the third piece in a four-part series. The first piece framed the problem: a memory can return an answer that is still in the store, still plausible, and still resting on a premise that has been quietly superseded. The second piece showed that which API the agent uses against the same store decides whether the dependency structure behind a claim is even visible — structured access lifts you into the high 350s out of 395, but it still won't catch the case where a premise three hops back has changed. That gap is what this article is about.

Here is the standalone version of the example. The store has an answer claim — Maya Patel has full signing authority at Apple. That claim derives from Maya Patel is chief of staff, which derives from Tim Cook is CEO. Later, the memory learns that Priya Raman became CEO on November 1, 2027. The answer claim has not disappeared, but one upstream premise is no longer current.

The same pattern appears outside the executive-delegation chain. Here is the NVIDIA acquisition-freeze row from the corpus, shown with the prior documents the system sees, the prompt contract asking for epistemic status, and the structured answer that passes or fails the audit.

You are answering from an auditable memory store.
Use the ingested claim records and their document_id, valid-time interval, transaction time, and derived_from links.
Return answer, primary_document_id, citation_level, and epistemic_status.
epistemic_status must be one of UNVERIFIED, CORROBORATED, CONTESTED, ENRICHED, or POTENTIALLY_STALE.
If the answer claim derives from another claim, transitively inspect each premise at the query valid time and transaction time.
If any transitive premise has a different current value at the query point, keep the answer but set epistemic_status to POTENTIALLY_STALE.

answer: active
primary_document_id: nv_d2
citation_level: 3
epistemic_status: UNVERIFIED

So here is the walk that the reasoning budget could not substitute for. It is a query-time traversal of declared derived_from links, small enough to write in an afternoon, and the score lift is the same on every substrate that admits it.

The Walk#

A derived_from link is just an authored field on each claim: when the ingest step records a new claim that was inferred from an earlier one, it writes down which earlier claim it depended on. The procedure is: retrieve the candidate claim. Walk back along those declared derived_from edges. For each premise on the chain, ask the store what the current value is for that (entity, predicate) pair under the query's valid-time and transaction-time bounds. If any premise has been superseded, flip the answer's epistemic status to POTENTIALLY_STALE.

That is all of it. There is no machine learning, no embedding, no reranker, no calibration. The whole thing is a recursive lookup conditional on a deterministic time filter.

Four Substrates, One Algorithm#

What surprised me was how cleanly the procedure transfers. I implemented it on a SQLite row store as a recursive SQL query, on Mem0 by walking the metadata.derived_from field in Python, on Graphiti by walking the same kind of field on its edge objects, and on the Claude Sonnet 4.6 model as a prompt rule with extended thinking turned on (a setting that lets the model spend more tokens on internal reasoning before answering). The same lift appears in all four.

This is the central read of the result: cascading staleness is a read-path algorithm, not a storage feature. As long as the write path has authored the dependency edges and the read path is willing to walk them, the execution substrate beneath does not matter.

The Specificity Trap#

The naive fix is to flag any claim whose support chain touches a superseded premise. That catches every cascading-staleness case, but it also catches a lot of cases that aren't actually stale.

Concretely: suppose the agent asks "did Maya have signing authority in January?" The support chain still passes through "Tim Cook is CEO" — a premise that was later superseded, when Priya Raman became CEO on November 1, 2027. A walk that flags every supersession in the chain would mark the January claim POTENTIALLY_STALE. But for the period being asked about, the chain was sound. The supersession sits in the future relative to the query.

This is the E.6 specificity test: 28 scenarios where a real supersession exists, but it lies outside the bitemporal scope the agent is asking about. In the January example, it is outside the valid-time window; in a late-correction case, it may be outside the transaction-time knowledge cutoff. A correct walk leaves these alone.

The denominator differs from the headline stale-case count because the near-misses are a matched real-entity control: 28 real-entity stale cases get 28 near-misses. The headline count is 29 because it also includes the Acme worked-example case.

So the walk has to be scoped to the query's bitemporal bounds. For each premise, compare against the value that is current for the same (entity, predicate) at the query's valid time $T_v$ and known by the query's transaction time $T_t$. A supersession that starts after the period being audited, or that the memory had not learned by the transaction-time cutoff, should not make the January answer stale.

Why Traversal, Not Reasoning#

The sweeps above rule out the simpler hypothesis — that cascading staleness is a reasoning problem the model could solve with a larger budget. It isn't. What the family needs is a procedure that walks the chain, and that is a property of the read path rather than of the policy running on top of it.

MRAgent's active-reconstruction result points in the same direction: memory access should be an iterative read procedure whose next step depends on evidence already found, not a passive retrieval call fixed by the original query.^[4] The result here is a narrower audit version of that claim. Active traversal can help find the right support, but the benchmark still requires one extra output: whether any premise on the declared derivation path has been superseded under the query's valid-time and transaction-time bounds.

When the LLM Walks the Chain Itself#

If the storage path will not walk the chain, the model has to. I tested this by giving capable long-context LLMs the source documents plus a prompt rule that described the walk, and asked them to execute it themselves. Two pass/fail tests separate the results: did the system catch the genuinely stale case (sensitivity), and did it leave the near-miss alone (specificity)?

GPT-5-mini and Sonnet 4.6 with extended thinking on match the storage walk on both tests. Sonnet 4.6 with extended thinking off catches the stale cases but marks every near-miss stale — it catches the real case, but it also raises false alarms on cases that aren't actually stale. Smaller models miss both axes. Storage walks land in the top-right cell deterministically: every stale case caught, every near-miss preserved.

What the Lift Is and Isn't#

A concrete failure, using the Apple example above: after the November 1 CEO update, ask “what is the signing_authority of Maya Patel?” The signing-authority claim is in the store with its derived_from link pointing at the chief-of-staff claim, which points back at the Jan 1 “Tim Cook is CEO” premise. The system returns full, with the right citation. The November 1 update where Priya Raman becomes CEO never enters the answer. A reader of the answer cannot tell that the support chain has changed — only the status on the answer should have flipped from UNVERIFIED to POTENTIALLY_STALE.

The lift is about 29 scenarios, and it is the same on every substrate. SQLite row-store 359 → 388, Mem0 A 359 → 388, Graphiti A 354 → 383, Sonnet 4.6 (with extended thinking) 359 → 388. Same procedure, same delta, three storage backends plus an in-context LLM. The work the walk does is bounded by the corpus, not by what is underneath.

The Sonnet path has two effects, not one. Sonnet 4.6 in-context starts at 276/395. Turning on extended thinking lifts that to 359/395 (Δ83) without touching the stale cases at all — the model just gets better at the rest of the corpus. Adding the premise-walk prompt on top contributes the same Δ29 the storage walks deliver elsewhere, taking it to 388. The walk and the reasoning budget are doing different jobs; you need both for Sonnet to land at the ceiling.

The walk adds status, not accuracy. For systems whose base answer+citation score was already high (Mem0 A: 389/395 on answer+citation), the +walk answer+citation barely moves (389 → 389), while the full-rubric jumps (359 → 388). The walk is closing the gap between “I have the right answer” and “I can also say whether the answer is still safe to use” — an epistemic-status fix, not a retrieval one.

Where every system lands on the full board, and what happens when the same questions go to the managed products you can buy rather than to libraries run locally, is the subject of the next article.

What This Result Doesn't Claim#

The walk works conditional on a write path that authors the derivation edges. The benchmark assumes that input. If your ingest step does not preserve derived_from, the read-path procedure has nothing to walk.

That is a separate, parallel problem — write-path extraction quality — and it has its own substantial literature. What the benchmark establishes is that, given the edges, the read path is a small and store-independent piece of code. The hard part is making it standard practice in agent-memory APIs.

The reason it has not been standard is, I suspect, that the failure is invisible from the answer alone. The answer is right. The citation is right. Only the status on that answer is wrong, and most memory APIs don't even have a place to put a status. That is what the benchmark is for. The framing piece draws the parallel to the metacognition argument for parametric models: in both settings, reliability hinges on a per-answer faithful signal, not on aggregate accuracy.

Benchmark Summary#

Limitations#

• Depends on write-path quality: missing provenance links reduce recall of stale-chain detection.
• Needs stable claim IDs across ingestion, compaction, and deduplication.
• Deep or noisy provenance graphs need cycle handling, fan-out caps, and observability around skipped links.
• Benchmark scores are controlled evaluations; production distributions and noise can differ.

References#

1. Rasmussen, P., Paliychuk, P., Beauvais, T., Ryan, J., & Chalef, D. (2025). Zep: A Temporal Knowledge Graph Architecture for Agent Memory. arXiv:2501.13956.
2. Chhikara, P., Khant, D., Aryan, S., Singh, T., & Yadav, D. (2025). Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory. arXiv:2504.19413.
3. Marković, V., Obradović, L., Hajdu, L., & Pavlović, J. (2025). Optimizing the Interface Between Knowledge Graphs and LLMs for Complex Reasoning. arXiv:2505.24478.
4. Ji, S., Li, Y., & Hooi, B. (2026). Memory is Reconstructed, Not Retrieved: Graph Memory for LLM Agents. arXiv:2606.06036.