The Stale Sticky Note

The claim: stale but highly relevant memory is more dangerous than no memory

The sticky-note story has a concrete, testable version: when a memory system only ever “appends” or “last-write-wins,” once a fact reverses (say, a launch date moves from Thursday to next Monday), the old memory is still judged highly relevant to the current question, and gets recalled and trusted first. The result is that the model is more likely to give a wrong answer than if it had no memory at all — because “no memory” at least prompts a follow-up question, while “stale but highly relevant memory” makes the model sound certain.

1. TEPA: append-only and last-write-wins lose to “no memory” when facts reverse

This is not speculation — it is a reproducible experimental result. An August 2026 paper, TEPA (arXiv:2608.07429), in a controlled “hidden-mechanism reversal” experiment, explicitly divides memory state into Hypothesis → Active → Revoked — three lifecycle states. At full reversal, both append-only memory and last-write-wins collapse to a 0.210 success rate — below the 0.309 baseline with no memory at all — while TEPA, which supports revocation, holds at 0.950. The authors call this “memory worse than no memory” effect memory pollution, and reproduce it again in an executable, real file read/write setting.

2. Mem0’s State of AI Agent Memory 2026: staleness remains an open problem

Mem0’s State of AI Agent Memory 2026 lists LoCoMo, LongMemEval, and BEAM as the three main benchmarks currently used to compare memory architectures, and summarizes several open problems that remain unsolved, including memory staleness, cross-session identity and temporal abstraction at scale. It is worth noting: the specific scores quoted here (for example, LoCoMo 92.5, LongMemEval 94.4) are self-reported by Mem0’s own algorithm — a vendor’s self-evaluation. We cite it only to show that “staleness is an industry-recognized open problem,” not to treat those scores as an independent third-party conclusion.

3. ADD-only: not overwriting history, but adding to it

The same Mem0 report notes that a new algorithm shipped in April 2026 introduced “single-pass ADD-only extraction,” which appends agent-generated facts and user-stated facts into memory on equal footing, instead of silently overwriting old records (see github.com/mem0ai/mem0). This step solves the problem of “history quietly getting erased.” But by itself it cannot replace revocation: appending without ever marking anything invalid just leaves the expired note and the newest note on the desk together — you still need a mechanism to tell which one counts now. ADD-only and revoke are complementary, not an either/or.

4. Validity windows: stamping every fact with “valid from — until when”

The Zep / Graphiti paper, Zep: A Temporal Knowledge Graph Architecture for Agent Memory (arXiv:2501.13956), offers a concrete approach: every fact edge in the knowledge graph carries valid_at / invalid_at two timestamp fields. When new evidence contradicts an existing fact, the system sets the old fact’s invalid_at to the moment the new fact takes effect, rather than deleting or overwriting the old record outright — history stays queryable, but retrieval defaults to only the currently valid segment.

5. Provenance: separating “when it was mentioned” from “when it actually happened”

An August 2026 paper, SodaMem (arXiv:2608.08055), goes further and splits time into three axes: mention time, occurrence time and validity, using SUPERSEDES (supersedes), CONTRADICTS (contradicts), UPDATES (updates) — three semantically typed edges linking prior and later facts, instead of simply letting “the new one overwrite the old one.” This is exactly what solves the three questions from the sticky-note story — who said it, which date counts, where it came from — without which neither revocation nor updating makes sense.

6. Separate storage by information type: not all memory should be compressed the same way

An August 2026 paper, LeanMem (arXiv:2608.03463), argues that stable user attributes, events that change over time, and verbatim records that need preserved detail should already use different storage forms: profile, event, and source-grounded record. Compressing the ever-changing “event” and the nearly static “profile” through the same pipeline is one reason memory goes stale so easily and is so hard to verify.

A concrete work scenario

The release was originally planned for “this Thursday,” then changed to “next Monday.”

• The wrong system: uses last-write-wins or plain append. The former makes “this Thursday” vanish without a trace, so if the new record itself is wrong there is no way to trace back; the latter leaves “this Thursday” and “next Monday” both sitting in the retrieval results, and the model may pick the stale one.
• The right system: marks “this Thursday” as revoked (stamping it invalid and recording when it expired), and creates a new active fact for “next Monday,” with a clear source (who said it, in what context, from which record). The old record stays queryable, but retrieval defaults to returning only the one currently active.

This is exactly the same problem that TEPA’s Active / Revoked states and SodaMem’s SUPERSEDES semantics are built to solve — just recast as an example closer to everyday work.

What HaroCue does about it

Based on this public research, HaroCue’s stance on memory going stale is:

• Appear only with evidence; stay quiet otherwise. When a recalled fact does not match the current question, its freshness is in doubt, or the evidence is insufficient, it is better to say nothing than to let stale data pass as a fresh answer.
• MCP results carry freshness labels. When an Agent reads HaroCue’s local facts over MCP, the response carries source and time information, instead of a plain block of text with no indication of when it was generated.
• Local-first memory storage. Raw activity, window titles, and local facts are written to your device only by default; for the full explanation of what stays local and what can leave, see Privacy boundary.

These reflect the product’s existing design direction for local memory and MCP access today, not an unverified marketing promise; for what a specific version actually supports, check the download page against the public release record — we will not fabricate benchmark scores or user testimonials here.