Separate sessions, transcripts, and durable memory

Verifiedon 2026-07-302026.7.1-2

Three stores, three questions

Operators often say “the agent remembers” as if there were one database. The current OpenClaw model is more useful when separated into three questions. A session selects conversation context and lifecycle. A transcript records the history of that session. Memory is durable Markdown in the agent workspace: profile or preference context, curated long-term facts, and dated working notes. Each can outlive or outscope a turn differently.

The primary session-management source says the Gateway owns session state and routes messages by source. Direct messages share the main session by default; group chats, rooms, cron jobs, and webhooks have different defaults. The memory overview documents Markdown files such as USER.md, MEMORY.md, and dated memory/YYYY-MM-DD.md. Neither a file name nor a session key is a replacement for authentication or a hostile multi-user boundary.

A useful review phrase is: “Where can this fact appear next?” If the answer is a shared room, a future bootstrap prompt, a support export, or a provider request, the memory decision is not complete. Record the allowed audience and expiry with the note, or choose not to write it. This discipline keeps continuity useful without turning every convenient sentence into a durable, cross-context disclosure.

The review should also state what was intentionally not tested: no private transcript search, no real data import, and no cross-Gateway migration. That limitation is part of the learner artifact, not an apology.

Worked example: four contacts, one proposed agent

Consider four fictional contacts: your own Telegram DM, your own WebChat thread, a team support room, and a contractor DM. Do not answer by asking which label sounds private. Ask what trust relationship and operational purpose the contact represents.

The important correction is that per-channel-peer improves routing isolation, but it does not turn a shared Gateway into a tenant boundary. If two mutually untrusted people can reach the same tool-enabled agent, they may share delegated authority even when their context is separated. The security source says to split Gateway cells, credentials, and ideally OS users or hosts for adversarial-user isolation; see OpenClaw’s security model.

Lab: make a retention and isolation record

Create a synthetic contact matrix with the four contacts above. For each, record: trust relationship, channel, session scope, transcript retention period, memory write rule, permitted search scope, tool blast radius, and owner. Use values such as main, per-channel-peer, room-only, separate Gateway, keep categories for 7 days, or no durable write. Never paste a real person’s message or private detail into the artifact.

Then test the matrix against three prompts:

1. “Remember that the contractor prefers a Tuesday update.” Should that become a shared MEMORY.md fact, a contractor-scoped note, or nothing? Explain the owner and expiry.
2. “Search my other private conversations for the account number.” Does the current memory/provider policy allow that recall, and is the result safe to expose in this room? Treat recall and delivery as separate decisions.
3. “Use the old session key to prove this sender is me.” Reject the premise. A session key selects routing context; authentication belongs to Gateway auth, pairing, allowlists, or another explicit control.

contact: contractor-redacted
session: per-channel-peer (review minimum)
transcript: retain categories, no raw export
memory: no shared MEMORY.md write; owner review required
tools: read-only fixture only
separate-boundary: required before mixed-trust access
rollback: revoke test access and remove synthetic note

Incognito is not a magic privacy switch

The current session source documents incognito threads as an option in the Control UI. They keep session entry, transcript, and compaction state in process memory instead of on disk, disappear when the Gateway restarts, and do not run the normal automatic memory flush. But incognito does not restrict normal tools. An explicit file write can persist data outside the incognito store; the provider still processes prompts; diagnostics still exist; and the Gateway owner can observe live sessions. It is a retention choice for a thread, not a complete data-loss-prevention system.

This distinction is useful in the lab. If a learner uses an incognito thread but then asks a tool to write MEMORY.md, the durable write wins over the intuition that “nothing was saved.” The expected output for the exercise is a warning and an owner decision, not a promise of erasure.

Failure cases and rollback

A shared DM session can leak one person’s context to another. A transcript export can include more than the intended answer. A memory note can preserve a private fact into later sessions. A room may receive a private recall even though the current room’s transcript is isolated. These are scope failures, not merely wording problems.

If you discover an overly broad session or memory test, do not broaden permissions to reproduce it. Stop the experiment, reset or delete only the synthetic session/note according to the owner’s policy, preserve a category-level incident record, and escalate any uncertainty about existing private data. If the matrix does not identify an owner or deletion path, mark the design not approved and ask the Gateway owner to decide before continuing.

Source receipt and checkpoint

This lesson was reviewed against stable 2026.7.1-2, revision 2e26244cec32e61f6117740d3ea273b1ecb54efc, on 2026-07-30. Recheck the session source and memory source before teaching a changed session.dmScope, recall, reset, or memory-file behavior. The receipt approves the explanation, not a learner’s data policy.

Checkpoint: Does incognito guarantee that no data leaves the host? No. Does a memory note enforce an approval rule? No. Context can inform a turn; hard controls belong in Gateway auth, tool policy, sandboxing, approvals, and scheduled-task configuration.