Untitled

Direct answers

1. Do we already have a deterministic append tool now?

• Partially, but not as a general agent-facing tool.
• In normal turns, the exposed file tools are read, write, and edit. There is no first-class generic append tool.
• Inside OpenClaw's automatic pre-compaction memory-flush path, there is an internal append-only wrapper for write. Local code shows appendMemoryFlushContent() plus wrapToolMemoryFlushAppendOnlyWrite(), which restrict writes to one allowed path and appends instead of overwriting. Evidence: /opt/homebrew/lib/node_modules/openclaw/dist/auth-profiles-DRjqKE3G.js:94918-94935, :94955-94972, :95953-95958.
• So, yes, OpenClaw already has deterministic append behavior in one narrow path, memory flush. No, it does not expose that as a general-purpose daily-notes append primitive you can call from any workflow.

1. Does default OpenClaw install have something like this?

• Yes, partially.
• Default OpenClaw docs define memory/YYYY-MM-DD.md as the daily log, explicitly described as append-only, and MEMORY.md as curated long-term memory. It also has an automatic pre-compaction memory flush that tells the agent to write lasting notes to memory/YYYY-MM-DD.md before context is compacted.
• But default install does not ship a general canonical daily-note append script or a built-in workflow that funnels all memory writes into one deterministic day file on every event.
• The bundled session-memory hook is related, but it is different. It writes separate memory/YYYY-MM-DD-slug.md files on /new or /reset, not the canonical memory/YYYY-MM-DD.md daily log.

1. If not, what are people in the OpenClaw community doing instead?

• The strongest visible pattern is the flat markdown memory model that OpenClaw documents: MEMORY.md plus memory/YYYY-MM-DD.md, with automatic pre-compaction flushes and memory search over those files.
• A second pattern is enabling session-memory as a backup or audit trail, even though it creates separate session files rather than appending to the canonical day file.
• A third pattern is pointing memory search at extra markdown sources, often an external notes vault such as Obsidian, or using plugin-based alternatives for richer memory. Public examples and requests show people experimenting with QMD-backed search, Obsidian vaults, structured folder layouts, Graphiti, Mnemon, and similar approaches.
• I did not find strong public evidence that the community norm is "build a custom deterministic append script for daily notes." The public evidence points more to: use the default markdown memory files first, then extend search or structure if needed.

1. For options A, B, and C, how common or idiomatic are they, and what are the tradeoffs?

• Option A, one canonical append path for sanitized daily notes, is the most idiomatic extension of OpenClaw's documented model. It aligns with memory/YYYY-MM-DD.md as the source-of-truth daily log. Low complexity, low risk.
• Option B, event-driven capture into that canonical path, is plausible and still aligned with OpenClaw, but it is already custom runtime plumbing. Medium complexity, medium risk, mainly dedupe and event-coverage problems.
• Option C, full session harvester plus auto-promotion, is not the visible default or community norm. Public discussion suggests many users want more automation, but also that resets, flush timing, and file layout are still moving parts. High complexity, high privacy and correctness risk.

Short recommendation

• Do Option A first.
• Do not build Option C now.
• Only do Option B after Option A exists and you have a clean answer for how to handle current session-memory output.

Local docs and defaults

What the official docs say

1. Default memory model is markdown files in the workspace.

• Local docs: /opt/homebrew/lib/node_modules/openclaw/docs/concepts/memory.md
• Public docs: https://docs.openclaw.ai/concepts/memory
• Key points from the docs:
• memory/YYYY-MM-DD.md is the daily log, append-only.
• MEMORY.md is curated long-term memory.
• The files are the source of truth.
• OpenClaw reads today and yesterday at session start.

1. Default automatic behavior is pre-compaction memory flush, not general event capture.

• Same doc: concepts/memory.md
• Public deep dive: https://docs.openclaw.ai/reference/session-management-compaction
• The built-in automatic memory behavior is a silent agentic turn near compaction that reminds the model to write durable notes to memory/YYYY-MM-DD.md.
• This is the one place where local code currently enforces append-only write behavior.

1. session-memory is bundled, but it is a separate hook and not the canonical daily-log writer.

• Local bundled hook doc: /opt/homebrew/lib/node_modules/openclaw/dist/bundled/session-memory/HOOK.md
• Public docs: https://docs.openclaw.ai/automation/hooks#session-memory
• Local hook metadata from openclaw hooks info session-memory confirms actual events are command:new and command:reset.
• The hook writes memory/YYYY-MM-DD-slug.md, with session metadata and a mechanical summary. It does not append into memory/YYYY-MM-DD.md.

1. Heartbeat guidance exists, but it is guidance, not a built-in daily-note append subsystem.

• Local AGENTS template: /opt/homebrew/lib/node_modules/openclaw/docs/reference/templates/AGENTS.md
• Public doc: https://docs.openclaw.ai/reference/templates/AGENTS
• The template suggests tracking periodic checks in memory/heartbeat-state.json and periodically reviewing daily notes into MEMORY.md.
• This is a recommended agent pattern, not a default deterministic daily-note writer.

What the current local setup is actually doing

1. session-memory is enabled locally.

• Local config: /Users/vinny/.openclaw/openclaw.json
• Relevant block: hooks.internal.entries.session-memory.enabled = true

1. Local memory backend is not the default.

• Local config has memory.backend = "qmd" and memory.qmd.includeDefaultMemory = true.
• It also indexes artifacts/**/*.md.
• Default OpenClaw docs describe memory-core as the default memory plugin. QMD is experimental and opt-in.

1. Daily reset defaults still matter.

• Local config does not override session reset behavior.
• OpenClaw's session docs say daily reset is default, 4:00 AM local, on the next inbound message after the boundary.
• This matters because pre-compaction flush and session reset are different code paths.

1. Current local setup is mixed.

• Canonical daily files exist under workspace/memory/YYYY-MM-DD.md.
• Separate session dump files also exist, for example memory/2026-03-13-1500.md, which contains Session Key, Session ID, and a conversation summary.
• That means the local corpus is already mixing canonical daily notes with session-level mechanical dumps.

Important local doc and behavior nuance

I found a small docs drift, not a fundamental conflict:

• automation/hooks.md describes session-memory in the getting-started section as saving context when you issue /new.
• The bundled hook doc and openclaw hooks info session-memory both show the actual events are /new and /reset.
• That does not change the recommendation, but it does mean the bundled hook doc and runtime metadata are more precise than the summary blurb.

Community patterns, public evidence, and confidence level

Confidence level: medium for the broad pattern, low for claiming one single community norm beyond "markdown memory first."

Pattern 1, default markdown memory is still the center of gravity

Public docs and public feature requests consistently refer to:

• MEMORY.md
• memory/YYYY-MM-DD.md
• pre-compaction memory flush
• memory search over those files

That suggests the idiomatic baseline is still flat markdown memory, not a custom event-sourced append pipeline.

Evidence:

• https://docs.openclaw.ai/concepts/memory
• https://docs.openclaw.ai/reference/session-management-compaction
• https://github.com/openclaw/openclaw/issues/62488
• This proposal explicitly describes current OpenClaw memory as flat: MEMORY.md plus memory/YYYY-MM-DD.md.

Pattern 2, people are actively hitting reset and flush gaps

There are public issues arguing that daily reset and /new or /reset do not preserve memory as cleanly as compaction does.

Evidence:

• https://github.com/openclaw/openclaw/issues/45608
• Requests a pre-reset agentic memory flush because the current fallback is the session-memory hook's mechanical dump.
• https://github.com/openclaw/openclaw/issues/56072
• Says daily session reset silently discards context without memory flush or compaction, and notes that session-memory only covers explicit commands.

Takeaway:

• Community members are not pointing to an existing standard built-in daily-notes append solution that solves this cleanly.
• They are mostly asking for OpenClaw's built-in flush path to be extended, which supports Option A much more than Option C.

Pattern 3, people extend memory by adding search sources or external markdown vaults

Public examples show users trying to make memory richer by indexing more markdown, not by replacing the daily log with a complex custom harvester.

Evidence:

• https://github.com/openclaw/openclaw/issues/22958
• Requests Obsidian vault integration, explicitly treating OpenClaw workspace memory files as the current baseline and asking to point memory config at a vault.
• Public search results also show discussions around Graphiti, Mnemon, and similar plugins. I treat those as evidence of experimentation, not of a settled norm.

Takeaway:

• The visible extension path is "more searchable markdown" or "plugin memory," not "everyone writes a custom deterministic append script."

Option A, B, C comparison

Using the option definitions from the earlier local audit artifact:

• Option A: one canonical append script for sanitized memory/YYYY-MM-DD.md, explicit flushes only, disable or move raw session-memory output.
• Option B: Option A plus more runtime events triggering the canonical append path.
• Option C: continuous session harvester with auto-promotion into longer-term memory.

Tradeoffs in plain terms

Option A

• Pros: closest to docs, lowest chance of bad recall, easiest to audit, easiest to change later.
• Cons: not full autopilot, still depends on explicit flush moments.

Option B

• Pros: better capture coverage without jumping all the way to a harvester.
• Cons: requires event design, dedupe, and clear rules about what is safe to append.

Option C

• Pros: highest theoretical capture.
• Cons: most likely to pollute memory, leak sensitive detail into search, and create maintenance work when resets, hooks, and compaction interact.

Recommendation

Recommend Option A.

Why:

1. It matches the documented OpenClaw memory shape, memory/YYYY-MM-DD.md plus MEMORY.md.
2. It matches the built-in append-only idea already present in pre-compaction memory flush.
3. It avoids doubling down on the current local problem, mixed canonical notes plus session dumps in the same searchable corpus.
4. Public community evidence does not show a strong norm for a more complex custom harvester. The public pressure is mostly for better built-in flush behavior around reset boundaries, not for a user-land full harvester.

Concrete decision guidance:

• If Pete wants the smallest thing that looks like OpenClaw, build Option A.
• If Pete wants more automation after that, add a narrow Option B layer, one event at a time.
• Do not build Option C until there is a tested redaction policy, a dedupe spec, and a hard answer for where raw session archives live.

Bottom line

• OpenClaw already believes in append-only daily notes.
• OpenClaw does not yet expose that as a general-purpose append tool across all workflows.
• Default install gives you the file model and the compaction-time memory flush, not a complete deterministic daily-notes pipeline.
• The most idiomatic move is not to invent a complicated new memory system. It is to standardize one canonical append path around the existing memory/YYYY-MM-DD.md model.

Ready for review: yes