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.
Community evidence suggests this assumption fails in approximately 40–60% of extended sessions — not due to storage failures, but because the agent's own operations destroy, overwrite, or fail to load stored memories into working context. The memories exist on disk. The agent cannot access them, or actively damages them, through the normal course of operation.
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. TrilogyAI's memory management guide documents this failure explicitly: "MEMORY.md contained 20+ entries of beautifully curated knowledge. After one single conversation, it was replaced with one line of text. Root cause: The agent used the write tool to create MEMORY.md from scratch instead of editing or appending to it." Their analysis concludes: "LLMs will overwrite files unless explicitly told not to at multiple reinforcement points. A single instruction isn't enough."
GitHub Issue #6877 documents a related vector: the default pre-compaction memory flush prompt causes agents to overwrite daily log files because the instruction "Store durable memories now" does not specify append behavior.
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. TheClawGuy's plugin review states: "OpenClaw forces the agent to re-read those core files on every single message. After a few weeks, your daily logs are so bloated they choke the context window. The agent slows down, starts guessing, and you're paying to process thousands of useless words on repeat."
VelvetShark's analysis (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."
BetterClaw's analysis references GitHub Issue #25633: "Hundreds of developers reporting the same thing: OpenClaw's context compaction silently destroys active work mid-session. Not old conversations from last week. Not stale memory files. The thing you're working on right now."
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 a 20,000-character hard limit per bootstrap file and a 150,000-character aggregate limit across all bootstrap files. When a file exceeds 20,000 characters, the content beyond that threshold is silently truncated during loading. The file exists in full on disk. Only the initial portion reaches the agent's context.
Community evidence. The OpenClaw documentation specifies these limits. VelvetShark's analysis notes: "Files over 20,000 characters get truncated per file. There's also an aggregate cap of 150,000 characters across all bootstrap files. Do injected chars equal raw chars? If not, content is being cut."
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 20,000 characters, 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.
Aristotle is an open-source OpenClaw plugin (MIT licensed) that implements four conduction components:
| Component | Function | Mechanism |
|---|---|---|
| Guard | Write protection | 10 redirect rules on before_tool_call hook |
| Context Shield | Context pressure management | Session JSONL transcript monitoring via three detection methods: ContextEngine API, JSONL parsing, tool-call estimation |
| Boot Card | Efficient context carry | Full file read at session initialization → ~20-line summary → summary carried for session duration |
| QC Nightly | Conduction integrity verification | 11 automated checks executed in an isolated session; deterministic code-generated reports (not model-formatted) |
Four automated overnight processes maintain conduction across the daily session boundary: pre-reset checkpoint (03:30), continuity update (22:45), QC checks (23:15), and report delivery (23:20).
Measured results:
Acknowledged limitations. Three agent behaviors cannot be enforced through deterministic code: post-compaction identity verification, confabulation prevention, and correction acceptance. These depend on the language model's behavioral tendencies. Code controls what the agent does. It does not control what the agent infers.
The implementation comprises approximately 3,000 lines of TypeScript across 11 files.
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.