Clawdbot handles persistent memory in a deliberately simple, local-first way: memory is written to disk, and disk is the source of truth. The agent does not “remember” anything magically—if something is not stored in the workspace, it is not durable. In the default design, memory is stored as plain Markdown files inside the agent workspace, which makes it inspectable, editable, and versionable using normal developer tools. This approach is practical for a personal assistant because you can open the files, see exactly what has been recorded, remove sensitive content, and understand why the assistant is recalling certain details. It also means persistence is robust across restarts: if the Gateway restarts, the memory files remain, and the assistant can rehydrate context by reading the relevant files again.
Under the hood, the default workspace layout typically uses two complementary layers. The first is a daily, append-only log (commonly one file per day, such as memory/YYYY-MM-DD.md) that captures what happened today in a chronological, low-friction way. The second is an optional curated file (often named something like MEMORY.md) meant for stable, long-term facts you explicitly want the assistant to reuse, and it is usually scoped more tightly (for example, loaded in a private, main session rather than group contexts). This layering solves a real problem: daily logs preserve raw detail without constantly rewriting a single giant file, while curated memory stays clean and intentional. Memory is also controlled through a plugin/slot mechanism: you can keep the default memory plugin, switch memory implementations, or disable memory entirely so the assistant behaves statelessly (useful for privacy-sensitive deployments). The key operational detail is that “persistent memory” is not only about what gets written, but also about what gets loaded at session start—many systems load a small window like today and yesterday’s files to avoid ballooning prompt size.
If you want persistent memory that works like “semantic recall” rather than file scanning, you typically add a retrieval layer. That’s where vector databases fit naturally, without forcing them into every use case. You can keep Markdown as the canonical audit trail while also building a derived index that supports fast “find relevant past context” queries. A common implementation is: write raw notes to the workspace, generate embeddings for selected entries, and store them in a vector database such as Milvus (self-hosted) or Zilliz Cloud (managed Milvus). Then, when a new message arrives, Clawdbot can retrieve the top-K similar memory chunks and feed them to the agent alongside the current conversation. This gives you practical benefits—better recall, less prompt bloat, and more control over retention—while keeping the privacy advantage of local-first files. You also gain developer-friendly controls: TTL policies on vectors, per-collection access keys, and the ability to delete a user’s embeddings without touching unrelated workspace files. In other words, Clawdbot’s persistent memory starts as readable Markdown on disk, and you can optionally add Milvus/Zilliz Cloud as a retrieval accelerator when your memory needs outgrow “search my notes.”