Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Proposal] Built-in Adaptive Memory: hierarchical memory management as a core feature [2 pull requests, 4 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#59095•Fetched 2026-04-08 02:28:43
View on GitHub
Comments
4
Participants
2
Timeline
15
Reactions
0
Author
yozuyozu
Participants
Yhyb24PYhyb24Pyozuyozu
Timeline (top)
commented ×4cross-referenced ×3mentioned ×3subscribed ×3

Memory management is currently left to users via AGENTS.md instructions or third-party skills, but it's fundamental enough to warrant first-class support in OpenClaw. This proposal describes a battle-tested three-layer memory architecture that has been running in production for 2+ months.

Root Cause

Memory management is currently left to users via AGENTS.md instructions or third-party skills, but it's fundamental enough to warrant first-class support in OpenClaw. This proposal describes a battle-tested three-layer memory architecture that has been running in production for 2+ months.

PR fix notes

PR #60403: Add session-persistence skill SKILL.md

Description (problem / solution / changelog)

Add session-persistence skill documentation

Summary

  • Adds SKILL.md for the session-persistence skill under skills/session-persistence/
  • Documents architecture, core scripts, checkpoint format, performance metrics, and troubleshooting
  • Developed with OpenClaw + GLM-5.1 assistance, tested in production for 2+ months

Change Type

  • Docs
  • Feature

Related

Changed files

  • skills/session-persistence/SKILL.md (added, +245/-0)
  • skills/session-persistence/references/checkpoint-manager.md (added, +63/-0)
  • skills/session-persistence/references/jsonl-recovery.md (added, +59/-0)
  • skills/session-persistence/references/knowledge-sync.md (added, +59/-0)
  • skills/session-persistence/references/state-schema.md (added, +77/-0)
  • skills/session-persistence/references/workspace-watchdog.md (added, +81/-0)
  • skills/session-persistence/scripts/checkpoint_manager.py (added, +176/-0)
  • skills/session-persistence/scripts/jsonl_recovery.py (added, +204/-0)
  • skills/session-persistence/scripts/knowledge_sync.py (added, +194/-0)
  • skills/session-persistence/scripts/workspace_watchdog.py (added, +142/-0)

PR #60586: feat(skills): add adaptive-memory — hierarchical memory management with production notes

Description (problem / solution / changelog)

Summary

Adds adaptive-memory as a built-in skill — a three-layer hierarchical memory system for AI agents that survives context compaction and session restarts.

Relates to #59095 and complements @Yhyb24P's session-persistence approach (see my comment for a detailed comparison).

What's Included

Memory Architecture

memory/
├── YYYY-MM-DD.md          # Layer 1: Daily notes (raw, append-only)
├── active_context.md       # Layer 2: Working memory (current tasks, blockers)
├── channel_context/        # Per-channel conversation summaries
│   └── {channel-name}.md
└── pending_tasks.json      # Structured task tracker

MEMORY.md                   # Layer 3: Long-term memory (curated, distilled)

Key Features

  • Three-layer memory — daily notes → active context → long-term memory
  • Channel context — per-channel summaries for multi-channel setups (Slack, Discord, etc.)
  • Task tracker — pending_tasks.json catches promises that would be lost after compaction
  • Four-phase distillation — Orient → Gather → Consolidate → Prune, triggered weekly or by staleness (48h+ AND 3+ unprocessed notes)
  • Init script — scripts/init_memory.sh bootstraps the directory structure
  • Session start routine — defined load order for context recovery
  • Security rules — never store credentials in memory files, reference paths only

Production Experience (2+ months)

This has been running daily with 30+ cron jobs, 5 Slack channels, and daily compactions:

  • active_context.md eliminates ~90% of post-compaction confusion
  • Channel context files are essential at 3+ channels
  • pending_tasks.json prevents forgotten promises
  • Distillation staleness trigger adapts to workload naturally

Complementary to session-persistence (#59095)

This skill and @Yhyb24P's checkpoint approach solve overlapping but distinct problems:

  • This skill adds: channel context, structured task tracking, four-phase distillation
  • session-persistence adds: dual-gate triggers, circuit breaker, xxhash watchdog

A merged core design could combine both — this skill's multi-channel and task layers on top of session-persistence's checkpoint machinery.

Files

  • skills/adaptive-memory/SKILL.md — full documentation with examples
  • skills/adaptive-memory/scripts/init_memory.sh — workspace initialization script

Changed files

  • skills/adaptive-memory/SKILL.md (added, +324/-0)
  • skills/adaptive-memory/scripts/channel_context.py (added, +238/-0)
  • skills/adaptive-memory/scripts/distill.py (added, +269/-0)
  • skills/adaptive-memory/scripts/init_memory.sh (added, +110/-0)
  • skills/adaptive-memory/scripts/memory_lint.py (added, +285/-0)
  • skills/adaptive-memory/scripts/pending_tasks.py (added, +241/-0)

Code Example

memory/
├── YYYY-MM-DD.md          # Daily notes (raw, append-only)
├── active_context.md       # Working memory (current tasks, blockers)
├── channel_context/        # Per-channel summaries (multi-channel setups)
│   └── {channel-name}.md
└── pending_tasks.json      # Structured task tracker

MEMORY.md                   # Long-term memory (curated, distilled)
RAW_BUFFERClick to expand / collapse

Summary

Memory management is currently left to users via AGENTS.md instructions or third-party skills, but it's fundamental enough to warrant first-class support in OpenClaw. This proposal describes a battle-tested three-layer memory architecture that has been running in production for 2+ months.

Problem

Every OpenClaw user eventually hits the same wall:

  • Context compaction wipes conversation history mid-session
  • Decisions and lessons learned are forgotten between sessions
  • Active tasks fall through the cracks after compaction or restart
  • Users end up reinventing memory systems in AGENTS.md (see the proliferation of memory skills on ClawHub)

Related: #9142, #50096

Proposed Architecture

Three memory layers, managed automatically by OpenClaw:

memory/
├── YYYY-MM-DD.md          # Daily notes (raw, append-only)
├── active_context.md       # Working memory (current tasks, blockers)
├── channel_context/        # Per-channel summaries (multi-channel setups)
│   └── {channel-name}.md
└── pending_tasks.json      # Structured task tracker

MEMORY.md                   # Long-term memory (curated, distilled)

Layer 1: Daily Notes

Raw log of decisions, discoveries, errors, and context. One file per day, append-only. Cheap to write, easy to search.

Layer 2: Active Context

Working memory — what's in progress, what's blocked, what just completed. The fastest way to resume after compaction or session restart. Should be readable from any channel/session.

Layer 3: Long-Term Memory (MEMORY.md)

Curated knowledge distilled from daily notes. Organized by topic, not date. Periodically consolidated via a four-phase distillation cycle (Orient → Gather → Consolidate → Prune).

Session Start Behavior

On session start, OpenClaw would automatically load:

  1. memory/active_context.md
  2. Today's + yesterday's daily notes
  3. MEMORY.md (configurable: main session only, or always)
  4. Channel context if applicable

Distillation Cycle

Periodic consolidation (weekly or when 3+ unprocessed daily notes accumulate):

  1. Orient: Read MEMORY.md to understand current state
  2. Gather: Read unconsolidated daily notes
  3. Consolidate: Extract lasting knowledge into MEMORY.md
  4. Prune: Remove outdated/superseded entries

This could run as a built-in heartbeat task or scheduled maintenance.

Production Experience

This architecture has been running for 2+ months in a daily-driver OpenClaw setup with:

  • 30+ cron jobs across financial tracking, monitoring, and automation
  • Multi-channel integration (5+ channels)
  • Daily context compactions survived without losing critical context
  • Weekly automated distillation via heartbeat

Key findings:

  • active_context.md is the single most valuable file — it eliminates 90% of "what was I doing?" moments after compaction
  • Channel context files prevent cross-channel confusion in multi-channel setups
  • The distillation cycle keeps MEMORY.md from growing unbounded while retaining important lessons
  • pending_tasks.json catches promises that would otherwise be forgotten

What "Built-in" Would Look Like

  1. openclaw init creates the memory/ structure automatically
  2. Session start loads memory files before the first user message (configurable depth)
  3. Heartbeat integration triggers distillation when conditions are met
  4. Compaction awareness flushes active context before compaction to preserve state
  5. Config options: which layers to use, MEMORY.md visibility scope, distillation frequency

Reference Implementation

A skill implementing this pattern is available on ClawHub: adaptive-memory. It includes setup scripts and a detailed distillation guide. This could serve as the starting point for a core implementation.

Security Considerations

  • Memory files must never contain secrets/credentials (enforced by convention + optional lint)
  • MEMORY.md visibility should be configurable (e.g., main session only vs. all sessions)
  • Memory files may be version-controlled — treat as semi-public by default

extent analysis

TL;DR

Implementing a three-layer memory architecture with automatic management by OpenClaw can resolve memory management issues.

Guidance

  • Integrate the proposed three-layer memory architecture into OpenClaw to provide first-class support for memory management.
  • Utilize the adaptive-memory skill on ClawHub as a reference implementation for the core implementation.
  • Configure OpenClaw to automatically load memory files on session start, including active_context.md, daily notes, and MEMORY.md.
  • Implement a distillation cycle to periodically consolidate knowledge from daily notes into MEMORY.md.

Example

No specific code snippet is provided, but the adaptive-memory skill on ClawHub can serve as a starting point for implementation.

Notes

The proposed architecture has been battle-tested in a production environment for 2+ months, demonstrating its effectiveness in managing memory and preventing context loss.

Recommendation

Apply the proposed three-layer memory architecture to provide a robust and automatic memory management system, using the adaptive-memory skill as a reference implementation. This approach can help eliminate the need for users to reinvent memory systems and reduce context loss.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#mixed precision#training loop#device allocation#conversation history#memory management

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING