OpenClaw memory search

Vector + FTS index over agent memory files — the subsystem behind memory_search, managed by the openclaw memory CLI.

Goals

Semantic recall over MEMORY.md and memory/*.md across six agents. Dogfooded 2026-07-29 by way of a failure: every session for days had opened with "memory search is currently paused (index built with a different embedding config)," and Gavin finally asked why the note kept recurring.

Effectiveness

Adequate. The engine itself is fine — one rebuild command restored all six agents' indexes in seconds, and FTS kept answering the whole time vector search was down. The failure UX around it is what earned days of a broken index.

What the issue actually was

Two issues, one technical and one procedural:

1. Stale index, missing identity metadata. The main agent's index predated the current embedding config, and memory status reported Index identity: index metadata is missing. OpenClaw responds by pausing vector search until a rebuild — safe, but silent about degradation since FTS keeps working.
2. The nag loop had no actor. The housekeeping note re-surfaced at the start of every session with the fix command included, the agent relayed it to Gavin daily, and nobody — human or agent — ever ran the command. The note was re-reporting the same unfixed state, not a fresh breakage. Fixed in one command the moment someone actually executed it.

What made it effective

• openclaw memory index --force rebuilt every agent's index (main, coding, artemis, throuple, researcher, qwen-coder) in one shot, seconds, exit 0.
• openclaw memory status is a genuinely good diagnostic screen: per-agent provider, files/chunks indexed, dirty flag, vector dims, FTS state, cache stats.
• Graceful degradation: FTS stayed live while vectors were paused, so recall never went fully dark.

Friction / pain points / surprises

A daily nag that never self-heals. The rebuild is safe and idempotent — the system could just run it. Instead it emitted the same note every session indefinitely. A warning with a known-safe remedy and no auto-repair (or at least no escalation after N repeats) trains everyone to read it as weather.

Two different fix commands for the same fault. The housekeeping note says openclaw memory index --force; memory status says openclaw memory status --index --agent main. Both work, but a rebuild spelled as a flag on a status command is a surprise, and the disagreement invites hesitation — plausibly part of why the fix sat unrun.

Two different diagnoses too. The note blames "a different embedding config"; status says "index metadata is missing." Same fault, two stories.

The real lesson is agent-procedural. Any housekeeping note carrying a concrete safe command should be executed in-session, not narrated. This is now standing policy in agent memory.