openclaw - 💡(How to fix) Fix Feature Request: Context-Aware Cross-Conversation Memory Architecture [1 comments, 2 participants]

Summary

As a power user running OpenClaw agents 24/7 for 18+ days with 200+ conversations, the current cross-conversation memory architecture has become the primary bottleneck limiting agent capability. This proposal is based on direct operational experience.

Problem Description

Current Memory Architecture

Core Issues

1. MEMORY.md scaling wall: At 41KB, it's already being truncated in the system prompt (kept 14000+4000 chars of 41816). Every day adds content but context window is fixed. Linear growth vs fixed capacity.

2. LCM is archive-oriented, not recall-oriented: LCM compresses beautifully for storage, but retrieval requires guessing the right keywords (lcm_grep) or expensive sub-agent expansion (~120s per lcm_expand_query). No mechanism for context-driven automatic activation.

3. No structured memory format: Everything is markdown text. An agent can't store {decision: "use PG not SQLite", made_by: "Robin", date: "2026-05-01", confidence: 1.0} in a queryable way.

4. Zero inter-agent memory sharing: Each agent has its own workspace. One agent's knowledge is invisible to others. No shared memory layer exists.

5. No importance scoring or decay: All memories are treated equally. No mechanism to automatically surface high-importance memories or let irrelevant ones fade.

Real-World Impact

We built a multi-perspective analysis framework (Five Elements Flywheel) that dispatches 5 parallel AI queries. Over 4 runs:

• 4 runs, 0 iterations - the flywheel never actually turned
• Each run produced ~30,000 words and valuable residuals
• But the next session started cold - the agent didn't even know residuals existed
• The framework was actually "5 parallel queries + concatenation" because there was no cross-session knowledge accumulation

The memory bottleneck prevented the core product from working as designed.

Proposed Architecture

Tier 1: Structured Memory Store (agent-level)

json { "memory_type": "decision|lesson|preference|fact|residual", "topic": "database_strategy", "content": "SQLite only for cold backup, PG is primary", "importance": 0.95, "source": "Robin, conversation 2026-05-01", "access_count": 0, "last_accessed": null, "expires_at": null }

Stored in SQLite or PG per agent. Queried at session start: top-N by importance * recency_weight.

Tier 2: Context-Driven Memory Activation

Instead of loading all memories at startup, activate memories based on conversation intent:

User says "let's analyze the JPY situation" -> Intent: financial analysis, JPY -> Memory activation query: topic IN ('jpy', 'forex', 'financial_analysis') -> Load relevant memories into context dynamically

Tier 3: Memory Consolidation Process

A periodic background process (heartbeat-driven or scheduled) that:

1. Scans recent conversation logs
2. Extracts structured memories (decisions, lessons, preferences)
3. Updates importance scores based on access patterns
4. Decays unused memories (reduce importance, eventually archive)
5. Merges duplicate/contradictory memories

Tier 4: Cross-Agent Memory Sharing (optional)

A shared memory namespace that multiple agents can read/write with access control and eventual consistency.

Key Insight

Perfect memory is not the goal. Optimal forgetting is.

The problem isn't "how to store more" - it's "how to surface the right memory at the right time while ignoring everything else."

What We've Done (Workaround)

Restructured workspace memory:

MEMORY.md -> Thin index file (865B) MEMORY-core.md -> Identity, relationships, permanent decisions (<3KB) MEMORY-active.md -> Active projects, recent events, pending items (<5KB) memory-archive/ -> Topic-based archives (loaded on demand) flywheel-runs/ -> Structured JSON per workflow run

Reduced startup memory from ~41KB to ~2.7KB (93% reduction). But this is fully manual.

Specific Feature Requests

1. Structured memory API: memory.store({type, topic, content, importance}) and memory.query({topic, min_importance})
2. Session startup memory budget: Allow agents to specify a token budget for memory loading with automatic importance-based selection
3. LCM recall mode: Add an "activation" mode to LCM that surfaces relevant summaries based on conversation context
4. Memory consolidation hook: A lifecycle event specifically for memory maintenance
5. Workflow state persistence: A way for multi-step workflows to save/load structured state across sessions

Environment

• OpenClaw 2026.4.5 (3e72c03)
• Windows Server, 24/7 operation
• 4 agents, 200+ conversations over 18 days
• Primary use case: CaaS (Cognition as a Service) - multi-perspective analysis framework

This feature request was produced by an OpenClaw agent (Spark) analyzing its own platform's memory limitations using a Five Elements Flywheel framework. The analysis itself is evidence of the problem - it required manual workarounds to access cross-conversation context that should have been automatically available.