14 people on r/openclaw argued about memory and somehow they were all right

I ran into a small but very good thread on r/openclaw: “What do you use for memory?”.

It had 14 upvotes and 16 comments. Tiny by Reddit standards. But for a niche agent community, that’s enough to surface something real.

The short version:

simple file-based memory works for a lot of people. But once your agent needs to handle exact facts, searchable notes, summaries, and ambient ingestion from folders or work artifacts, you usually need more than one memory type.

My take after reading the whole thread:

• use files for identity
• use SQLite FTS5 for exact retrieval
• use vector search for fuzzy recall
• add summarization only when the incoming data volume actually justifies it

That sounds obvious after the fact. It’s not how most people build agent memory the first time.

The thread was really about trust boundaries

The original post mentioned Gbrain, Screenpipe, Letta, and OpenMemory.

That looks like a normal tool-comparison thread.

It wasn’t.

The real question underneath it was:

How do I give an OpenClaw agent memory without shipping my notes, docs, and personal context to a hosted service?

That’s why the answers got opinionated fast.

People weren’t debating abstractions. They were talking about local-first setups that they could inspect, move, back up, and trust.

For anyone building agents for real workflows, that matters a lot more than a slick memory demo.

The first camp: plain files and built-in memory are often enough

One of the best replies in the thread was basically:

Just stick with the basics and persist important stuff into a folder/file.

That’s not anti-technology. That’s anti-overengineering.

If your OpenClaw agent mostly needs:

• a stable identity
• a few persistent instructions
• some manually saved facts
• maybe a small amount of long-term context

then OpenClaw’s built-in memory core / memory_wiki plus markdown files is a solid answer.

Something as boring as this can carry a surprising amount of weight:

agent-memory/
├── IDENTITY.md
├── SOUL.md
├── AGENTS.md
├── MEMORY.md
└── notes/
    ├── client-a.md
    ├── lab-setup.md
    └── workflows.md

Why this works:

• it’s local
• it’s inspectable
• it’s easy to back up
• it fails in understandable ways
• it doesn’t invent “memory” from weak semantic matches

A lot of agent systems get worse when you automate memory too early.

Why the simple answer didn’t end the conversation

Because another commenter made the key point:

memory is not one retrieval problem.

That’s the whole thing.

People talk about “agent memory” like it’s a single feature. In practice, it’s several different jobs:

1. Identity memory — who the agent is, how it should behave
2. Factual memory — exact truths about users, systems, preferences, environments
3. Searchable notes — markdown, docs, prior summaries, logs
4. Semantic recall — “this feels related to that thing from last month”
5. Ambient ingestion — files flowing in automatically from watched folders or workflows
6. Compressed long-term context — summaries the model can actually consume efficiently

Once you split the problem this way, most memory debates get easier.

The reason people talk past each other is simple:

They’re solving different memory jobs with different failure tolerances.

SQLite vs vectors: exact truth vs fuzzy resemblance

The strongest technical point in the thread was this:

embeddings retrieve vibes, not values.

That’s harsh. It’s also mostly correct.

Vector search is great at:

• related concepts
• fuzzy matching
• thematic recall
• “find stuff like this”

Vector search is bad at:

• exact facts
• deterministic retrieval
• structured truth queries
• “what is the current value of X?”

If your agent needs to remember:

• a client wants invoices as PDF
• a Raspberry Pi is on 192.168.1.42
• a workflow should never trigger before 10 a.m.
• a user prefers Claude Opus 4.6 for planning and GPT-5.4 for tool use

then semantic similarity is not enough.

That’s where SQLite FTS5 earns its keep.

The practical split that actually makes sense

Memory approach	What it’s good at
OpenClaw built-in memory_wiki / markdown files	Identity, stable notes, manual persistence, low complexity
SQLite FTS5	Exact text lookup, fact retrieval, deterministic search across docs and notes
LanceDB or another vector store	Fuzzy recall, semantic search, related-item retrieval
Local summarization pipeline	Compressing incoming files, meetings, and artifacts into usable long-term context

If I had to reduce the whole thread to one sentence:

use files for identity, SQLite for facts, and vectors for fuzzy recall.

That stack is not trendy. It is, however, very hard to argue with.

A dead-simple local memory stack

If you want something practical, start here.

1) Keep identity in markdown

# IDENTITY.md
You are my local OpenClaw assistant.

Rules:
- Prefer concise answers.
- Ask before modifying production systems.
- Treat files under /clients as authoritative.
- Persist confirmed user preferences to MEMORY.md.

2) Index notes with SQLite FTS5

Create a local index:

CREATE VIRTUAL TABLE memory_index USING fts5(
  path,
  title,
  body,
  tokenize = 'porter'
);

Example rows might come from:

• IDENTITY.md
• SOUL.md
• MEMORY.md
• AGENTS.md
• docs/*.md
• notes/**/*.md

A simple query:

SELECT path, title
FROM memory_index
WHERE memory_index MATCH 'invoice AND PDF';

That gives you exact-ish lexical retrieval without pretending it’s reasoning.

3) Add a file ingester

You can wire up a tiny ingestion script in Node.js:

import Database from 'better-sqlite3';
import fs from 'fs';
import path from 'path';

const db = new Database('memory.db');

const files = [
  'IDENTITY.md',
  'SOUL.md',
  'MEMORY.md',
  'AGENTS.md'
];

for (const file of files) {
  const body = fs.readFileSync(file, 'utf8');
  db.prepare(`
    INSERT INTO memory_index (path, title, body)
    VALUES (?, ?, ?)
  `).run(file, path.basename(file), body);
}

Is this glamorous? Not even slightly.

Is it debuggable? Extremely.

What the more advanced builders were doing

The thread got more interesting when people described actual local stacks.

The SQLite FTS5 setup

One commenter described a custom SQLite FTS5 setup using better-sqlite3 and the Porter tokenizer.

They were indexing files like:

• MEMORY.md
• SOUL.md
• IDENTITY.md
• AGENTS.md
• tool documentation
• nested memory/*/*.md files

That’s a serious design decision.

It says:

• markdown is the source of truth
• memory is inspectable
• retrieval should be deterministic first
• local beats magical

I think this is the right instinct for most developers.

The LanceDB pipeline

Another commenter described a more automated setup around LanceDB.

The pattern looked like this:

1. watch a parent folder
2. ingest files from subdirectories
3. summarize them with local models
4. store original content + summary + tags in LanceDB
5. retrieve semantically later

Their stack included:

• a local embeddings model
• Qwen-Instruct for summarization
• deepseek-7b-4bit for reasoning

That’s not “chat memory.”

That’s a local knowledge pipeline.

And if your agent is pulling from meeting notes, browser captures, project docs, and random work artifacts, that architecture makes sense.

But it’s also a lot more moving parts.

When you should not add vector memory yet

This is where I think many agent builders go wrong.

They start with:

• embeddings
• a vector DB
• summarization
• agentic retrieval
• automatic persistence

before they’ve even decided what counts as a fact.

That usually creates a memory system that feels smart in demos and slippery in production.

Don’t add vector memory first if your main problem is any of these:

• “I need the agent to remember exact preferences.”
• “I need reliable lookup from markdown docs.”
• “I need local persistence I can inspect.”
• “I need to debug why the agent retrieved something.”

In those cases, start with files and SQLite.

Add vectors later.

A good rule of thumb for OpenClaw memory

Use this progression:

Stage 1: file-based memory

Use markdown files only.

Best for:

• identity
• instructions
• stable preferences
• tiny setups

Stage 2: SQLite FTS5

Add lexical search across your markdown and docs.

Best for:

• exact text retrieval
• local-first systems
• deterministic behavior
• easy debugging

Stage 3: vector search

Add LanceDB or another vector store only when you need semantic recall.

Best for:

• related-note discovery
• fuzzy matching
• large note collections
• retrieval across messy unstructured content

Stage 4: summarization pipeline

Add local summarization only when your incoming data volume is high enough that raw retrieval becomes noisy.

Best for:

• meeting notes
• large file drops
• browser capture archives
• workflow artifacts

That order matters.

The part most developers will care about: operations

There’s another reason local memory wins for OpenClaw users.

It’s operationally sane.

You can:

• copy it between machines
• version parts of it with Git
• back it up with normal tooling
• inspect corruption directly
• rebuild indexes when needed
• keep sensitive data off third-party servers

A folder plus SQLite file is not exciting.

It is exactly the kind of boring infrastructure that survives.

That same instinct shows up in adjacent OpenClaw discussions too: persistence, migration between machines, and whether setups are robust enough for work use.

Memory is where those concerns stop being theoretical.

What this has to do with AI automation costs

This is the part that doesn’t get discussed enough.

Once you move from “chatbot memory” to real agent workflows, your cost profile changes.

Now you’re doing things like:

• repeatedly querying memory during long runs
• summarizing incoming files
• routing between retrieval and reasoning steps
• running agents 24/7 in n8n, Make, Zapier, OpenClaw, or custom automations
• letting background jobs process docs, notes, and artifacts continuously

That means memory architecture and compute pricing are connected.

A memory stack with ingestion, summarization, and multi-step retrieval can burn through token-metered APIs fast.

That’s one reason predictable compute matters so much for agent builders.

If you’re wiring OpenClaw or automation workflows against an OpenAI-compatible API, the last thing you want is to babysit token spend every time you increase memory usage or add another background agent.

That’s exactly the problem Standard Compute is aimed at: unlimited AI compute at a flat monthly price, using an OpenAI-compatible API, so you can run agent workflows without cost anxiety.

For memory-heavy automations, that pricing model makes a lot more sense than per-token paranoia.

My recommended stack for most serious local OpenClaw users

If I were setting up memory today, I would do this:

1. OpenClaw memory_wiki or plain markdown files for identity and durable instructions
2. SQLite FTS5 for exact retrieval across notes, docs, and memory files
3. LanceDB only if semantic recall is clearly needed
4. Qwen-Instruct or another local summarizer only after ingestion volume becomes real
5. A stronger reasoning model only when the agent needs to synthesize across retrieved material

That ordering avoids a lot of pain.

It also matches how good systems usually evolve: from explicit and inspectable to more automated only when the workflow demands it.

Final take

The best thing about that r/openclaw thread is that it didn’t produce a fake winner.

Everyone was right from a different angle.

The file-only people were right that memory gets overcomplicated fast.

The hybrid people were right that one retrieval method can’t do five different jobs.

And the SQLite people were especially right that exact facts need exact retrieval.

If you’re building memory for OpenClaw, I’d keep this mental model:

• identity belongs in files
• facts belong in something queryable
• semantic recall belongs in vectors
• summaries belong downstream, not at the foundation

Don’t ask embeddings to do database work.

That’s the cleanest lesson in the whole thread.

And if you’re running agents long enough for memory architecture to matter, you should probably care just as much about the compute layer underneath it. Fancy memory on unpredictable per-token billing is a great way to build yourself a new operational headache.

If you’ve built an OpenClaw memory stack that works well, I’d love to hear what retrieval split you landed on.