openclaw - 💡(How to fix) Fix [Feature]: Memory importance scoring + time decay for long-term memory [1 participants]

Summary

Add importance scoring (1-10) at memory write time and Weibull time-decay so that old/trivial memories fade while important ones persist, improving retrieval quality for long-running assistants.

Problem to solve

All memory entries have equal weight regardless of age or content significance. A note about "weather was nice today" has the same retrieval priority as "user accepted a $500K contract."

After months of use, memory becomes cluttered with low-value entries that dilute search quality. This affects both QMD and builtin backends neither has a mechanism to:

1. Score initial importance when a memory is created
2. Decay importance over time (old entries never lose relevance)
3. Boost on access (frequently recalled memories should stay relevant longer)

For QMD L0/L1/L2 injection, this is especially impactful the limited token budget gets spent on stale trivia instead of high-value facts.

Proposed solution

A three-part importance system:

Part 1: Initial scoring at write time When a memory entry is created, score importance 1-10 using the model (nano tier is sufficient):

• 1-3: trivial (small talk, weather)
• 4-6: useful context (preferences, general facts)
• 7-8: important (decisions, milestones, project info)
• 9-10: critical (contracts, security, life events)

Part 2: Time decay (Weibull distribution) Periodic recalculation:

import math

def decay_importance(original, days_since_update, days_since_access):
    half_life = 14  # configurable
    decay = math.exp(-0.693 * (days_since_update / half_life) ** 1.5)
    access_boost = 1.0 if days_since_access < 3 else 0.8 if days_since_access < 7 else 0.5
    return max(1, round(original * decay * access_boost))

Weibull (shape=1.5) drops fast in the first week, then plateaus - matching how human memory works.

Part 3: Importance-weighted retrieval Search results ranked by similarity * importance instead of similarity alone.

Alternatives considered

1. Manual pinning only (pinned: true/false) - too coarse, binary instead of continuous. User must manually manage pins. Importance scoring is the continuous extension of pinning.

2. Recency-only sorting - penalizes old-but-important facts ("user's birthday", "API key location"). Importance scoring preserves high-value memories regardless of age.

3. LLM-based filtering at retrieval time - adds latency to every search query. Scoring at write time is O(1) per entry, filtering at read time is O(n).

Impact

Affected: All users with long-running assistants (months of accumulated memory) Severity: Medium - search quality degrades gradually over time Frequency: Always - every memory recall searches unweighted entries Consequence: Irrelevant results returned instead of important ones; wasted token budget on stale context injection

Evidence/examples

I've implemented this as an external overlay (PostgreSQL + hourly APScheduler cron) in my OpenClaw deployment with 3 Telegram agents. Results after 2 weeks:

• "Meeting with investor tomorrow at 15:00" -> importance 7 (LLM scored correctly)
• "test message" in group chat -> importance 2 (trivial, scored low)
• "Budget approved for Q2" -> importance 7
• After 14 days without access, importance 7 -> 4 (natural decay)
• After being recalled, importance boosts back (access_boost)

The pinned field already exists in memory entries - this is a natural extension from binary to continuous importance.

Additional information

• Backward-compatible: entries without importance default to 5 (current implicit behavior)
• QMD reranking layer could incorporate importance as an additional signal alongside BM25/vector scores
• The Weibull half_life (default 14 days) should be configurable per-deployment
• Happy to contribute a PR if there's interest in this direction