OpenClaw Memory Plugin: Choose with a Five-Test Gate

The safest default is not to install the most capable looking OpenClaw memory plugin. Start with the builtin backend, write down the requirement it cannot meet, and move only when a candidate passes five tests: persistence, retrieval, privacy, failure behavior, and recovery. That rule produces different choices for different problems. Use the builtin engine for a small local Markdown memory. Consider QMD when a large local corpus needs reranking or extra indexed directories. Consider memory lancedb when automatic capture and vector recall justify a native database dependency. Consider Honcho when automatic user modeling and cross session service backed memory are the actual requirement. Treat memory wiki as a companion knowledge layer, not as a replacement for the active memory backend. This article uses the OpenClaw 2026.7.1 2 documentation contract and an executable selection fixture. It does not claim that the fixture benchmarks retrieval quality. The point is narrower: reject an architecture whose operational boundary you cannot verify before it owns durable memory. First decide which layer you are replacing “Memory plugin” hides two different decisions. The active memory backend owns recall. OpenClaw's memory overview says that memory search and memory get come from the active memory plugin, with memory core as the default. Only one plugin owns that active memory slot at a time. Changing the slot changes a runtime dependency. A companion layer adds another representation without taking that slot. The bundled memory wiki compiles claims, evidence, provenance, dashboards, and wiki pages beside the active backend. Recall, indexing, promotion, and dreaming remain with the active memory plugin. Installing it to “improve search” is therefore the wrong decision if the real requirement is a replacement retrieval engine. The documented choices have materially different boundaries: Builtin stores a per agent SQLite index over MEMORY.md and memory/ .md . It supports keyword, vector, and hybrid search. The builtin engine documentation says keyword search remains available when no embedding provider is configured. It is the baseline because it adds no separate sidecar or service. QMD is a local first sidecar with BM25, vector search, reranking, query expansion, and extra directories. The QMD documentation also documents fallback to the builtin engine if QMD fails entirely. That fallback is a concrete operational advantage, not merely another feature. memory lancedb is an external plugin that owns the memory slot. Its official documentation describes auto recall, optional auto capture, an embedding dependency, per agent ownership, and a native @lancedb/lancedb package. The same page notes a platform limitation for Intel macOS and does not promise an automatic backend fallback. Honcho persists conversations to a dedicated service and builds user and agent models. The Honcho integration documentation supports managed or self hosted operation and says local Markdown memory can remain alongside it. The service, its retention boundary, and its availability become part of memory health. memory wiki is for provenance rich synthesis and maintained knowledge pages. It is a good answer to “How do we keep claims and sources inspectable?” It is not the answer to “Which active backend should own recall?” On the test host, openclaw version reported 2026.7.1 2 . openclaw plugins list json showed memory core bundled and loaded, memory wiki bundled but disabled, and neither LanceDB nor Honcho installed. That observation is not a universal recommendation. It illustrates why selection must begin with the current inventory rather than a marketplace screenshot. Run five tests with deliberately inconvenient cases A successful install only proves that a command completed. It does not prove that required memory survived, can be found, stayed private, degrades safely, or can be restored. 1. Persistence: name the durable owner Create a synthetic fact with a unique canary ID in a disposable test agent. Record where the source of truth lives, where the index lives, and whether a plugin stores a second copy. Restart the Gateway, rebuild the index if the backend requires it, and retrieve the canary. A pass needs all three facts: the source record still exists; the active backend reports a healthy index or connection; the canary is retrievable after restart. Do not use a real credential, customer name, or private conversation as the canary. A result that is merely still present in the current context proves nothing about persistence. 2. Retrieval: measure misses, not one lucky hit Build a tiny fixture with exact IDs, paraphrased decisions, two conflicting revisions, and one item that should not match. Test exact lookup, semantic lookup, recency, contradiction handling, and deletion. Record the expected source path or record ID before running the query. The reasonable default is deterministic acceptance: every required item is found, the stale revision does not outrank the current one, and the negative control stays absent. A demo query with one plausible answer cannot distinguish retrieval from coincidence. 3. Privacy: prove the isolation predicate Use two disposable agents and two canaries. Each agent should retrieve its own canary and fail to retrieve the other. Then inspect what leaves the host: which text is embedded; whether a hosted service receives raw messages or derived observations; where API credentials live; whether deletion removes source, index, and service copies; whether logs include memory content. The LanceDB documentation explicitly describes an owner predicate applied before vector ranking. Honcho deliberately moves conversations into a dedicated service unless self hosted. Those are different trust boundaries. Neither should be collapsed into a generic “supports privacy” checkbox. 4. Failure: interrupt the dependency Make the embedding provider unavailable, remove the sidecar from PATH in a test environment, or block the service endpoint. Then ask a query whose answer is known. The required outcome is not necessarily a correct answer. It is an honest state: available through a documented fallback, unavailable with a useful error, or degraded in a way the operator can see. Returning an empty result as though no memory existed is a false green failure. The documented boundaries matter here. Builtin search can retain keyword lookup without embeddings. QMD can fall back to builtin. A LanceDB native load or embedding failure needs its own handling. A service backed plugin adds network and service availability to the health envelope. 5. Recovery: restore, reindex, and verify Take a verified snapshot before migration. After the failure test, restore it into a disposable environment, rebuild any derived index, and rerun the retrieval fixture. Recovery passes only when expected items, ownership, deletion state, and the current revision agree. Useful read only probes depend on the selected path: QMD should expose whether the sidecar is ready or builtin fallback is active. LanceDB adds openclaw ltm stats . Honcho adds openclaw honcho status . Memory Wiki adds openclaw wiki doctor and openclaw wiki status . Run the relevant probe after recovery; do not infer health from process availability alone. What the executable gate actually selected The accompanying fixture encoded documented capabilities as hard requirements, then evaluated five profiles. Its result was: The output is useful because each choice also carries a fallback statement and a recovery probe. It is intentionally not a scorecard. Adding points for every feature would make the most complex candidate win even when the reader needs only durable local Markdown. The fixture also exposes an important boundary. memory wiki wins the provenance profile but remains outside the active backend lane. Honcho wins automatic user modeling but introduces a service boundary. LanceDB wins automatic local vector capture but introduces embedding and native package dependencies. QMD wins the large local corpus profile because reranking is required. Builtin wins the default because none of those extra requirements exist. You can reproduce the rule without trusting the conclusion: 1. List the requirement in observable terms. 2. Mark non negotiable privacy and platform constraints. 3. Reject candidates that cannot satisfy every hard constraint. 4. Prefer the surviving candidate with the smallest new failure surface. 5. Run the five tests against disposable data before migration. This is also where feature pages stop being sufficient evidence. The fixture is based on current documentation, not a shared retrieval benchmark. If two candidates survive, test both against your corpus, queries, latency budget, and failure modes. Unknown remains unknown. Keep rollback available until the new path proves itself A memory migration is not complete when records are copied. It is complete when the new backend retrieves the right current decision after restart, keeps agent boundaries intact, exposes failures, and can be rolled back without losing writes. Use a staged cutover: freeze the fixture, not the entire production memory; take a content snapshot and record its hash; populate the candidate in an isolated agent; run the five tests; shadow representative queries against old and new paths; classify disagreements before switching the active slot; keep the previous source intact through a stability window; remove the rollback path only after restore has been tested. Auto capture deserves special caution. It can reduce missed writes, but it also changes the ingestion boundary. Test whether transport metadata, injected context, secrets, and duplicates are rejected. Confirm which message types qualify, how deletion works, and whether a failed capture is visible. Convenience does not replace provenance. The same principle applies to fallback. QMD's documented builtin fallback preserves a search path, but the result quality and corpus coverage may change. That is a degraded state, not an automatic green. If the selected backend has no documented fallback, make unavailability explicit and retain a tested rollback. Use a release rule, not a favorite plugin Select the smallest architecture that satisfies the requirement and passes all five tests. Block migration when the durable owner is unclear, a required retrieval misses, cross agent isolation fails, an outage looks like “no memories found,” or the snapshot cannot be restored. That rule resolves the original question: Stay on builtin for the ordinary local case. Add QMD for local corpus scale, reranking, or extra paths. Choose LanceDB only when automatic vector memory is worth its embedding and native dependency. Choose Honcho when service backed cross session user modeling is the goal and its data boundary is acceptable. Add memory wiki when provenance rich knowledge compilation is required; do not mistake it for the active backend. Sidewisp is currently in private preview. It does not currently inspect, select, migrate, or recover OpenClaw memory backends. Its product direction is to make agent health evidence, uncertainty, and safe recovery boundaries visible; the five test gate above is a method you can use today without claiming that capability is shipped.