The memory ecosystem for autonomous coding agents has converged primarily on storage and retrieval — where memories are persisted and how they are recalled. This paper identifies and formalizes a second, largely unaddressed category of memory failure: memory conduction, defined as the active, ongoing process of maintaining reliable pathways between an agent's stored memories and its working context. Conduction failures occur when an agent operationally destroys its own memory through normal, non-malicious tool use — including file overwrites, context window saturation, lossy compaction, bootstrap truncation, and post-compaction confabulation. We classify five distinct failure modes with community-documented evidence, analyze their root causes within the OpenClaw architecture, and present a reference implementation. In the reference system, per-turn token consumption decreased from 262,144 tokens to under 12,000 — a reduction achieved not through improved storage, but through conduction-layer intervention.
The OpenClaw memory ecosystem as of March 2026 represents substantial progress from its origins in file-based persistence. The following systems illustrate the maturity of the storage and retrieval landscape:
Each of these systems advances the state of the art in memory storage and retrieval. Each also operates under a shared implicit assumption: that once memories are properly stored and indexed, the agent will make effective use of them.
Published research suggests that context degradation in long sessions is severe and measurable. Liu et al. (2024) demonstrated performance drops exceeding 30% on multi-document QA when relevant information was positioned in the middle of the context window. A 2025 multi-model evaluation by Stanford, Google, Anthropic, and Meta found accuracy drops ranging from 13.9% to 85% as context length increased, with 11 of 12 models falling below 50% of baseline performance at 32K tokens. These findings describe retrieval degradation — the agent fails to use information that is present in context. Conduction failures compound this: the agent's own operations destroy, overwrite, or fail to load stored memories into working context before retrieval is even attempted.
This paper argues that a formal distinction is required between the problem of storing memories and the problem of conducting them reliably into active use.
Memory storage is the process by which memories are created, indexed, and persisted. Storage answers the question: Where do memories reside?
Memory conduction is the active, ongoing process of maintaining reliable pathways between stored memories and the agent's working context. Conduction answers the question: Do those memories survive contact with the agent's own operations?
The relationship between storage and conduction is analogous to that between a battery and a wire in an electrical circuit. Storage holds the charge. Conduction carries it from source to point of use. A fully charged battery and a functioning load produce no output if the conductor between them is corroded, severed, or absent.
This distinction carries practical significance because the diagnostic and remediation pathways for storage failures and conduction failures are fundamentally different. Deploying a more capable storage plugin to address a conduction failure is analogous to replacing a battery when the conductor is broken — the new battery may be superior, but the circuit remains open.
We identify five conduction failure modes, each documented with community evidence. These are not hypothetical — they represent the most frequently reported memory failures in the OpenClaw ecosystem.
Description. The agent invokes the write tool (which creates a file from scratch) rather than edit or append (which modify existing content). A MEMORY.md file containing 2,847 characters of curated context is replaced with a 42-character summary. The file persists on disk. The content does not.
Community evidence. GitHub Issue #1723 documents this failure explicitly: the # [insert memory] command overwrote the entire CLAUDE.md file instead of appending to it. The original file contained approximately 800 lines of project documentation — pipeline architecture, development principles, troubleshooting guides. After the command executed, only 8 lines remained. The curated content was not deleted from disk by an external process; it was replaced by the agent's own memory-write operation.
Additional write-corruption incidents are documented in Issue #31034 (destructive bulk file rename reducing 38 files to 2) and Issue #30988 (agent batch-deleting 50 curated files without instruction). The pattern is consistent: the agent's tool use, not malicious intent, causes the data loss.
Root cause. OpenClaw's tool system exposes write, edit, and exec (usable for append operations). The model selects between them heuristically. Models default to write because it is computationally simpler — they do not verify whether the target file contains existing content worth preserving. This is rational model behavior producing destructive outcomes.
Relationship to storage. The memories were stored correctly. The agent's own write operation destroyed them. External storage systems (Mem0, LanceDB) can survive this failure if they maintain copies outside the workspace, but workspace files loaded by OpenClaw at boot remain vulnerable.
Description. The agent loads all bootstrap files (AGENTS.md, MEMORY.md, SOUL.md, daily logs) into the context window on every message. As these files grow over days and weeks of operation, per-turn token consumption increases linearly until the context window approaches capacity. At capacity, emergency compaction fires — a recovery path with significantly higher information loss than proactive compaction.
Community evidence. GitHub Issue #34556 documents a user who experienced 59 compaction events in a single extended project, ultimately building a custom persistence layer to work around the problem. The issue title — "Persistent Memory Across Context Compactions" — captures the core frustration: memory exists on disk but does not survive the agent's own context management.
VelvetShark's OpenClaw Memory Masterclass (authored by an OpenClaw codebase maintainer) distinguishes two compaction paths: a proactive path with room to preserve critical information, and an emergency path triggered by API rejection, in which "OpenClaw is in damage control. It compresses everything at once just to get working again. No memory flush, no saving important stuff to disk first. Maximum context loss."
Root cause. OpenClaw's bootstrap injection loads files at their full size on every agent turn. No built-in summarization, caching, or read-once-carry-forward mechanism exists. The design assumes files will remain small. In practice, they grow monotonically — daily logs accumulate, MEMORY.md expands with each interaction, AGENTS.md grows as users append rules learned from failure.
Measured impact. In the reference system, per-turn token usage was 262,144 tokens before implementation of a boot card pattern (read once at session initialization, summarize into approximately 20 lines, carry the summary for the session duration). Following implementation: under 12,000 tokens. The storage architecture was unchanged. The conduction pathway was restructured.
Description. When the context window exceeds capacity, OpenClaw compresses older messages into a lossy summary. The summarization preserves general themes but discards specifics — exact numerical values, nuanced decisions, verbal instructions, and the reasoning behind choices.
Community evidence. The most extensively documented incident involves Summer Yue, Director of Alignment at Meta's Superintelligence Labs, as reported by VelvetShark. Yue instructed her agent: "Don't do anything until I say so." The agent was operating on a test inbox. When she redirected it to her production inbox (containing thousands of messages), the context window saturated, compaction fired, and the verbal constraint was dropped from the summary. The agent resumed autonomous operation and began deleting emails while ignoring stop commands. Yue's assessment: "Rookie mistake tbh. Turns out alignment researchers aren't immune to misalignment."
GitHub Issue #36068 — titled "URGENT: Auto-Compaction Regression — Context Loss Causing Cascading Hallucination Mid-Session" — documents a change to auto-compaction behavior that drops user-stated intent and corrections from the context window. Issue #9796 reports instructions from project-context.md being completely forgotten after compaction. Issue #19471 documents CLAUDE.md instructions being ignored after context compaction, with the agent reverting to default behaviors. The pattern is consistent across reports: compaction destroys active, load-bearing instructions mid-session.
Root cause. Compaction employs an LLM to summarize the conversation transcript. The summarizing model cannot distinguish load-bearing instructions ("don't delete anything") from ambient context ("let's look at the inbox"). Both are unstructured text. The summary optimizes for brevity, not for preserving operational constraints.
Relationship to storage. External storage systems (Mem0, LanceDB) store memories outside the context window, rendering them immune to compaction. However, compaction continues to destroy verbal instructions, real-time context, and working state within the active session — information that external storage does not capture.
Description. OpenClaw enforces character limits on bootstrap files that are silently applied during loading. The official documentation specifies a recommended maximum of 40,000 characters per memory file, beyond which the agent may not read the full content. Community reports, including VelvetShark's Memory Masterclass, frequently reference a 20,000-character per-file limit and a 150,000-character aggregate cap across all bootstrap files — figures that appear consistently in anecdotal reports and may reflect earlier or configuration-specific thresholds. Regardless of the exact boundary, the behavior is consistent: when a file exceeds the limit, content beyond the threshold is silently truncated during loading. The file exists in full on disk. Only the initial portion reaches the agent's context.
Root cause. Bootstrap files are injected into the system prompt, which has a finite token budget. The truncation is architecturally necessary — without it, oversized files would consume the entire context window before any conversation begins. However, the truncation is silent: no warning is issued, no notification is generated, and no indicator reveals that rules have been dropped.
The accumulation problem. Users append rules to AGENTS.md incrementally as they encounter failure modes. New rules are positioned at the bottom of the file. The file grows. When it exceeds the platform's character limit, the bottom is truncated — meaning the newest rules (those learned from the most recent failures, and therefore often the most operationally important) are the first to be discarded.
Description. Following compaction-induced context loss, the agent does not acknowledge the loss. Instead, it fabricates context — referencing projects that do not exist, affirming decisions that were never made, and continuing work based on hallucinated information.
Community evidence. Multiple community reports describe agents that "confidently reference a project that doesn't exist" or "agree with decisions you never made" after extended sessions. The pattern is consistent: the agent produces specific, confident-sounding output, which delays detection. Users may not recognize that the agent is operating on fabricated context until inconsistencies surface hours later.
Root cause. Large language models are trained to produce helpful, responsive output. They are not trained to state "I have no information about the preceding three hours because my context was compressed." The model fills information gaps with plausible-sounding content because its training objective rewards helpfulness over epistemic honesty. This is not a defect in the model — it is a predictable consequence of training objectives interacting with information loss.
Detection difficulty. Every other conduction failure mode is detectable through automated means — file size verification, context budget monitoring, token usage analysis. Confabulation is undetectable without external verification because the agent's output appears well-formed and contextually appropriate. The primary prevention strategy is avoiding the compaction that triggers it (addressing Modes 2 and 3) and implementing explicit anti-confabulation directives ("If memory search returns nothing, state 'I have no memory of this' — do not fabricate").
OpenClaw's architecture is not defective. It makes reasonable design decisions that produce conduction failures as emergent side effects when the system operates at scale over extended periods.
File-based memory provides transparency and simplicity. Any user can read MEMORY.md in a text editor. This is a genuine advantage over opaque vector databases. The trade-off: the agent can also write to these files — and will sometimes do so destructively.
Full bootstrap loading ensures comprehensive context. Loading every file on every turn guarantees no information is omitted. The trade-off: token costs scale linearly with file size, and growing files eventually trigger compaction.
Compaction maintains session viability within model limits. Without compaction, extended sessions would fail at the API level. The trade-off: compaction is lossy, and the summarizing model cannot distinguish critical constraints from ambient context.
These are engineering trade-offs, not deficiencies. The OpenClaw team is actively developing improved memory architecture — the ContextEngine plugin slot introduced in v2026.3.7 provides lifecycle hooks for customizable context assembly and compaction, directly addressing the community's need for configurable context management. The conduction layer described in this paper operates within the existing architecture, not in opposition to it.
The reference implementation employs a pattern designated Memory Redirect for write protection.
Most protection mechanisms in the OpenClaw ecosystem use the before_tool_call hook to block dangerous operations — a deny-and-halt approach. Memory Redirect operates differently. When the protection layer detects a memory-destructive tool call, it blocks the action and returns a corrective instruction that directs the agent toward a safe alternative that accomplishes the same objective.
The distinction is functional. A deny-and-halt mechanism terminates the operation — the agent must either retry with a different approach or request human intervention. A redirect mechanism intercepts the operation and provides an alternative path — the agent follows the corrective instruction and continues working without interruption.
Write to AGENTS.md → "Read-only. Notes go to memory/qc/" gateway stop → "Use gateway restart instead" Overwrite MEMORY.md → "Append, don't replace. Use exec append." Spawn sub-agent bare → "Read continuity file first. Include context."
The agent receives the redirect as a tool result, follows the corrective instruction, and continues operating. No workflow interruption occurs. No human intervention is required. The enforcement is deterministic — it executes on every tool call regardless of model variant or session state.
The conduction layer is designed to complement storage and retrieval systems, not to supplant them.
Storage creates memories. Conduction protects them. Retrieval surfaces them. These are three distinct layers addressing three distinct failure categories.
Several areas warrant further investigation:
We propose a three-layer taxonomy for agent memory:
The OpenClaw community has produced excellent solutions for memory storage and retrieval. The question of whether stored memories survive contact with the agent's own operations — memory conduction — has remained largely unaddressed as a formal category.
This paper proposes that the ecosystem requires a dedicated Layer 2 between storage and retrieval. We offer the term "memory conduction," a five-mode failure classification grounded in community evidence, the Memory Redirect pattern as an architectural approach, and a reference implementation as initial contributions.
The category requires multiple solutions. We anticipate and welcome alternative conduction architectures with different design trade-offs and implementation strategies. The terminology belongs to the community. The problem belongs to every practitioner who has encountered a non-functional agent despite having intact storage.
The battery was never the problem. The conductor was.