memory-lancedb-pro: a LanceDB memory plugin for OpenClaw agents

The amnesia problem memory-lancedb-pro targets

OpenClaw agents start every session with an empty context. A user who says "use tabs for indentation, always add error handling" in one conversation has to say it again in the next one, and again after that. The README frames this as the core motivation: most agents "forget everything the moment you start a new chat." The plugin's job is to capture the durable parts of a conversation, store them, and inject the relevant ones back into the prompt before the agent replies. The intended audience is someone already running OpenClaw who wants that recall without hand-tagging entries or writing memory_store calls into their own prompts. The README describes the plugin as a "production-grade long-term memory plugin" and lists the pieces: auto-capture, LLM-based extraction into six categories (profiles, preferences, entities, events, cases, patterns), a Weibull decay model for forgetting, hybrid retrieval, context injection, and per-agent, per-user and per-project scoping. That is a lot of surface area for one plugin, and the sections below take the claims apart.

Two stores, one slot: how the memory architecture actually splits

The README is explicit that when memory-lancedb-pro takes the OpenClaw memory slot, it exposes one capability backed by two coordinated stores. The first is plugin memory in LanceDB, a vector store queried through memory_recall and auto-recall. The second is the canonical corpus: MEMORY.md, files under memory/**/*.md, recent session transcripts, and memory/dreaming/**/*.md. Those files stay the source of truth. LanceDB holds a semantic index over them, and the README states that recall through the index only happens when canonicalCorpus.enabled is true. That split matters because it means the plugin is not the only writer of your memory. If you edit MEMORY.md by hand, you are editing the source of truth, and the index is a derived view. Retrieval itself is hybrid: vector search plus BM25 full-text search, fused and then reranked with a cross-encoder. The README does not publish a fusion weight, a rerank model name, or a latency figure, so treat the ranking behaviour as something to observe on your own corpus rather than something the documentation pins down. Scope isolation is the other structural piece. Memories are partitioned per agent, per user and per project, which is what keeps two projects from bleeding preferences into each other.

Installing memory-lancedb-pro and storing your first memory

Before any install command, check the CPU. The README warns that LanceDB native vector search may require AVX2 on some Linux x64 builds and can crash AVX-only CPUs with SIGILL. The documented check is a single grep against /proc/cpuinfo. No output means AVX is not supported.

grep -o 'avx[^ ]*' /proc/cpuinfo | head -1

If the machine cannot run the native path, the README gives two ways to fall back to a scoped row scan plus JavaScript cosine ranking: set retrieval.disableNativeCosine to true in the plugin config, or set the MEMORY_LANCEDB_DISABLE_NATIVE_COSINE environment variable to 1. The README points at issues #419 and #644 for the details.

The recommended install path is the community setup script, which the README says handles install, upgrade and repair in one command.

curl -fsSL https://raw.githubusercontent.com/CortexReach/toolbox/main/memory-lancedb-pro-setup/setup-memory.sh -o setup-memory.sh
bash setup-memory.sh

If you prefer the OpenClaw CLI, the documented command installs the beta tag. The npm route is npm i memory-lancedb-pro@beta, and the README flags the most common setup problem with it: you must add the plugin's install directory as an absolute path under plugins.load.paths in openclaw.json.

openclaw plugins install memory-lancedb-pro@beta

Configuration goes in openclaw.json. This is the shape the README gives, with the memory slot pointed at the plugin and auto-capture, auto-recall and smart extraction enabled.

{
  "plugins": {
    "slots": { "memory": "memory-lancedb-pro" },
    "entries": {
      "memory-lancedb-pro": {
        "enabled": true,
        "config": {
          "embedding": {
            "provider": "openai-compatible",
            "apiKey": "${OPENAI_API_KEY}",
            "model": "text-embedding-3-small"
          },
          "autoCapture": true,
          "autoRecall": true,
          "smartExtraction": true,
          "canonicalCorpus": { "enabled": true, "syncOnSearch": true },
          "extractMinMessages": 2,
          "extractMaxChars": 8000,
          "sessionMemory": { "enabled": false }
        }
      }
    }
  }
}

The README explains why these defaults were chosen: extractMinMessages at 2 triggers extraction in ordinary two-turn chats, and sessionMemory.enabled false keeps session summaries out of retrieval on day one. After upgrading, the release notes for v1.1.0-beta.10 say to run openclaw doctor --fix. That release also moved the plugin onto the before_prompt_build hook, replacing the deprecated before_agent_start, which is the change that makes OpenClaw 2026.3 or later a requirement.

The AVX constraint is the failure mode to take seriously

The README spends more space on CPU compatibility than on any other limitation, and that is the right emphasis. On an AVX-only Linux x64 machine, the native vector search path can terminate the process with SIGILL rather than degrade gracefully. The documented escape hatch is retrieval.disableNativeCosine or MEMORY_LANCEDB_DISABLE_NATIVE_COSINE=1, which swaps native cosine for a scoped row scan plus JavaScript ranking. That fallback is a different performance profile by construction, and the README gives no numbers for either path. Two other constraints are worth naming. First, the plugin is published under a beta tag: the install commands in the README target memory-lancedb-pro@beta, and the most recent releases listed are v1.1.0-beta.10, beta.9 and beta.8. If your policy is stable tags only, this is not that. Second, the OpenClaw 2026.3 hook change means an older OpenClaw release is the wrong host. This is also the wrong tool if you want a memory layer with no native dependency at all. LanceDB is the storage engine, and the AVX requirement comes with it; a plugin built on a pure-JavaScript store would sidestep the SIGILL case entirely.

How it compares to a plain memory-lancedb setup

The search data shows people comparing memory-lancedb-pro against memory-lancedb, and the package name itself signals the difference. The pro plugin adds a retrieval stack on top of vector search: BM25 full-text search fused with the vector results, then cross-encoder reranking, plus the canonical corpus index and the multi-scope isolation. A plain vector-only memory plugin retrieves by embedding similarity alone, which tends to miss exact strings such as a flag name, a file path or an error code that BM25 catches directly. The trade-off runs the other way too. Every additional stage is another component to configure and another place for ranking to behave unexpectedly, and the pro plugin's config surface is correspondingly larger: embedding provider, auto-capture, auto-recall, smart extraction, canonical corpus sync, dreaming, extraction limits and session memory. If your recall needs are simple and your corpus is small, the extra layers buy you less than they cost in setup. The plugin also accepts any OpenAI-compatible embedding endpoint, and the README names OpenAI, Jina, Gemini and Ollama, so the embedding provider is not a lock-in point.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-08-29. The release cadence visible in the changelog is rapid and beta-tagged: three beta releases between 2026-03-12 and 2026-03-23, with the package.json sitting at 1.1.0-beta.11. That cadence is the upgrade cost. The v1.1.0-beta.10 release notes describe a hook migration that requires OpenClaw 2026.3 or later and a follow-up openclaw doctor --fix, which is exactly the kind of change that forces you to read release notes before bumping. The README also mentions backup, migration, upgrade and export/import tooling, and the repository ships a CLI entry point at cli.ts plus a scripts directory, so there is a documented path for moving data rather than hand-editing stores. On licensing: package.json declares MIT and the README carries an MIT badge, while the repository metadata available here leaves the licence field unknown. Check the LICENSE file in the repository before you rely on either. Nothing in the README addresses commercial support, warranty or indemnity, and this is not legal advice.

Editorial conclusion

Adopt memory-lancedb-pro if you run OpenClaw 2026.3 or later, want preference and decision recall without calling memory_store by hand, and can confirm your CPU exposes AVX (and AVX2 on Linux x64) before installing. Skip it if you are on an older OpenClaw release, if you need a plugin that is not published under a beta tag, or if you want a memory layer that does not depend on LanceDB's native binaries. Verify three things first: your CPU flags with grep -o 'avx[^ ]*' /proc/cpuinfo | head -1, that openclaw doctor --fix runs clean after the upgrade, and whether canonicalCorpus.enabled should stay true in your openclaw.json.

Frequently asked questions

Official sources

1. CortexReach/memory-lancedb-pro on GitHub
2. Issues
3. Project website
4. README
5. Releases