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.
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).
171 remaining items
dezren39 commentedon Nov 3, 2026
agent-note:v1
event: parked
task: 5001 (repo-health-code-pilot; worker repo-worker-code; OpenChamber scheduled lane 8ac61616-3815-4e7b-b33d-840a3829154a)
state: parked until 2026-11-03T10:35:08Z.
blocker: Laptop load 40.03/31.90/23.93 on 16 cores (heavy rustc builds in fleet worktrees 5874 + probe-laneB-scan16); openclaw-gateway and openclaw-embedding inactive. Unsafe window for gateway memory round-trip.
resume: In a low-load window, retry authenticated memory.status and explicit memory store/recall round-trip; then document final evidence and rollback on #1300 without closing it. Full HM activation separately noted blocked by pre-existing opencode-node_modules FOD hash mismatch.
labels: queue/parked + status/parked; work/assigned retained.
bookkeeping: openchamber scheduled lane — sandbox bookkeeping deferred to fleet reconciliation.
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.