# How Does AI Memory Decay Work? > AI memory decay reduces the retrieval priority of stored facts over time using a half-life formula — so recent, frequently-recalled memories outrank old, unused ones without manual deletion, keeping the agent's working memory relevant as the world changes. - **Category**: Theory - **Read time**: 6 min read - **Date**: July 2, 2026 - **Author**: Feather DB (Engineering) - **URL**: https://getfeather.store/theory/how-ai-memory-decay-works --- AI memory decay is a scoring mechanism that reduces the retrieval priority of stored memories over time, based on how recently they were accessed and how frequently they have been recalled. It operates like a half-life formula: a memory never recalled drops toward zero retrieval weight over its half-life period, while a memory recalled frequently resists decay and stays accessible. The goal is to make the agent's working memory reflect what's been recently relevant — not what was stored months ago and has never been useful. ## Why memory decay is necessary Without decay, a memory system accumulates indefinitely. A fact stored 18 months ago competes equally for retrieval with a fact stored yesterday, as long as their cosine similarity to the query is similar. This creates three problems: **Stale information surfaces.** A user preference that changed six months ago still retrieves if it's semantically similar to the query. The agent acts on outdated information without knowing it's outdated. **Working set grows unbounded.** With no decay, memory size grows without limit. Search quality degrades as the index fills with low-signal, irrelevant facts that compete with high-signal current ones. **Manual curation becomes a bottleneck.** Without automatic decay, the system requires explicit deletion rules — TTLs per memory type, manual review cycles, hard-coded expiration dates. At scale, this is operationally unsustainable. Memory decay solves all three: recent facts naturally outcompete old ones, the working set self-manages, and the system requires no manual curation rules. ## The decay formula Feather DB implements decay using an exponential half-life model with recall stickiness: ``` stickiness = 1 + log(1 + recall_count) effective_age = age_in_days / stickiness recency = 0.5 ^ (effective_age / half_life_days) final_score = ((1 - time_weight) × cosine_similarity + time_weight × recency) × importance ``` Breaking this down: **stickiness** is a multiplier on effective age based on how many times the memory has been recalled. A memory recalled 0 times has stickiness of 1.0 (no effect). A memory recalled 10 times has stickiness of ~3.4. A memory recalled 100 times has stickiness of ~5.6. The log scaling prevents unbounded stickiness growth. **effective_age** divides the raw age in days by stickiness. A 30-day-old memory recalled 10 times has an effective age of only 30 / 3.4 = 8.8 days — it behaves as if it's 8.8 days old, not 30. **recency** is the standard exponential decay function: 0.5 raised to the power of (effective_age / half_life). At effective_age = half_life_days, recency = 0.5. At 2× half_life, recency = 0.25. This is the same functional form as radioactive decay. **final_score** blends semantic similarity (cosine distance) with recency, scaled by importance. The time_weight parameter controls how much recency influences the final rank. At time_weight=0.3, the score is 70% semantic similarity and 30% recency × importance. At time_weight=0.7, recency dominates. ## Configuring decay for different use cases Use casehalf_life (days)time_weightBehavior Real-time ad creative70.5Last week's performance dominates; old campaigns fade fast Customer support agent300.3Last month relevant; older history still surfaces but deprioritized Research agent900.2Long memory window; recency lightly weighted Core brand guidelinesAnyAnyimportance=1.0 keeps at full score regardless of decay The key insight: `half_life` and `time_weight` are set at query time, not at ingest time. The same database can be queried with different decay parameters for different use cases. An agent that needs fast-decay context for real-time decisions can query with half_life=7; the same data can be queried with half_life=90 for historical analysis. ## Recall stickiness: the feedback loop Decay without stickiness would make recently-added memories permanently disadvantaged — a core brand guideline added six months ago would decay toward zero regardless of how useful it's been. Stickiness is the correction: every time a memory is retrieved, its recall_count increments, reducing its effective aging rate. This creates a virtuous feedback loop: memories that are useful get recalled, which makes them more resistant to decay, which keeps them accessible for future retrieval. Memories that are useless never get recalled, which means they age at full speed and eventually fall below the retrieval threshold. The system self-curates. The working set that emerges reflects the memories that have been operationally useful in the agent's actual interactions — not the memories that are semantically similar to something, but the memories that have been consistently relevant. ## What happens when a memory fully decays When a memory's effective score falls below the retrieval threshold, it stops appearing in search results. It is not deleted from the database — it remains in storage and can be recalled explicitly by ID, or can be re-surfaced if its recency score recovers (which doesn't happen in practice without a recall signal, since the score is monotonically decreasing for unretrieved memories). This is a deliberate design choice. Decay is a retrieval filter, not a deletion mechanism. A compliance requirement may mandate keeping all memories; decay ensures they don't pollute retrieval quality while still being auditable in storage. ## Memory decay vs explicit TTL The alternative to decay is explicit TTL (time-to-live): set a fixed expiration time at ingest and delete the memory when the TTL expires. This is simple to implement but rigid in practice — the right TTL for any given memory is unknown at ingest time, and important memories can expire while unimportant ones with longer TTLs remain. Decay is adaptive. The effective TTL for each memory is determined by its usage pattern. A heavily-used memory effectively has an infinite TTL; a never-used memory expires at a rate determined by the configured half-life. This matches the intuition of how useful information should behave — it stays accessible as long as it's being used. ## FAQ ### What is memory decay in AI systems? Memory decay is a scoring mechanism that reduces the retrieval priority of stored facts over time. Unused memories gradually stop surfacing in retrieval results without being explicitly deleted. This keeps the agent's working memory focused on recent, relevant information. ### Does Feather DB delete memories that have decayed? No. Decayed memories remain in storage and can be accessed by ID. Decay only affects retrieval scoring — a decayed memory's score falls below the return threshold, but the data is preserved. This supports audit requirements while keeping retrieval quality high. ### How does recall stickiness interact with decay? Stickiness is a multiplier on effective age: a memory recalled 10 times has an effective age of only 29% of its real age. This means frequently-recalled memories resist decay automatically — the system prioritizes what has been operationally useful without requiring manual importance updates. ### What half-life should I use for agent memory? 30 days is a reasonable default for general-purpose agent memory. Use shorter (7 days) for fast-moving contexts like ad creative performance. Use longer (60–90 days) for slower-moving contexts like research agents or user preference tracking where preferences change gradually. ### Can I prevent specific memories from decaying? Yes. Set `importance=1.0` for core facts that should never decay. In the scoring formula, importance scales the final score — a memory with importance=1.0 and high recall count will maintain a competitive final score even as its raw recency decreases. Brand guidelines, core user profiles, and critical system facts should all be stored at maximum importance. --- *This is the machine-readable mirror of the theory post at [getfeather.store/theory/how-ai-memory-decay-works](https://getfeather.store/theory/how-ai-memory-decay-works). For the full Feather DB documentation, see [getfeather.store/llms-full.txt](https://getfeather.store/llms-full.txt).*