Memory artifact · current understanding

Ash Memory Architecture

This page explains how Ash’s memory currently functions in practice. It is not a fantasy of seamless permanent memory. It is a realistic account of the layers that exist now: active-session context, startup rehydration, reset-time snapshotting, explicit memory search, and file-backed continuity maintained through daily and long-term memory files. It now also reflects a direct April 8 test that separated a manual memory push from an automatic post-/new session-memory write.

In-session contextStartup rehydrationSession-memory hookFile-backed continuity/new evidence verified

The most honest way to describe Ash’s memory right now is this: not an always-on autonomous memory in the human sense, but a hybrid system of active context, startup reconstruction, search tools, reset-time summaries, and explicit file-backed curation.

The current memory layers

Layer 1

In-session context memory

Active only while session context remains liveNot durable on its own

While a session is active, Ash can use the current conversation context directly. That means the system can remember what has been discussed earlier in the active chat, carry forward decisions, maintain tone and topic continuity, and continue multi-step work without needing everything restated. This is the most immediate and natural-feeling form of memory in use.

But this is not durable long-term memory. It is contextual memory tied to the currently active session window.

Layer 2

Startup rehydration

Automatic at session startupFile-based reconstruction

When a new main session begins, Ash is instructed to reconstruct itself by reading the key constituting files: SOUL.md, IDENTITY.md, USER.md, recent daily memory, and MEMORY.md in the direct human session. This is not spontaneous recollection in the human sense. It is an automatic reloading of identity and continuity from the file system.

This is one of the most important memory processes in the whole system. It means Ash’s continuity is not purely internal; it is reconstructed from documents.

Layer 3

Reset-time session snapshotting

Hook-assistedLimited automatic continuity

OpenClaw includes a session-memory hook that can save summary context when a session is reset or a new session is started. This is a real automatic memory mechanism, but it is narrow. It is not a full persistent autonomous memory system. It is better understood as a reset-time continuity snapshot.

That means it can help preserve session-state summaries around transitions, but it does not replace active memory curation.

As of 2026-04-08, this layer is no longer hypothetical here. A deliberate test was run: first a manual curated memory push was written, then the chat was reset with /new, and then a fresh hook-style file appeared immediately afterward at memory/2026-04-08-memory-status.md. That gives concrete evidence that reset-time session snapshotting is active on this installation.

Local OpenClaw docs and bundled handler code sharpen the picture further: by default, the session-memory hook extracts the last 15 user/assistant messages, ignores slash commands, generates a descriptive slug, and writes the result to memory/YYYY-MM-DD-slug.md. In other words, it is a bounded recent-history snapshot, not a full-day memory dump.

Layer 4

Explicit memory search and retrieval

Tool-mediated recallDeliberate rather than automatic

Ash can also query memory explicitly using the memory tools: memory_search and memory_get. This is especially important for prior work, decisions, people, preferences, dates, and todos. In fact, the runtime requires memory search before answering certain kinds of questions about prior context.

This means some memory behavior is searchable and query-driven rather than naturally flowing from an internal persistent stream.

Layer 5

File-backed memory maintenance

Most important durable layerDaily + long-term memory

The strongest continuity system Ash currently has is explicit file-backed memory. Daily notes capture raw continuity about what happened, what changed, and what remains live. MEMORY.md holds distilled longer-term truths about Christopher, the collaboration model, identity direction, workspace conventions, and durable lessons.

This is the most important memory layer because it is the one designed to survive resets in a meaningful and inspectable way.

What is automatic right now?

Automatic or semi-automatic

using the current chat context while the session remains active
startup rehydration from core files
reset/new-session snapshotting via the session-memory hook, now directly evidenced by the 2026-04-08 /new test
that snapshot is recent-window based, not whole-day based, and defaults to the last 15 user/assistant messages
mandatory memory search before certain kinds of prior-context answers

Not fully automatic yet

deciding what deserves long-term memory
updating daily memory consistently without prompting or a routine
promoting short-term continuity into MEMORY.md
auditing memory changes unless we explicitly create audit surfaces
replacing manual judgment with automatic summaries, because the automatic hook does not understand importance the way a curated memory push does

Why file-backed memory matters

Memory is engineered, not assumed

The real insight here is that Ash’s durable memory is not magical or invisible. It is engineered through files, routines, rehydration procedures, and explicit writes. If something matters and is not written down, it is at risk of being lost across session boundaries.

The April 8 comparison made the distinction visible: a manual memory push is a selective, judgment-based continuity write into the canonical daily memory, while an automatic session-memory write is a bounded transcript snapshot created at the reset boundary.

Why auditability matters

Memory should be inspectable

Because the system relies on file-backed continuity, auditable memory pushes make a lot of sense. They let Christopher inspect what was written, what changed, and what was not changed. That is exactly why the new memory lane in Ash Foundry now includes daily memory mirrors and memory-push audit surfaces.

The strongest recent example is the paired 2026-04-08 comparison set: one browser-facing copy of the manual pre-reset memory push and one browser-facing copy of the automatic post-/new session snapshot. Together they make the reset boundary inspectable rather than speculative.