Repository navigation
Roadmap: vector memory for OpenClaw (memory-lancedb now, fleet vector store later?) #1300
Description
Roadmap: vector memory for OpenClaw — and possibly the fleet
Drew approved enabling memory-lancedb for the laptop OpenClaw (2026-10-26), and raised the open design question this issue tracks: does vector memory stay an OpenClaw-only store, or do we eventually incorporate our own vector store as an additional data source the agent can use more broadly?
Phase 1 (do now, small)
- Enable the
memory-lancedbruntime plugin inplugins.slots.memoryfor the laptop gateway, with a local embedding endpoint (the fleet already runs local llama.cpp embedding servers for OpenCode; check for a stable endpoint or stand one up — avoid per-instance dynamic ports). - Verify the official npm package name before wiring (two candidates surfaced in research:
@openclaw/memory-lancedbvs a third-party scope; the nix-openclaw catalog entrymemoryLancedbis the authority for what the module builds). - Confirm recall quality improves over the current degraded state (gateway logs vector-recall fallback warnings today).
Phase 2 (decide later, this issue)
- Should OpenCode sessions, OpenChamber, and other fleet agents share one vector store (e.g. the same LanceDB, or a served store) instead of each keeping their own?
- Data sources worth indexing beyond chat memory: the zettelkasten/Emanote notes, repo docs, prior research reports.
- Access pattern: MCP server vs per-tool native stores.
Notes
- Oh My OpenClaw's "Graphiti memory" was reviewed and not adopted (no such config exists in its reference; its persona/model-routing defaults also clash with fleet quota discipline). Cherry-picks only.
- Keep phase 1 reversible: memory slot swap is one config line.
Acceptance criteria
- Phase 1: memory-lancedb is enabled for the laptop OpenClaw gateway (plugins.slots.memory) using the verified official package (the nix-openclaw catalog entry memoryLancedb is the authority) and a stable local embedding endpoint — no per-instance dynamic ports.
- Phase 1 is verified live: the gateway starts, the memory plugin loads, and a store/recall round-trip works.
- The fleet question is answered on this issue with a recorded decision: OpenClaw-only store, or a fleet vector store as an additional agent data source — with the follow-up implementation issue filed if the fleet option is chosen.
Metadata
Metadata
Assignees
Labels
Large: multi-day or open-ended; expect staged check-insQuestion or design decision to resolveIntake review done: acceptance criteria, links, and normalized labels addedOrdinary priority (the default)Queue task is parked (waiting on CI, time, or an event)Filed directly by a humanDeliberately paused with a recorded resume conditionQueue or user escalation stateQueue worker lifecycle state
Activity
developing-today commentedon Oct 27, 2026
CODE-421
dezren39 commentedon Oct 27, 2026
Recon 2026-10-27 (amd): no Ollama installed and no fixed-port embedding endpoint exists today. The embedding servers are per-OpenCode-process llama.cpp children on dynamic ports (OpenChamber serve currently on 127.0.0.1:37621). So phase 1 needs one of: (a) a small dedicated fixed-port llama.cpp embedding service (Nix-managed user unit), or (b) endpoint discovery from the shared opencode serve once it stands up with a fixed port. Sequencing: after the shared-serve work in #1243.
dezren39 commentedon Oct 27, 2026
Intake review
Fleet monitor intake pass (protocol §5), 2026-10-27.
Still live: verified this run — issue is OPEN, no merged PR references or closes it (0 closing-PR references), and it was filed within the last day, so nothing has had time to supersede it.
Related: No linked implementation issue yet; the nix-openclaw catalog entry
memoryLancedbis the package authority named in the body.Notes / risks: This is Drew's open design question, so it lands in the user/review discussion lane alongside the Phase 1 enablement. Phase 1 itself is small; the effort/l covers the fleet-store decision tail. Risk: wiring the wrong npm package (two candidates surfaced) — verify against the nix catalog before any config change.
Suggested approach: Suggested approach: enable Phase 1 behind the verified package + stable embedding endpoint, verify recall, then bring the fleet-store question to Drew with the Phase 1 experience as evidence.
Labels normalized this pass; acceptance criteria appended to the body (original text preserved verbatim above it).
177 remaining items
dezren39 commentedon Nov 3, 2026
agent-note:v1
state: triaged (coverage pass)
Coverage pass 2026-11-03: reviewed in the fleet-wide per-issue pass (drift / overlap / already-handled / stale / blockers / ordering). Verdict: still live; queued in repo-health-code-pilot as triage at priority 40 (priority/normal). If this is already handled at current main, the triage closes it with evidence; if it needs splitting, the triage files the split.
Found via: coverage pass 2026-11-03
dezren39 commentedon Nov 3, 2026
🤖 Agent note · picked up → done (triage)
7b47536bqueue/parked/status/parkedfrom task 5001 with no live task)Verdict — phase 1 is implemented in config; live round-trip is the only open verification; phase 2 is Drew's decision
Phase 1 (config) — landed, on
mainin this repo.home/openclaw/default.nixenables thememory-lancedbruntime plugin, makes it ownplugins.slots.memory(slots.memory = "memory-lancedb"), and configures a fixed loopback embedding endpoint — a dedicated llama-server over the Qwen3-Embedding-0.6B GGUF withConditionPathExistsso a cleared cache fails loudly instead of silently losing recall. The plugin comes from the nix-openclaw catalog, which the issue names as the authority for the package, so the npm-name ambiguity is moot. Rollback remains one line, as intended.Live state today.
openclaw-gatewayandopenclaw-embeddingare bothactive. Host load is28.58 / 38.83 / 39.90on 16 cores. The last 400 journal lines for the gateway contain nomemory/lancedb/vector/embedentries, so there is no evidence here of a store/recall round-trip — the gate that task 5001 parked on (load) has improved but is still ~2× core count, and the authenticatedmemory.status+ store/recall check has still not been run and recorded.Phase 2 — genuinely Drew's. Whether the fleet shares one vector store (and which data sources — zettelkasten/Emanote, repo docs, prior research — plus MCP-server vs native-store access) is a roadmap architecture decision, not worker-discoverable from the codebase. Escalating that half to
user/escalated; my read is attached here.Ordering for the next packet. One small, live-smoke
small_fixlimited to: authenticatedmemory.status(plugin loaded, slot =memory-lancedb) and one explicit store→recall round-trip against the running gateway, recorded on this issue — no config changes, no fleet-store work. Phase 2 implementation must not start before that record exists and before Drew answers the fleet question.Labels. Removed the stale
queue/parked,status/parked,queue/queued,work/assignedandtask/triageleft by the parked run;user/review→user/escalatedfor the phase-2 decision. Issue stays open.dezren39 commentedon Nov 8, 2026
Partial verification — staying open (2026-11-07 done-task-only audit, tracking: #7016).
Queue task(s) [7678, 2542] were marked done, and some work did land:
No merged change closes this issue's full scope, so the done status is not treated as completion. Remainder re-queued as triage task 11562.
dezren39 commentedon Nov 8, 2026
🤖 Agent note · handed off
dezren39 commentedon Nov 8, 2026
🤖 Agent note · escalated
user/escalatedlabel — a decision reserved for Drew is already pending on this issue. The task is parked (not completed); the opencode claimant must revalidate the escalation fresh and must not work past it — if the escalation still stands, the correct disposition is to keep the task blocked/parked on the escalation, not to proceed with triage.