Importance-Based Forgetting

Category: Lifecycle

Problem

Memory stores grow indefinitely. Without a forgetting mechanism, recall becomes noisy — low-value memories (greetings, tangential details, resolved issues) compete with critical knowledge for retrieval slots. You need memories to naturally fade unless they prove valuable.

Architecture

Dakera's memory decay system assigns each memory an importance score that decreases over time according to a configurable strategy. Memories that are recalled (accessed) get their importance reinforced. Memories below a threshold are excluded from recall results.

Decay Strategies

Strategy	Behavior	Best For
Exponential	Rapid early decay, slows over time	General-purpose, mimics Ebbinghaus curve
Linear	Constant rate decrease	Predictable lifecycle, TTL-like behavior
Logarithmic	Fast initial drop, very slow thereafter	Recent context is critical, old memories persist
Step	Drops at fixed intervals	Sprint/cycle-based workflows
Periodic	Cyclical importance (seasonal)	Recurring patterns, seasonal data
Custom	User-defined function	Domain-specific decay curves

Implementation

from dakera import Dakera

client = Dakera(base_url="http://localhost:3300", api_key="dk-...")

# Store memories with varying importance
client.memory.store(
    content="User's API key was rotated successfully",
    namespace="user-ops",
    metadata={"importance": 0.4, "type": "routine-event"}
)

client.memory.store(
    content="User's production database is PostgreSQL 16 on AWS RDS",
    namespace="user-ops",
    metadata={"importance": 0.95, "type": "infrastructure-fact"}
)

client.memory.store(
    content="User said 'good morning' and asked about the weather",
    namespace="user-ops",
    metadata={"importance": 0.1, "type": "small-talk"}
)

# Configure exponential decay
# The key rotation (0.4) will decay below threshold in ~2 weeks
# The infrastructure fact (0.95) will remain for months
# The small talk (0.1) will be excluded within days

# REST API to configure decay:
# curl -X POST http://localhost:3300/v1/decay/config \
#   -H "Authorization: Bearer dk-..." \
#   -H "Content-Type: application/json" \
#   -d '{
#     "namespace": "user-ops",
#     "strategy": "exponential",
#     "params": {
#       "half_life_days": 14,
#       "min_importance": 0.15,
#       "reinforcement_boost": 0.2
#     }
#   }'

# When a memory is recalled, its importance is reinforced
# This prevents frequently-accessed memories from decaying
results = client.memory.recall(
    query="What database does the user run?",
    namespace="user-ops",
    top_k=5
)
# The PostgreSQL fact gets importance reinforced (+0.2 boost)
# It will now take even longer to decay

Checking Decay Stats

# View decay statistics for a namespace
curl -X GET http://localhost:3300/v1/decay/stats?namespace=user-ops \
  -H "Authorization: Bearer dk-..."

# Response:
# {
#   "total_memories": 147,
#   "active_memories": 89,
#   "decayed_memories": 58,
#   "avg_importance": 0.52,
#   "strategy": "exponential",
#   "half_life_days": 14
# }

When to Use This Pattern

Any long-running application where memory accumulates over months/years
Customer support — routine issues fade, critical escalations persist
Personal assistants — small talk fades, core facts remain
Systems with storage constraints that need bounded memory growth

Key Considerations

Set initial importance thoughtfully — it determines how long a memory survives
The reinforcement mechanism means frequently recalled memories resist decay naturally
Decayed memories are excluded from recall but not deleted — they can be recovered if needed
Combine with the summarization pattern: consolidate before decay removes individual memories
Monitor decay stats to tune half_life and min_importance for your workload