{"slug": "usage-reinforced-decay-engine-outperforms-recency-windows-for-ai-memory", "title": "Usage-Reinforced Decay Engine Outperforms Recency Windows for AI Memory", "summary": "A new memory engine for AI agents using the Ebbinghaus forgetting curve achieved a 100% Foundational Recall Rate across 150-turn sessions while a recency-window baseline scored 0%, developer E.P. Alexander reported on July 24, 2026. The deterministic, dependency-free system scores retention based on recall frequency and evicts items when the score drops below 0.20, but its advantage vanishes when facts are never recalled. The complete code is available on GitHub.", "body_md": "**July 24, 2026**, (Inside AI) — A new memory engine for AI agents uses the 140-year-old Ebbinghaus forgetting curve to keep foundational facts alive across hundreds of turns, outperforming standard recency-window pruning in long-running sessions. The system, built by developer E.P. Alexander, is fully deterministic and requires no external dependencies, yet it exposes a hard limit where its advantage vanishes entirely.\n\nMost production AI agents evict old context with a sliding window: if an item hasn't been touched in N turns, it's deleted. This treats a critical instruction from turn 1 identically to a debug log from turn 40. Alexander's engine scores retention based on recall frequency, where each use reinforces an item's stability and pushes its eviction horizon out non-linearly. In tests across 50 seeded sessions, the engine maintained a **100% Foundational Recall Rate** while the recency-only baseline scored **0%**.\n\nThe core math comes from Hermann Ebbinghaus's 1885 experiments on human memory, which showed that retention drops sharply at first but flattens with review. Alexander is not the first to apply this to AI agents—projects like [YourMemory](https://github.com/sachitrafa/YourMemory) and Stanford's Generative Agents have used similar concepts—but this implementation is stripped to a minimal, verifiable core. \"I just wanted to see if I could build the absolute smallest, fully deterministic version of this myself with zero dependencies, run it against the basic sliding window most systems actually use, and find the exact point where it breaks,\" Alexander writes.\n\nThe engine uses two classes with identical interfaces, differing only in eviction logic. Retention is scored as **R = e^(-d/s)**, where **d** is turns since last recall and **s** is stability. Each recall updates stability via **s_new = s_old * (1 + 0.5 * log(1 + r))**, with **r** being the recall count. An item is evicted when its score drops below **0.20**. The baseline simply checks if **d > window_size**.\n\nAlexander tested the system on 150-turn sessions with three foundational facts and three noise items per turn. Both engines pruned about **90%** of noise, but the decay engine kept all foundational facts while the baseline lost them all. The result held across noise levels from **3** to **60** items per turn and across **15** threshold-window combinations. Even a window size of **50**—triple the default—couldn't recover the baseline's performance.\n\nHowever, the advantage disappears when a fact is never recalled. In a failure-case test, both engines scored **0%**. \"The mechanism does not rescue facts that nobody ever uses again,\" Alexander notes. \"It specifically, and only, rewards the facts that actually get reused.\"\n\nTwo bugs nearly invalidated the benchmarks. First, a default stability of **2.0** caused items to decay past the threshold before their first scheduled recall; raising it to **8.0** gave a 13-turn grace period. Second, uniform-random recall scheduling made success structurally impossible because recalls almost always arrived after both engines' grace periods expired. Alexander fixed this by using spaced-repetition intervals with jitter, modeled on how facts are actually used in real sessions.\n\nThe engine is not a silver bullet. It treats all items as equal token weight, requires explicit recall triggers, and uses defaults tuned for a specific session shape—early establishment, a quiet middle, and late resurfacing. It also doesn't resolve conflicting memories. \"A recency window is not a bad idea implemented poorly,\" Alexander concludes. \"It is a simple, cheap policy designed to answer exactly one question: when was this last touched? That works perfectly for sessions where importance and recency happen to align. It quietly breaks the moment they do not.\"\n\nThe complete code is available on [GitHub](https://github.com/Emmimal/memory-decay-engine/), and the underlying research on spaced repetition is detailed in a [2006 meta-analysis by Cepeda et al.](https://doi.org/10.1037/0033-2909.132.3.354)", "url": "https://wpnews.pro/news/usage-reinforced-decay-engine-outperforms-recency-windows-for-ai-memory", "canonical_source": "https://insideai.news/news/agentic-ai/usage-reinforced-decay-engine-outperforms-recency-windows-for-ai-memory/5246/", "published_at": "2026-07-24 13:24:21+00:00", "updated_at": "2026-07-24 13:40:23.642553+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-agents", "ai-research", "ai-tools"], "entities": ["E.P. Alexander", "Hermann Ebbinghaus", "YourMemory", "Stanford", "GitHub"], "alternates": {"html": "https://wpnews.pro/news/usage-reinforced-decay-engine-outperforms-recency-windows-for-ai-memory", "markdown": "https://wpnews.pro/news/usage-reinforced-decay-engine-outperforms-recency-windows-for-ai-memory.md", "text": "https://wpnews.pro/news/usage-reinforced-decay-engine-outperforms-recency-windows-for-ai-memory.txt", "jsonld": "https://wpnews.pro/news/usage-reinforced-decay-engine-outperforms-recency-windows-for-ai-memory.jsonld"}}