memory-lancedb-pro: a LanceDB memory slot for OpenClaw agents
Enhanced LanceDB memory plugin for OpenClaw — Hybrid Retrieval (Vector + BM25), Cross-Encoder Rerank, Multi-Scope Isolation, Management CLI
At a glance
- What is it?
- This plugin takes over the OpenClaw memory slot and stores preferences, decisions and project context in LanceDB, recalling them through hybrid vector plus BM25 search with a cross-encoder rerank. It is a beta-stage beta.10 release with an AVX2 caveat that can crash older x64 CPUs.
- Who is it for?
- Adopt it if you run OpenClaw 2026.3 or later, your CPU reports avx2 in /proc/cpuinfo, and you want the memory slot filled by a store you can inspect with an export command. Do not adopt it if you are pinned to an OpenClaw version before 2026.3, since the release notes describe the beta.10 line as a hook adaptation and the README tells you to run openclaw doctor --fix after upgrading.
- Can I use it commercially?
- Not without permission. GitHub finds no licence file in the repository, and without a licence all rights are reserved by default: you may read the code but not reuse it. Check the README, or ask the authors, before using it.
- Is it still maintained?
- Yes. The repository last received commits 3 days ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The amnesia problem this plugin is aimed at
OpenClaw agents start each session without the preferences and decisions from the last one. The README frames this as the core failure: a user says "Use tabs for indentation, always add error handling", and in the next session says it again. The plugin's answer is to capture those statements automatically, classify them, and inject the relevant ones back before the agent replies.
The intended user is someone running OpenClaw in a recurring project context, not a one-off chat. The README's own example is a design decision ("Why did we pick PostgreSQL over MongoDB last month?") that only makes sense if the agent has been present across weeks. If your sessions are independent and short-lived, the capture and recall machinery has nothing to work on.
The plugin occupies the memory slot in OpenClaw's plugin configuration. That is a positional commitment: only one plugin can hold that slot, so installing this one displaces whatever memory handler you had. The README's architecture section makes the ownership explicit and describes two coordinated stores rather than one.
Two stores, one recall path
The README describes a two-layer arrangement. Plugin memory lives in LanceDB as a vector store and answers memory_recall calls and automatic recall. A separate canonical corpus covers MEMORY.md, files under memory/**/*.md, recent session transcripts, and memory/dreaming/**/*.md. The stated principle is that canonical files remain the source of truth and LanceDB is the semantic index over them, reachable when canonicalCorpus.enabled is true.
That split is the most interesting design decision in the project, because it means the vector store is not authoritative. If the index and the markdown disagree, the markdown wins by the project's own statement. The syncOnSearch flag appears alongside enabled in the sample config, which suggests the corpus is refreshed as searches happen rather than only at write time. The README does not spell out the reconciliation rules, so how deletions in the corpus propagate to the index is something you would have to confirm in the source.
Retrieval itself is described as hybrid: vector search plus BM25 full-text search, fused, then passed through a cross-encoder rerank. The README lists this under Hybrid Retrieval without giving fusion weights, candidate counts, or the rerank model. Those numbers are not in the supplied material, so treat the retrieval quality as unquantified until you read the config schema.
Capture, extraction and the forgetting model
Auto-capture is on by default in the sample configuration. The agent records what it judges to be worth keeping without a manual memory_store call. Extraction is described as LLM-powered classification into six categories: profiles, preferences, entities, events, cases, patterns. Two config keys govern when it fires: extractMinMessages, set to 2 in the sample, and extractMaxChars, set to 8000. The README explains the first choice directly, saying extraction triggers in normal two-turn chats.
Forgetting uses what the README calls a Weibull decay model, with the claim that important memories stay and noise fades. No decay parameters, half-life values or scoring formula appear in the material, so the practical effect of that model is not something I can state. What is clear is the intent: an unbounded auto-capture store grows without limit, and decay is the mechanism proposed to stop recall from drowning in it.
A dreaming feature exists in the config with enabled set to false by default, and a memory/dreaming/**/*.md path is listed under the canonical corpus. The README does not explain what dreaming does beyond the path and the flag, so leaving it off is the documented starting position rather than a judgement about its usefulness.
Installing it and the config keys that matter
The recommended path is the community setup script, fetched and run in two commands:
curl -fsSL https://raw.githubusercontent.com/CortexReach/toolbox/main/memory-lancedb-pro-setup/setup-memory.sh -o setup-memory.sh bash setup-memory.sh
The manual path is either openclaw plugins install memory-lancedb-pro@beta or npm i memory-lancedb-pro@beta. The README warns about the npm route specifically: you must add the plugin's install directory as an absolute path in plugins.load.paths in openclaw.json, and it calls this the most common setup issue.
The configuration block sets plugins.slots.memory to memory-lancedb-pro, then enables the entry. The keys that change behaviour most are embedding.provider (openai-compatible in the sample, with apiKey read from ${OPENAI_API_KEY} and model text-embedding-3-small), autoCapture, autoRecall, smartExtraction, canonicalCorpus.enabled and canonicalCorpus.syncOnSearch, extractMinMessages, extractMaxChars, and sessionMemory.enabled. The README's stated reason for sessionMemory.enabled being false is to avoid polluting retrieval with session summaries on day one. The provider list in the feature table covers OpenAI, Jina, Gemini, Ollama and any OpenAI-compatible API, so the embedding endpoint is not locked to one vendor.
The AVX2 crash is the first thing to check
The README puts a CPU requirement at the top of Quick Start, which is unusual placement and worth reading as a signal. LanceDB's native vector search may require AVX2 on some Linux x64 builds. On a CPU that supports AVX but not AVX2, the README says it can crash with SIGILL. The check is:
grep -o 'avx[^ ]*' /proc/cpuinfo | head -1
No output means AVX is absent. The documented workaround is to set retrieval.disableNativeCosine to true or the environment variable MEMORY_LANCEDB_DISABLE_NATIVE_COSINE=1, which switches to a scoped row scan with JavaScript cosine ranking. That fallback is a different performance profile by construction: a row scan plus JS ranking versus a native vector index. The README does not quantify the difference, and I have not measured it.
This is the clearest case where the plugin is the wrong tool. If you are deploying to heterogeneous x64 hardware you do not control, or to a container platform where CPU flags vary by node, you are choosing between a crash and a degraded retrieval path. A memory plugin that takes down the agent process is a worse outcome than an agent that forgets.
Multi-scope isolation and who shares what
The plugin advertises multi-scope isolation: per-agent, per-user, per-project memory boundaries. The README lists it as a feature but does not show the config keys that define a scope, nor how a scope is resolved at recall time. That gap matters more than it first appears. Isolation boundaries are the part of a memory system where mistakes are expensive, because a mis-scoped recall leaks one project's decisions into another project's prompt.
What the material supports is the claim that boundaries exist. What it does not support is a statement about how they are keyed, whether a scope can be shared deliberately, or what happens when an agent moves between projects. If you plan to run one OpenClaw instance across several client projects, that is the section of the source you should read before trusting the default.
The management CLI is the counterweight here. The feature table lists backup, migration, upgrade, and export/import as part of the toolkit. An export command turns isolation from a promise into something you can inspect: you can dump a scope and read what is in it. The README does not give the CLI's subcommand syntax, so the exact invocation is not something I can quote.
Where a plain markdown memory file wins
The obvious alternative is the canonical corpus on its own: MEMORY.md and files under memory/**/*.md, read directly, with no vector index and no embedding provider. The plugin's own architecture section concedes that those files are the source of truth. The difference in approach is retrieval. A markdown file is loaded whole or grepped; it has no semantic ranking, no BM25 fusion, no rerank, and no decay model. It also has no embedding cost and no AVX2 dependency, and it cannot return a wrong memory because a similarity score crossed a threshold.
The honest split is corpus size. A few hundred lines of project conventions fit in a prompt or a grep and gain little from a vector store. Once the corpus spans months of transcripts and dozens of decisions, whole-file loading stops fitting and ranked retrieval starts earning its cost. The plugin's auto-capture default pushes you toward the second regime whether or not you have reached it, which is why sessionMemory.enabled is false in the sample: the authors are trying to keep the first-day index narrow.
The other real difference is operational. A markdown file has no process to crash, no native library to match against your CPU, and no API key to rotate. You are trading that for semantic recall. Whether the trade is worth it depends on how often you actually ask the agent about a past decision.
Beta status, licence and upgrade cost
Every release in the supplied list is a beta: v1.1.0-beta.8, beta.9 and beta.10, spanning March 2026. The install commands target memory-lancedb-pro@beta explicitly, so the beta channel is the documented one. The beta.10 release notes describe an OpenClaw 2026.3+ hook adaptation, replacing the deprecated before_agent_start hook with before_prompt_build, and the README instructs you to run openclaw doctor --fix after upgrading. That is a concrete upgrade step, and it implies the plugin's compatibility surface tracks OpenClaw's plugin architecture rather than being independent of it. Pin your OpenClaw version or expect to re-run doctor on upgrades.
On licence: the README carries an MIT badge and links to a LICENSE file, but the repository metadata supplied here lists the licence as unknown. A badge is not a licence grant. Before you depend on this in anything you ship, open the LICENSE file and confirm the terms yourself. I am not giving legal advice, and MIT versus an unstated licence changes what you can do with the code.
Maintenance cost is the part the material supports least. The repository shows a last push in August 2026 and beta releases through March 2026, with a gap between them that I cannot explain from the supplied facts. There is no stated support window, no compatibility matrix beyond the 2026.3+ badge, and no deprecation policy for config keys. Budget for reading release notes before each upgrade, and for the possibility that a hook rename, as happened between before_agent_start and before_prompt_build, breaks recall silently rather than loudly.
Editorial conclusion
Adopt it if you run OpenClaw 2026.3 or later, your CPU reports avx2 in /proc/cpuinfo, and you want the memory slot filled by a store you can inspect with an export command. Do not adopt it if you are pinned to an OpenClaw version before 2026.3, since the release notes describe the beta.10 line as a hook adaptation and the README tells you to run openclaw doctor --fix after upgrading. Before installing, verify three things: that the repository states an explicit licence rather than only a badge, that your embedding provider key is reachable from the process that loads openclaw.json, and that you are comfortable with autoCapture defaulting to true on a store that writes into your project's memory directory.
Community notes