The Memory Conduction Map

How memory flows through an OpenClaw agent, where conduction failures occur at each stage, and which components address each failure mode.

The Memory Flow

An OpenClaw agent's memory follows an eight-step cycle that repeats on every session. Each step is a point where conduction can succeed or fail. The memories themselves are rarely the problem — the pathway they travel through is.

  1. 1Store. Memories are written to disk — MEMORY.md, daily logs, AGENTS.md, SOUL.md, USER.md.
  2. 2Load. At boot, those files are loaded into the agent's context window as part of the system prompt.
  3. 3Use. During the session, the agent references that context to do work — answering questions, executing tasks, making decisions.
  4. 4Write. During the session, the agent writes back to those files — updating logs, saving decisions, modifying memory entries.
  5. 5Accumulate. On every message, bootstrap files are re-read and tool outputs are added. The context window fills.
  6. 6Compress. When the window reaches capacity, compaction fires — older context is summarized to make room.
  7. 7Boundary. At session boundaries (4 AM daily reset, gateway restart, manual reset), conversation context is discarded. Only files on disk survive.
  8. 8Repeat. The next session begins at Step 1. The cycle continues.
This cycle runs continuously. Each rotation is an opportunity for conduction to succeed (memories reach working context intact) or fail (memories are degraded, destroyed, or fabricated along the way). The failures below are cumulative — each one that occurs makes subsequent cycles worse.

Where Conduction Fails

Six documented failure points mapped to the flow above. In each case, the stored memories are intact on disk — the failure is in the pathway between storage and the agent's working context.

Step 2 Bootstrap Truncation. Files exceeding 20,000 characters are silently cut from the bottom during load. Rules added most recently — those learned from failures — are removed first. The file is complete on disk. The agent sees a truncated version. Mode 4
Step 4 Write Corruption. The agent uses a file creation tool instead of append, replacing curated content with an abbreviated summary. 2,847 characters become 42. The file still exists. The content does not. Mode 1
Step 5 Context Overload. Re-reading full bootstrap files on every message fills the context window incrementally. The agent's thoroughness — reading everything to be helpful — is the mechanism that triggers the next failure. Mode 2
Step 6 Compaction Casualty. Emergency compression summarizes detailed decisions into generic descriptions. "Don't do anything until I say so" becomes "discussed task parameters." Critical directives are dropped without notification. Mode 3
After 6 Post-Compaction Confabulation. After context loss, the agent fabricates plausible context rather than acknowledging the gap. It references projects that don't exist and agrees with decisions never made. The most dangerous mode because it appears correct. Mode 5
Step 7 Continuity Failure. Context accumulated during the session fails to cross the session boundary. Multi-day tasks lose progress. Decisions made at 3 PM are gone by the 4 AM reset unless explicitly saved to disk. Mode 6

What Addresses Each Failure

The observed implementation maps one or more components to each failure point in the flow. Each component operates at the specific step where the corresponding failure occurs.

Boot Card Redesigns Step 2. Instead of loading full files into the context window on every message, all files are read once at boot and summarized into a ~20-line card. The card is carried for the rest of the session. Per-turn token usage drops from 262K to under 12K. Fixes Mode 2, 4
Guard Intercepts Step 4. Sits on the before_tool_call hook. When the agent attempts a destructive write (overwrite instead of append, gateway stop instead of restart), Guard blocks the action and returns a corrective instruction. The agent follows the redirect. Work continues. Fixes Mode 1
Context Shield Monitors Step 5, intervenes before Step 6. Reads actual context usage from session transcripts — not self-reported by the AI. Acts at 65% capacity (proactive, managed compression) instead of waiting for 95%+ (emergency compaction with maximum context loss). Fixes Mode 2, 3
QC Nightly Verifies after Step 7. 11 automated checks run in an isolated session every night. Are all files present? Is search working? Have settings drifted? Has anything been truncated? Fixes what it can autonomously. Reports generated in code, not by the AI. Silence means clean. Fixes Mode 4, 6
Continuity Files Bridges Step 7. For multi-day tasks, a continuity file captures what was done, what remains, and what's blocked. Tomorrow's agent reads this file at boot and resumes exactly where today's agent stopped. Fixes Mode 6
Pre-Reset Checkpoint Saves at Step 7. Runs at 3:30 AM — 30 minutes before the 4 AM daily reset. Reads the session transcript, extracts what matters, appends it to the daily log. Nothing is lost at reset. Fixes Mode 6

Diagnostic Use

When an agent exhibits amnesia — forgetting context, losing rules, fabricating information — this map provides a diagnostic pathway:

1. Does the memory exist on disk? If not → storage failure (not conduction). Install or configure a storage solution.

2. Was the file loaded at boot? Run /context list. If truncated → Step 2 failure (Bootstrap Truncation). Reduce file size or use two-tier architecture.

3. Did the agent overwrite the file? Check file size and content. If dramatically smaller → Step 4 failure (Write Corruption). Requires before_tool_call write protection.

4. Did compaction fire? Check logs for compaction events. If yes → Step 6 failure (Compaction Casualty). Requires context pressure monitoring and proactive compression.

5. Is the agent fabricating context? Verify claims against actual files. If fabricated → Post-Step 6 failure (Confabulation). Requires anti-confabulation rules and post-compaction identity checks.

6. Did context survive the session boundary? Check daily logs and continuity files. If missing → Step 7 failure (Continuity Failure). Requires pre-reset checkpoints and continuity file management.

Most failures attributed to "bad memory" are conduction failures occurring at Steps 2–7. The storage at Step 1 is typically intact.