When harness tuning stops being enough, choose your substrate deliberately: QMD, Mem0, Cognee, Obsidian.
Prerequisites
- OpenClaw installed
- Multi-step workflows where state continuity matters
- Willingness to treat memory as a production system
Outcomes
- Diagnose missed writes vs missed retrieval vs compaction loss.
- Know which architectural change to make first.
If your agent has ever ignored a decision you know you already made, it is usually not random.
It is your memory system.
We were mid-migration with one hard rule: after cutover, do not write to the old table. We agreed explicitly, and the next day the agent generated code that wrote to both old and new tables "just to be safe."
If you are building multi-step workflows, cutovers, runbooks, incident response, multi-day projects, this failure mode is the default unless you engineer around it.
Memory failures usually come from write/read/compaction design, not model quality alone.
Core claim
Memory behavior in production is mostly a systems problem: write path, read path, and compaction policy.
Memory is now more important than ever
I recently wrote about persistent memory for Claude Code:
We are now talking about multi-day horizon tasks, specialist agents, and a chief-of-staff agent that keeps the plan. But there is a hard constraint that does not care how smart your model is:
Models are stateless between calls.
Context windows are bounded.
Anything not made durable eventually falls out of view.
So memory becomes the difference between:
an assistant that can execute a plan across sessions,
and a confident autocomplete engine with amnesia.
Treat memory as read/write/GC system
In practice, memory behaves like three subsystems:
Write path
What gets extracted and persisted, and exactly when.
Read path
How relevant state gets retrieved and injected into active context.
Compaction / GC
What gets summarized, pruned, or dropped under token pressure.
Observability
Whether you can inspect what was saved, retrieved, and ignored.
OpenClaw's default posture is usually painful for real systems:
writes are discretionary,
reads are optional,
compaction gets aggressive under limits.
Memory SLOs
A useful framing is to define three service-level objectives:
✓
Durability: important decisions and constraints survive sessions.
✓
Retrievability: relevant facts get surfaced when needed.
✓
Compaction stability: long sessions do not silently erase critical state.
Harness-level fixes (before substrate changes)
1) Add checkpoint before compaction (memory flush)
Code
json
{
"compaction": {
"memoryFlush": {
"enabled": true,
"softThresholdTokens": 32000,
"prompt": "Write a durable session note to memory/YYYY-MM-DD.md. Capture: decisions, constraints, open questions, owners, and any state that would break the plan if forgotten. If nothing meaningful happened, write NO_FLUSH.",
"systemPrompt": "Be terse. Prefer bullet points. Do not rewrite the conversation."
}
}
}
Why this works:
decisions and constraints are what break systems when lost,
owners matter for multi-agent coordination,
open questions prevent repeated loops.
Trade-off: extra tokens and latency. If flush prompts are sloppy, retrieval becomes noisy.
Cognee adds relationship-aware memory for ownership, dependency, and hierarchy style queries.
Code
python
import asyncio
import cognee
async def main():
await cognee.add("Cognee turns documents into AI memory.")
await cognee.cognify()
await cognee.memify()
results = await cognee.search("What does Cognee do?")
for result in results:
print(result)
if __name__ == "__main__":
asyncio.run(main())
Use graph-backed memory when relationship queries matter: ownership, dependencies, hierarchy, and cross-agent responsibility.
Obsidian: human-in-the-loop governance layer
Obsidian is useful because humans can curate what the agent considers true.
Obsidian adds human curation so your long-term memory stays high-signal and governable.
Two practical patterns:
symlink memory folder into an Obsidian vault for review/edit,
index vault via retrieval backend for curated search.
That creates a governance loop:
agent writes memory,
human curates memory,
retrieval prioritizes curated store,
behavior quality improves.
Multi-agent memory design (org-chart style)
Layered memory topology for agent teams
Components
Per-agent private state
Durable notes and working memory per specialist agent
Zone: private
Shared canonical docs
Profiles, policies, conventions, and operating rules
Zone: shared
Shared retrieval scope
Cross-agent retrieval over canonical knowledge
Zone: shared
Coordinator agent
Reads canonical docs at startup and enforces consistency
Zone: control
Boundaries
- Shared memory without boundaries causes cross-contamination.
- Private-only memory without canonical docs causes drift.
Data flow
Canonical policy updated once
All agents retrieve canonical policy before execution
Coordinator detects and corrects policy drift
Closing recommendations
Start in this order:
Launch checklist
0/6
Then ask hard questions:
What is source of truth when memory conflicts with current chat?
How do we test memory behavior over long runs without anecdotes?
What must be deterministic (policy) vs learned (what to remember)?
How do we prevent memory from becoming a junk drawer?
If you have already shipped an agent system, your scars likely fall into one of three buckets: missed persistence, missed retrieval, or compaction loss.
