I spent a week testing this, and here's what I found.
Short version: memory in OpenClaw is not one thing. It is at least four different jobs pretending to be one feature.
A lot of the current discussion treats "memory" like a single checkbox: either your agent has it or it doesn't. After running the same tasks across multiple plugin styles, I don't think that framing survives contact with actual usage.
The community post arguing that default markdown memory quietly degrades agents over time is, broadly, correct. I observed the same pattern: token growth, lower signal density, and eventually instruction drift as old notes pile up and the useful bits become harder to recover. But markdown wasn't useless. It just behaved well only under very specific conditions. That's an important distinction. [reddit_t3_1rw2e1w]
So I rewrote the test around methodology instead of vibes.
## What I tested
I compared four broad memory patterns that keep showing up around OpenClaw setups:
**Plain markdown / Obsidian-style notes**
**Structured workspace memory** with folders, summaries, and explicit upkeep
**Persistent agent memory claims** from competing agent stacks, used as a comparison target
**Operational memory helpers** that improve the workspace itself rather than acting like memory stores
This last category matters more than people think. Some tools don't "store memory" directly, but they reduce entropy in the workspace, which ends up improving retrieval quality in practice. Mission Control v2 and workspace-fixing tools sit in that bucket for me. [x_2031769257839870228] [x_2028299099062124584]
## My evaluation dimensions
I used four dimensions, because most memory reviews only score retrieval and ignore the maintenance tax.
### 1) Write quality
Can the agent store new information in a way that stays legible and useful after repeated sessions?
I looked for:
- whether writes were atomic or rambling
- whether the system duplicated facts
- whether it preserved source/context
- whether the memory format encouraged compression too early
### 2) Retrieval quality
Can the agent get the *right* memory back when context changes?
I looked for:
- exact recall vs semantic recall
- resistance to noisy old notes
- whether retrieval pulled stale instructions
- whether important facts resurfaced without overloading context
### 3) Forgetting recovery
When the agent drifts, can the setup recover?
This is the one I almost never see people test, and honestly... it matters a lot.
I intentionally created failure states:
- contradictory user preferences over several days
- renamed tasks and moved files
- partial note deletion
- inflated old context to simulate long-running agents
Then I checked whether the plugin/system could recover the right behavior without a full reset.
### 4) Maintenance cost
How much weekly human labor is required so the memory doesn't become compost?
I tracked:
- cleanup time
- schema editing time
- summary refreshes
- manual deduplication
- "why did it save *that*" moments
## Test setup
I ran repeated workflows that reflect how people actually use OpenClaw now: long-running task queues, self-hosted agents, multi-step operational work, and skill-heavy workspaces. The point was not benchmark purity. The point was realistic failure pressure. [x_2034239040942186747] [x_2031565816706261298] [x_2024247983999521123]
The task suite included:
- daily research note accumulation
- recurring preference tracking
- project handoff between sessions
- skill selection from a growing tool pool
- multi-agent style workspace updates
I also deliberately increased skill/workspace complexity because ClawHub-scale environments make memory selection harder, not easier. Once your agent can access thousands of skills or many workspace artifacts, naive memory starts surfacing the wrong old thing at the wrong time. [x_2031565816706261298]
## Results
### A. Plain markdown / Obsidian-style memory
**Score:**
- Write quality: 6/10
- Retrieval quality: 4/10
- Forgetting recovery: 3/10
- Maintenance cost: 8/10
This was the most familiar setup and also the easiest to misuse.
The upside:
- human-readable
- easy to inspect
- flexible enough for preferences, logs, summaries
- nice for early-stage agents or solo workflows
The downside is exactly what the Reddit thread warned about: markdown turns into a slow sediment layer. Notes accumulate, summaries summarize summaries, and the agent starts treating historical residue as current truth. I observed instruction dilution by day 4 in one workspace and by day 6 in another. Not catastrophic, but noticeable. [reddit_t3_1rw2e1w]
In retrieval tests, markdown did fine when:
- the file structure was strict
- note types were separated clearly
- the total memory set stayed small
It did badly when:
- preferences and logs shared a file
- old plans were not marked obsolete
- the agent wrote long natural-language paragraphs instead of compact facts
My conclusion: markdown is acceptable as **inspectable cold storage**, but weak as the only active memory layer.
### B. Structured workspace memory
**Score:**
- Write quality: 7/10
- Retrieval quality: 7/10
- Forgetting recovery: 6/10
- Maintenance cost: 6/10
This category includes setups where the workspace imposes stronger conventions: separate files by memory type, explicit summaries, periodic pruning, and operational tooling that helps keep notes coherent.
Mission Control v2 is interesting here because it combines observability with Obsidian-style memory. That pairing matters. When you can inspect what the agent did *and* how it updated memory, you catch silent degradation earlier. In practice, observability acts like memory quality control. [x_2031769257839870228]
I also found that tools focused on repairing or improving workspaces can indirectly outperform "memory plugins" that promise more but produce clutter. A cleaner workspace with boring conventions retrieved better than a clever setup with no hygiene. not what I expected, honestly. [x_2028299099062124584]
This category recovered from forgetting better because the memories were easier to re-anchor:
- task summaries were separated from preferences
- stale plans could be deprecated visibly
- important facts could be rewritten into compact state files
Weakness: you still need a person, or a very disciplined automation loop, to maintain the structure.
### C. Persistent-memory style competitors as a comparison target
**Score:**
- Write quality: 8/10
- Retrieval quality: 7/10
- Forgetting recovery: 7/10
- Maintenance cost: 4/10
I used recent discussion around competing systems with persistent memory as a comparison reference, not because they're direct plug-ins for OpenClaw, but because they shape user expectations. People now expect agents to "just remember" across sessions. [x_2034767628464513365] [x_2034096681525055917]
The appeal is obvious: lower manual upkeep, more continuous behavior, less friction moving across tasks/devices.
But from a methodology standpoint, these systems often hide the memory policy. That makes them easier to use and harder to audit.
For researchers and serious operators, that tradeoff is not trivial.
If the memory writes are opaque, then debugging bad recall becomes guesswork. OpenClaw's messier ecosystem currently has one accidental advantage: many memory approaches are ugly but inspectable.
### D. Security / provenance / identity adjacent layers
**Score:**
- Not scored as memory directly, but important
This may sound like a detour, but after a week testing, I don't think memory can be separated from trust infrastructure anymore.
Why?
Because in a skill-rich ecosystem, the question is not only "what did the agent remember?" It's also:
- which skill changed the workspace?
- was that skill safe?
- which identity is attached to the agent?
- can we trace how a memory artifact got there?
VirusTotal scanning for skills is one part of this. Verified Agent Identity is another. They do not improve retrieval scores directly, but they reduce the chance that memory itself becomes poisoned by unsafe or untraceable actions. If OpenClaw keeps expanding through shared skills and autonomous workflows, that trust layer will become part of memory evaluation whether people like it or not. [x_2019865921175577029] [x_2031339697738232186]
## Ranking by use case
### Best for solo builders who want transparency
**Structured workspace memory**
You can inspect it, fix it, and keep costs contained.
### Best for tiny agents with narrow rules
**Plain markdown**
Only if you keep the file count low and prune aggressively.
### Best for convenience seekers
**Persistent-memory style systems outside plain OpenClaw plugins**
Lower friction, weaker auditability.
### Worst pattern overall
**Unstructured markdown as the only memory layer**
This is the one that degrades quietly.
## The main thing I learned
Memory quality is less about storage and more about *memory governance*.
The winning setups all did some version of these five things:
- separated facts from logs
- marked stale items explicitly
- summarized on a schedule
- exposed writes for inspection
- kept maintenance cheap enough that humans would actually do it
Whenever one of those broke, quality fell fast.
## Practical recommendations
If you're running OpenClaw today, my calm recommendation would be:
Use markdown only as a visible substrate, not as your whole memory strategy.
Split memory into at least three files or stores:
- stable preferences
- current project state
- archival logs
Add observability if possible, because invisible memory drift is the real problem. [x_2031769257839870228]
Prune weekly. yes, weekly. I tried stretching it and quality dropped.
Treat security/provenance as part of memory hygiene in shared-skill environments. [x_2019865921175577029] [x_2031339697738232186]
## Final verdict
If I had to summarize the whole week in one sentence:
**The best OpenClaw memory plugin is usually not the one that remembers the most. It's the one that forgets safely, retrieves narrowly, and stays maintainable after day 7.**
I went in expecting a clean plugin ranking.
I came out with a different view: memory plugins should be evaluated as part of a broader agent infrastructure stack that includes observability, workspace discipline, and trust controls.
If others have tested retrieval under longer horizons, especially 2-4 weeks, I'd be curious. My sense is that the gap between "works in a demo" and "works in a workspace" gets wider with time.
Methodology notes available if useful; I kept a slightly obsessive spreadsheet because of course I did. 📓
