Configure OpenClaw Memory Search: Improve Retrieval Accuracy

We’ve all been there—staring at a terminal, knowing the answer is buried somewhere in a markdown file you wrote weeks ago. Keyword search is great until you forget the exact term you used. That’s where memory_search comes in. It helps you find what you need even when your query doesn’t match your notes word-for-word.

It works by indexing your memory into small chunks. You can then search them using embeddings or keywords, and sometimes both.

Quick start

If you have an API key for OpenAI, Gemini, Voyage, or Mistral, you’re already set. Memory search works out of the box. If you want to be specific about which provider you use, you can set it in your config like this:

{
  agents: {
    defaults: {
      memorySearch: {
        provider: "openai", // or "gemini", "local", "ollama", etc.
      },
    },
  },
}

For those who prefer keeping everything on their own machine, use provider: "local". Just keep in mind this needs node-llama-cpp.

Supported providers

You have plenty of options depending on whether you want speed or local privacy.

Provider	ID	Needs API key	Notes
OpenAI	openai	Yes	Auto-detected, fast
Gemini	gemini	Yes	Supports image/audio indexing
Voyage	voyage	Yes	Auto-detected
Mistral	mistral	Yes	Auto-detected
Ollama	ollama	No	Local, must set explicitly
Local	local	No	GGUF model, ~0.6 GB download

How search works

OpenClaw doesn’t just pick one way to search. It runs two retrieval paths in parallel and merges the results:

flowchart LR
    Q["Query"] --> E["Embedding"]
    Q --> T["Tokenize"]
    E --> VS["Vector Search"]
    T --> BM25 Search"]
    VS --> M["Weighted Merge"]
    BM --> M
    M --> R["Top Results"]

• Vector search handles the meaning. If you search for “gateway host,” it knows you probably mean “the machine running OpenClaw.”
• BM25 keyword search is for the specifics. It’s perfect for finding exact IDs and error strings, or config keys.

If one path isn’t available (like no embeddings or no FTS), the other one runs alone.

Improving search quality

Two optional features help when you have a large note history:

Temporal decay

This makes older notes less important over time so recent info surfaces first. With the default 30-day half-life

{
  agents: {
    defaults: {
      memorySearch: {
        query: {
          hybrid: {
            mmr: { enabled: true },
            temporalDecay: { enabled: true },
          },
        },
      },
    },
  },
}