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.
- 1Store. Memories are written to disk — MEMORY.md, daily logs, AGENTS.md, SOUL.md, USER.md.
- 2Load. At boot, those files are loaded into the agent's context window as part of the system prompt.
- 3Use. During the session, the agent references that context to do work — answering questions, executing tasks, making decisions.
- 4Write. During the session, the agent writes back to those files — updating logs, saving decisions, modifying memory entries.
- 5Accumulate. On every message, bootstrap files are re-read and tool outputs are added. The context window fills.
- 6Compress. When the window reaches capacity, compaction fires — older context is summarized to make room.
- 7Boundary. At session boundaries (4 AM daily reset, gateway restart, manual reset), conversation context is discarded. Only files on disk survive.
- 8Repeat. The next session begins at Step 1. The cycle continues.
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.
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.
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
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.