Skip to content

[Phase 4] Implement Memory Eviction Strategy for COLD Tier #67

@frankbria

Description

@frankbria

Summary

Design and implement explicit eviction policies for the tiered memory system to prevent COLD tier bloat and ensure long-term system health during multi-day autonomous sessions.

Background: State of the Art

From Philipp Schmid's "Memory in Agents":

"Memory Bloat: An agent that remembers everything eventually remembers nothing useful. Storing every detail leads to 'bloat' making it more expensive to search, and harder to navigate."

"Need to Forget: The value of information decays. Acting on outdated preferences or facts becomes unreliable. Designing eviction strategies to discard noise without accidentally deleting crucial, long-term context is difficult."

The challenge: delayed feedback loops. Bad eviction decisions only surface later, making iteration difficult.

Key insight: Memory systems need explicit "forgetting" mechanisms, not just retention policies.

Current State in CodeFRAME

The HOT/WARM/COLD tiered system implies decay (items demote over time), but several questions remain:

  1. COLD tier growth: What happens to items that reach COLD and stay there?
  2. Eviction triggers: Is there a max size? Time-based expiry? Relevance threshold?
  3. Protected items: Are some contexts "pinned" and never evicted?
  4. Cross-session accumulation: Over 8+ hour sessions or multiple days, how large does the context store grow?

Without explicit eviction, COLD tier becomes a write-only log that degrades retrieval performance and increases storage costs.

Investigation Tasks

  1. Measure current growth patterns

    • Instrument context store size over a multi-task session
    • Track items entering COLD tier vs. ever being retrieved again
    • Identify "dead" context (written but never read)
  2. Define eviction policy categories

    • Time-based: Items older than X hours without access
    • Access-based: Items with access count below threshold
    • Relevance-based: Items with importance score below threshold
    • Size-based: Evict oldest/lowest-scored when tier exceeds limit
  3. Implement eviction strategies

    • LRU (Least Recently Used) for each tier
    • Importance-weighted eviction (low score + old = evict first)
    • "Summarize before eviction" - compress episodic memory into semantic facts
  4. Design protection mechanisms

    • Pin critical context (project architecture, key decisions)
    • Require explicit "forget" vs. automatic eviction for sensitive items
    • Eviction audit log for debugging
  5. Handle the feedback loop problem

    • Log eviction decisions for later analysis
    • Build "eviction regret" metric: was evicted content later re-requested?
    • Tune policies based on regret rate

Success Criteria

  • Documented current context growth rates over extended sessions
  • Implemented configurable eviction policy (time/access/relevance/size)
  • COLD tier maintains bounded size under continuous operation
  • Eviction audit log for debugging and tuning
  • Measured "eviction regret" rate < 5%

Design Considerations

Summarize before eviction: Instead of deleting episodic memory ("on task 47, agent tried X and it failed"), summarize into semantic memory ("approach X doesn't work for this codebase") before eviction. This preserves learning while reducing storage.

Session boundaries: Consider more aggressive eviction at session end, but preserve cross-session learning.

References

  • Memory in Agents - Philipp Schmid
  • Elasticsearch hot/warm/cold/frozen tiers as precedent for data lifecycle
  • Redis eviction policies (LRU, LFU, TTL) as implementation patterns

Metadata

Metadata

Assignees

No one assigned

    Labels

    P3-post-betaLow priority - can wait until after beta (v2.0)architectureSystem architecture and design patternscontext-engineeringContext window management and optimizationenhancementNew feature or requestpriority:high

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions