hermes - 💡(How to fix) Fix Memory Enhancement via Forgetting Curve Model — Standalone Plugin for Mem0 Users

Problem Statement

Hermes Agent supports Mem0 as a configurable memory provider for cross-session persistence. When deploying Mem0 locally, users encounter a fundamental limitation: Mem0 has no built-in mechanism for memory expiration or decay. Everything added via conclude() stays forever.

Over weeks of operation, this causes:

1. Retrieval noise compounds — top-k search results mix genuinely useful facts (e.g., "user prefers Chinese responses") with stale artifacts (e.g., one-time troubleshooting notes, expired task progress logs, outdated configuration snippets)
2. Context token inflation — obsolete memories consume context window that should be used for relevant facts
3. Contradictions — stale preferences conflict with current ones, confusing the agent

The core issue: there is no distinction between frequently-used memories and rarely-accessed memories. A preference retrieved daily has exactly the same persistence guarantee as a temporary note created once and never referenced again. This is fundamentally different from how human memory works.

Solution: Memory Lifecycle via Forgetting Curve Model

We implemented a memory lifecycle system modeled after the Ebbinghaus forgetting curve, where:

• Frequently accessed memories persist longer (like reinforced neural pathways)
• Unused memories naturally decay (like pruned rarely-used connections)
• New memories get protection time (like working memory consolidation)
• Decay is gradual, not abrupt (unlike hard TTL which kills memories instantly)

Core Formula

weighted_score = min(access_count, 255) * 0.5^(days_since_last_access / 7)

Architecture: Bridge Layer (No Core Mem0 Modification)

Hermes Agent ←→ mem0_lifecycle (bridge) ←→ Mem0 SDK ←→ Qdrant
                            ↓
        Access tracking + decay scoring + automated cleanup

Key implementation details:

1. Transparent access tracking on search: Every search() call increments access_count and updates last_accessed_at timestamp for matched memories in Qdrant's vector payload. Caller sees no API difference — tracking happens automatically at the bridge layer.

2. Exponential decay scoring with defensive programming:

def compute_weighted_score(access_count, last_accessed_iso):
    # Timezone-aware datetime handling
    # Parse failures default to score=0.0 (expired) — prevents immortal zombie memories
    # Access count capped at 255 — prevents unbounded integer growth
    ...

3. Dual-layer cleanup: Cleanup properly deletes from both Qdrant vector index AND Mem0 metadata layer to prevent orphaned entries. Supports --dry-run mode for preview.

4. Idempotent automation via systemd ExecStartPre: Cleanup runs before the gateway service starts, with a daily guard (/tmp/.mem0_cleanup_date) to prevent redundant runs within the same day. No cron needed.

Comparison with Alternatives

Published as Standalone Plugin

Per maintainer guidance (see closed PR #35870), this was published as a standalone pip-installable plugin rather than added to plugins/memory/:

Repo: https://github.com/HH1162/mem0-lifecycle

pip install git+https://github.com/HH1162/mem0-lifecycle.git

Usage Example

from mem0_lifecycle import Mem0LifecycleServer

# Initialize with your Mem0 config
server = Mem0LifecycleServer(config={...})

# Search automatically tracks access frequency
results = server.search("query text", user_id="hermes-user")

# Cleanup stale memories
server.cleanup(dry_run=False)

CLI Interface

# Search (auto-tracks access frequency)
mem0-server search "query text" hermes-user 5 true

# View statistics
mem0-server stats hermes-user

# Find least-used memories  
mem0-server least_used hermes-user 10

# Cleanup stale memories
mem0-server cleanup --dry-run hermes-user   # Preview
mem0-server cleanup hermes-user             # Execute

Automation via systemd

Create a drop-in config at $SYSTEMD_USER_DIR/your-gateway.service.d/mem0-cleanup.conf:

[Service]
ExecStartPre=/path/to/mem0-daily-cleanup.sh
TimeoutStartSec=300

Production Results

Deployed under Hermes Agent with local Mem0 v2.0.4 + Qdrant + bge-large-zh-v1.5 embedding:

• Active memories stabilized at ~20 entries (down from 30+ before implementing cleanup)
• Zero false deletions across multiple cleanup cycles
• Zero manual intervention required — system fully self-manages
• Single-access memory auto-cleaned after ~33 days of inactivity
• Max-count memory (255) auto-cleaned after ~86 days of inactivity
• Retrieval quality improved measurably — fewer stale entries appear in top-k results

What This Is Not

This is NOT asking for changes to Hermes core code. It's announcing a community-built plugin for users who want automatic memory lifecycle management with their local Mem0 deployment. The plugin implements the same MemoryProvider pattern and can be adopted independently.

Upstream Reference

This addresses the feature gap discussed in mem0ai/mem0#5330, where we proposed native support for memory lifetime management in Mem0's SDK. Until upstream implements this natively, this plugin serves as a complete reference implementation for anyone running a local Mem0 deployment facing the same accumulation problem.