Memory System

How OpenClaw stores and uses memories

OpenClaw's memory system stores conversations, context, and information as files in your workspace. This file-based approach means you can read, edit, search, and version control your memories just like any other files.

How Memory Works

OpenClaw stores memories as Markdown files:

  • Daily Notes - Automatic daily memory files
  • Conversation History - Stored in session files
  • Context - Loaded automatically when needed
  • Editable - You can read and modify memory files directly

Memory Storage

Memories are stored in your workspace (~/.openclaw/workspace by default):

  • Daily Notes - ~/.openclaw/workspace/YYYY-MM-DD.md
  • Sessions - ~/.openclaw/workspace/sessions/
  • Memories - Organized by date and topic

Daily Notes Format

Daily notes are created automatically:

Example Daily Note 
# 2026-01-25

## Conversations
- Discussed project ideas with user
- Helped with configuration setup

## Important Information
- User prefers dark mode
- Workspace location: ~/projects

Memory Search & Embeddings

Memory search (finding relevant past context) may use embeddings. Depending on your setup, you may need to configure an embeddings model or API key in addition to your main LLM—it is not always enabled out of the box. OpenClaw supports several embeddings providers, including Voyage AI (native support). If memory search or “what the agent remembers” seems limited, check your configuration for embeddings provider settings. See Configuration and your provider’s docs for embedding options.

QMD & builtin (2026.2.21): With the QMD backend, per-agent memorySearch.enabled=false is respected at gateway startup; multi-collection searches run as per-collection queries. BM25-only search mode skips embed runs (e.g. memory index --force). The builtin backend avoids sync races on shutdown so onSearch/onSessionStart no longer fail with "database is not open" in ephemeral CLI flows. /status session summaries include cacheRead/cacheWrite for cache hit percentages.

RAG vs file-based memory

RAG (retrieval-augmented generation) usually means: chunk documents, embed them, store vectors, retrieve top‑k chunks per question, then answer from that slice. The memory system on this page leans on workspace files, notes, and context you curate—not necessarily a dedicated vector database.

Start with memory and skills

If you want the assistant to remember preferences and read a vault of notes, start with the patterns above plus skills. For a walkthrough, use personal knowledge base. Files are easy to grep, diff, and back up.

Add a full retrieval layer when…

  • You have large corpora (tens of thousands of chunks) where linear search or occasional web_fetch is too slow or too fuzzy.
  • Many clients hit the same document store and you need ranked retrieval with caching.
  • Compliance needs explicit retrieval boundaries (what text was in context for this answer) beyond today's markdown paths.

Then you typically run embeddings and a vector store next to the Gateway and expose search through tools or skills. Wire formats change—confirm in official docs before production.

Hybrid pattern

Keep memory files for identity and standing preferences, skills for repeatable procedures, and retrieval only for the big corpus (handbook, ticket archive, PDFs) so you do not pay an embedding bill on every chat turn.

For release-level embedding and API notes, see Releases and Memory management tutorial.

Memory Access

The agent automatically accesses memories:

  • Context Loading - Relevant memories loaded for conversations
  • Search - Agent searches memories when needed
  • Updates - Memories updated based on conversations

Manual Access

You can also access memories directly:

  • Read memory files with any text editor
  • Search with tools like Raycast or Obsidian
  • Edit memories directly
  • Version control with Git

Memory Features

Automatic Creation

  • Daily notes created automatically
  • Conversations recorded
  • Important information extracted

Context Persistence

  • Memories persist across sessions
  • Context maintained over time
  • Agent remembers your preferences

Searchable

  • Search memories with text tools
  • Agent searches automatically
  • Fast retrieval of relevant information

Managing Memories

Viewing Memories

View your memories:

  • Open workspace directory: ~/.openclaw/workspace
  • Browse daily notes
  • Check session files

Editing Memories

Edit memory files directly:

  • Open in any text editor
  • Make changes
  • Agent will use updated information

Searching Memories

Search your memories:

  • Use grep or text search tools
  • Use Raycast or Obsidian for advanced search
  • Agent searches automatically during conversations

Memory Best Practices

  • Let It Grow - More memories = better context
  • Review Regularly - Check daily notes periodically
  • Edit When Needed - Correct inaccurate information
  • Backup Workspace - Regular backups of memory files
  • Use Search Tools - Leverage search for finding information

Memory and Privacy

Memory files are stored locally:

  • Local Storage - All memories on your machine
  • No Cloud Sync - Never leaves your device
  • You Control - Read, edit, or delete anytime
  • Private by Default - Only you have access

Memory skills and integrations

OpenClaw’s built-in memory is file-based: daily notes, session history, and optional embeddings-based search. If you want structured long-term memory, automatic curation into a context tree, or higher-accuracy recall, you can add a community skill. ByteRover (on ClawHub) provides a memory skill with automatic memory flush at compaction, daily knowledge mining, and a context plugin that injects relevant context into prompts—see ByteRover’s OpenClaw integration docs. Browse Skills and ClawHub for other memory-related skills.

Related guides