Better memory for OpenClaw.

The infrastructure is built for retrieval. Most local memory tools are SQLite and Markdown files under the hood. SQLite is great at what it was designed for, but it wasn't designed to be a search engine. dmem runs on Qdrant for semantic search and Elasticsearch for keyword and recency. Both are purpose-built for retrieval at scale, both are running on hosted infrastructure you don't have to manage, and both produce better results than anything you can run locally without becoming a part-time infra engineer.

An LLM does the thinking. Most memory systems are elaborate retrieval pipelines — chunking strategies, reranking layers, graph databases, fusion algorithms — built to compensate for the limits of classical retrieval. dmem skips all that. We run an LLM on our side that reads retrieval candidates and figures out what's actually relevant. When your agent queries dmem, you don't get a list of chunks back — you get an answer, synthesized by a model that read the candidates and picked the signal from the noise.

Better storage and retrieval, powered by LLM intelligence. We didn't build a smarter pipeline. We built a system that doesn't need one.

Hi. I'm Daren. I've been writing Python professionally for 20 years, with a focus on information retrieval and stints on the search teams at Yelp and eBay. For the last decade I've run a consumer product with millions of daily users entirely solo: frontend, backend, search infrastructure, payments, monitoring, 24/7 ops. Elasticsearch clusters that I built, scaled, and woke up at 3am for. Data-driven ranking algorithms I designed myself. The whole production stack, top to bottom.

dmem is what happens when that experience gets pointed at agentic AI memory.

It's a one-person operation, which means: I answer your email when something breaks. There's no roadmap committee. There's no acquisition risk. And the person running your memory infrastructure has been running production infrastructure — at scale, alone, under real load — for over a decade.

This is what a memory service looks like when someone who knows search builds it end-to-end.

Q: What happens to my memories if I stop using dmem?

Nothing. They're already on your machine.

dmem doesn't replace OpenClaw's memory system; it layers on top of it. The whole time you're using dmem, OpenClaw is also building its own summaries of your conversations in the background, exactly as it would without dmem installed. dmem just intercepts memory_search calls and returns better results.

When you uninstall dmem, OpenClaw resumes serving memory_search from its own memory, which has been quietly accumulating the entire time you were using us. You don't need to export anything. You already have a complete local copy.

That's also why there's no acquisition lock-in or shutdown risk: even if dmem disappeared tomorrow, your OpenClaw setup goes back to exactly how it would have worked if you'd never installed dmem in the first place.

Q: What does dmem store, and where?

When your agent calls memory_search, dmem receives the query and returns synthesized results. To do that, we store summarized versions of your conversations on our infrastructure (Qdrant for semantic embeddings, Elasticsearch for keyword/recency indexing) hosted on AWS in the US.

What we store: topic-chunked summaries of conversations your agent processes through dmem, plus the embeddings derived from them.

What we don't store: raw conversation transcripts (we summarize and discard), credentials, or anything from OpenClaw's other tools or internal memory.

Storage is on encrypted EBS volumes (AES-256, AWS-managed keys), which protects the underlying disk. Data is plaintext at the application layer because semantic and keyword search require it — your summaries are queryable by dmem's services, not encrypted blobs.

If you uninstall dmem, your stored memories remain on our servers. To remove them from our servers, use the Delete My Data tool.

Q: Should I use dmem if my data is sensitive?

Probably not, and here's what to use instead.

dmem is a hosted service. Your agent's conversations get summarized and stored on our infrastructure. That's a fine tradeoff for a lot of use cases — better retrieval, better synthesis, no ops work — but it's the wrong tradeoff if you're working with medical records, legal privilege, regulated enterprise data, or anything else that legally or ethically can't leave your environment.

For those cases, we recommend QMD — it's the best of the local-only OpenClaw memory plugins, runs entirely on your machine, and doesn't send anything anywhere. It uses SQLite + vectors instead of Qdrant + Elasticsearch, which means retrieval quality is more limited than dmem, but for sensitive workloads that's the right tradeoff.

dmem is built for the use cases where hosted infrastructure makes sense. If yours isn't one of them, use the right tool.

Q: How does dmem compare to other memory tools?

Two architectural differences worth knowing about, both intentional.

Many memory systems pre-process your messages. They intercept what you send to your agent, decide what context is relevant, and inject it before the model sees the prompt. dmem doesn't do that. We trust the LLM to call its memory_search tool when it needs memory, and we make sure the tool returns useful results. We've carefully prompted OpenClaw to actually use the tool and tested it extensively with Anthropic models (results may vary on other model families). The bet here is that as models get better at tool use, "let the model decide" beats "decide for the model." So far that bet is paying off.

dmem is slower than non-LLM-based memory systems, on purpose. Because we run an LLM on our side to synthesize results rather than just returning ranked chunks, queries take longer than systems that skip that step. The tradeoff is dramatically better answers, especially for queries where the relevant memory is spread across multiple conversations or requires synthesis to be useful. If your use case is extremely latency-sensitive, dmem might not be the right fit, and a faster, simpler memory tool will serve you better.

I use dmem every day on my own OpenClaw agent — it helps me manage a high-traffic website, so I'm trusting it with real production work. It's slightly annoying to wait for responses, and then extremely satisfying when the memory comes back and it's perfect.

Q: How do I uninstall dmem?

openclaw plugins uninstall dmem

That's it. Uninstalling removes dmem and restores OpenClaw's built-in memory. If you swapped in a different third-party provider before dmem, point the memory slot back at it:

openclaw config set plugins.slots.memory <provider>