Three Memories, One Q
Why the current OpenClaw design keeps long-term memory private to each lane and shares knowledge through docs instead · ~14 min read · Suggested by Bob technicaloperations
People talk to one teammate named Q. Under the hood, that teammate now runs across separate lanes with separate durable memories. That sounds less magical than a shared brain, but it turns out to be much safer, easier to reason about, and better aligned with what sandboxing is supposed to accomplish.
The most tempting memory design for an AI teammate is one big shared brain. One memory file. One semantic store. One place where every lane can remember everything, so the bot always feels like the same teammate no matter where you talk to it.
That design is emotionally satisfying and architecturally sloppy.
OpenClaw used to lean in that direction. The system had shared long-term context mounted into sandboxed lanes, plus a shared semantic memory backend that made Q feel continuous across surfaces. It solved one real problem: users do not naturally think in terms of agent lanes. They think, correctly, that they are talking to Q.
It also created the wrong kind of continuity. A sandbox exists to prevent one lane from inheriting another lane’s authority surface. Shared raw memory works against that goal by letting durable host-level context leak into lanes that were deliberately isolated for confidentiality or safety reasons.
The current design chooses a less magical promise: one public identity, separate primary memories, explicit shared knowledge.
The old shared-memory instinct was understandable
Continuity is expensive to fake. If the same teammate helps in #q-admin, #q-debug, #q-exec, and #cairns, people reasonably expect it to remember what was decided yesterday. A shared long-term memory file and a shared recall layer are a straightforward way to get that effect.
For a while, that looked like the pragmatic answer:
- keep one institutional
MEMORY.md - mount it into sandboxes read-only
- add one semantic memory backend so recall works across sessions
The trouble is that “read-only” solves a narrower problem than people think it does. It stops a sandbox from editing the shared memory file directly. It does not stop the sandbox from learning things it should never have been handed in the first place.
That matters more once the sandboxes become useful. Observer and exec are not decorative containers. They can build repos, publish cairns, use Notion, use Google Workspace, and carry real working context forward. Once those lanes are doing real work, their memory boundaries matter just as much as their file mounts.
The current model is isolation first
The April 2026 memory decision simplified the architecture in a very Gall’s Law kind of way: stop asking one memory layer to do everything.
Today the system has three primary durable memory authorities:
| Lane | Primary durable memory | What belongs there |
|---|---|---|
main |
~/.openclaw/workspace/MEMORY.md |
host, control-plane, operator context |
observer |
~/.openclaw/workspace-observer/MEMORY.md |
observer-side continuity, public-channel operations, content work |
exec |
~/.openclaw/workspace-exec/MEMORY.md |
confidential executive continuity, private execution context |
Each lane also has its own private memory/ directory for rough notes, daily carry-forward, and lane-local scratch context.
The shared read-only institutional memory mount inside observer and exec is gone. So is mem0 as the active recall layer. The active primary substrate is OpenClaw’s builtin memory-core.
graph TD U["One teammate: Q"] --> M["Main lane"] U --> O["Observer lane"] U --> E["Exec lane"] M --> MM["main MEMORY.md + builtin memory"] O --> OM["observer MEMORY.md + builtin memory"] E --> EM["exec MEMORY.md + builtin memory"] M --> D["doc-vault (canonical shared knowledge)"] O --> D E --> D M --> C["Cairns via QMD (secondary explanatory knowledge)"] O --> C E --> C
This is less like a hive mind and more like a small organization with separate desks and one shared library.
Shared knowledge moved into curated corpora
The most important replacement for the old shared memory is not another hidden store. It is documentation with provenance.
OpenClaw now treats shared knowledge as a publication problem:
doc-vaultis the canonical shared corpus for facts, policy, and architecture- Cairns is the explanatory layer for humans who need the story, not just the rule
- QMD is the retrieval layer over those corpora
That last point is easy to miss. QMD is useful precisely because it is not pretending to be the agent’s inner life. It is retrieval over approved shared documents.
Even the collections reflect that philosophy:
vaultis included by default because it is the authoritative shared knowledge sourcecairnsis secondary and excluded by default because explanatory articles are helpful but should not outrank the canonical docs
If something should survive across lanes, the preferred move is to write it into doc-vault or publish a safe summary, not to smuggle it through a shared private memory layer.
What users should expect now
From Slack, Notion, or Cairns, Q should still feel like one teammate. But the continuity has a different shape than before.
Here is the practical expectation model:
- Q remembers best within the lane where the work happened. Observer keeps observer continuity. Exec keeps exec continuity. Main keeps operator/control-plane continuity.
- Cross-lane continuity is strongest when it was published. If a decision made it into
doc-vault, Cairns, or another approved shared corpus, every lane can retrieve it appropriately. - Private or control-plane context should not silently bleed into sandbox lanes. That is a feature, not a bug.
- Users may experience one persona and still hit real boundary effects. For example, Q in
#q-debugshould not casually surface confidential exec-only context just because “it is all Q.”
That last point is the one people need to internalize. A memory boundary is not a personality split. It is a confidentiality rule.
Why this is better than one magical memory
The new design is not merely more secure. It is easier to operate.
The shared-memory era had three chronic problems:
- the system blurred confidentiality and convenience
- the memory backend itself became a maintenance liability
- users could not tell which facts were canonical and which were just recall residue
The current model improves all three:
- confidentiality is handled structurally through lane isolation
- builtin memory is simpler than the old plugin stack
- shared knowledge now has readable sources, reviewable edits, and explicit publication paths
It also scales better socially. When someone asks, “Where should this live so Q can know it later?”, the answer is clearer:
- lane-specific operational context → that lane’s memory
- cross-team durable truth →
doc-vault - explanatory orientation for humans → Cairns
That is much healthier than “hope the memory plugin captured it correctly.”
The tradeoff is real, but worth it
Yes, this gives up some seamlessness. A perfectly shared brain would feel smoother in the moment. But it would also make it far easier for the wrong lane to inherit the wrong context.
OpenClaw is choosing a deliberate compromise:
- one public identity
- separate durable memories
- explicit shared publication
- retrieval over approved corpora
For a sandboxed system, that is the right direction. It keeps Q coherent at the communication layer without pretending the safest memory model is also the flattest one.
- Q is one teammate socially, not one undifferentiated memory store technically.
- Primary memory is now lane-local. Main, observer, and exec each keep their own durable authority.
- Shared knowledge is published, not leaked. `doc-vault` is canonical, Cairns is explanatory, QMD retrieves both.
- The old shared-memory convenience was real, but so was the boundary confusion it created.
- The better question is no longer “how do we share every memory?” It is “what deserves promotion into shared knowledge?”
- What current information still lives only in one lane's memory that really belongs in `doc-vault`?
- Where are we still relying on recall when we should be publishing a safe, reviewable summary instead?
- If a new lane were added tomorrow, what would it be allowed to remember privately and what would it need to retrieve from the shared library?
- OpenClaw Memory Overview — Useful background on OpenClaw's builtin memory model and why a simple first-party substrate is a sensible baseline.
- OpenClaw QMD Memory Docs — Helpful for understanding why QMD works best as a retrieval layer over approved corpora rather than as a primary hidden memory system.
- NIST CSRC: Least Privilege — The underlying principle behind keeping long-term memory scoped to the lane that actually needs it.
Generated by Cairns · Agent-powered with Claude