OpenClaw Local Only Memory Setup – Making Your Assistant Remember Better

This is the next installment in my running series on OpenClaw setup. One of the important ways in which OpenClaw setup can be a more useful personal assistant is by having more personalized and persistent memory about you, the things you care about and being able to retrieve them well based on context.

The memory system for an agent can be de-constructed into two parts:

• Storage
• Retrieval

In this post, we will go over how to build a robust, local-only, cost-effective memory storage + retrieval system for your OpenClaw Agent. Please note that while the memory storage, indexing and retrieval is local, retrieved values can still be sent to your actual configured model which can (and most likely should) be a cloud based model.

Storage

OpenClaw has a few different ways in which it stores memory for the agent (these are within a given workspace – for now, let’s assume that there’s only one workspace. We will cover the basic terminology of OpenClaw concepts in a different post). All these are stored as filesystem files under your openclaw working folder (typically $HOME/.openclaw for the user running the openclaw binary):

• workspace/MEMORY.md – This is a durable, selective and important set of facts. It can be injected into every prompt. Important to curate, keep it meaningful and short in order to avoid your token costs from blowing up.
• workspace/memory/YYYY-mm-dd.md – These are daily memory notes that OpenClaw makes to summarize key points of the conversation(s) for that day.
• agents/<agent-name>/sessions/<uuid>.jsonl – These are the session transcripts that contain the full back and forth conversations along with tool call trajectories, outputs etc. While technically not part of the memory system, these are stored and can be used as part of the memory system as shown below.

The one thing I noticed is that the summarization daily into YYYY-mm-dd.md memory notes is not consistently done. I ended up asking my agent to setup a cron job that runs at 1 AM every day to do this for the previous day and it has been more consistent since then. This is a common theme with OpenClaw – things kind of work, you have to work to make them resilient.

Retrieval

OpenClaw has a memory_search tool. However, by default, searching files for bits of information, ranking them and extracting snippets is expensive, error prone and hard to get right. In order to help with ranking and retrieval, we can use the embedding system to create embeddings for the corpus of “memories” (text files on the file system) and then allow the search, ranking and retrieval to operate through this embedding system.

Note that I stick with default built-in memory tool for OpenClaw. QMD is another supported option – but I prefer keeping my dependencies simpler and adding more complexity when warranted (or when I am bored enough or the change is interesting enough to explore). In this case, built-in memory from OpenClaw is the first stage I am exploring and keeping it simple there with a good baseline allows for more informed exploration of possible improvements down the line.

To create embeddings, we can use a text embedding model – in my case, I use the nomic-embed model – this is a very good model that can run on the CPU of my device (no need for GPU). If you need to create a CPU only version of the model, here’s how you can do it:

• ollama pull nomic-embed-text
• Create a new file MODELFILE.nomic-cpu:

FROM nomic-embed-text
PARAMETER num_gpu 0

• ollama create nomic-embed-cpu -f MODELFILE.nomic-cpu

Now, we have the necessary model for creating text embeddings. Next we configure OpenClaw to use this for semantic memory search which both keeps updating the embeddings and uses them to search. Note that we only use the built-in memory engine of OpenClaw (no QMD). Add the following to your openclaw.json:

{
  "agents": {
    "defaults": {
      "memorySearch": {
        "experimental": {
          "sessionMemory": true
        },  
        "sources": ["memory", "sessions"],
        "provider": "ollama",
        "fallback": "none",
        "model": "nomic-embed-cpu",
        "sync": {
          "onSearch": true,
          "watch": true,
          "sessions": {
            "deltaBytes": 50000,
            "deltaMessages": 20, 
            "postCompactionForce": true
          }   
        }   
      }   
    }   
  }
}

This sets up both memory and session log embedding creation + allows the memory_search tool to use these for improved recall and for your agent to act like it actually remembers what you talked about in the past as opposed to feeling like a smart amnesiac.

What Gets Better

By doing this, I am seeing improvements in:

• Cross session memory – now when I do /clear or /new, it does not feel like starting from scratch.
• Remembering and being able to recall from past conversations when nudged.
• Being able to remember personal preferences.