A Hacker News thread went around recently with a claim that reads like a troll: a plain Markdown wiki beat every commercial AI agent memory product someone benchmarked. I couldn’t pin down that exact scoreboard, so treat it as folklore until the harness is public. The direction matches my client work, though. Markdown-and-Git wikis keep surfacing on HN (one recent Show HN pitches a wiki agents maintain themselves), and they keep outperforming what they should.
My position after shipping a lot of these: use plain files until you hit a specific wall. Most teams never hit it.
Why Agents Forget
A language model is stateless. Every turn, your framework replays the conversation into the prompt, the model reads it fresh, then it’s gone. Nothing survives between API calls unless you persist it deliberately.
Fine for a single chat session. It falls apart the moment your agent needs to know something from last Tuesday, or that this customer already churned once, or that the team ruled out Postgres in March.
Two failure modes follow. First, amnesia: your agent asks the same onboarding questions every session. Second, context bloat, where you stuff everything into the prompt, blow the budget, and watch quality sag in the middle. I unpacked that tradeoff in my piece on context engineering in the 200K token era.
The File-Based Approach I Actually Ship
Claude Code does this in production, which is the strongest argument for it. Markdown files on disk, an index loaded at session start, and the agent reads and writes them with the same tools it uses for source code. No embedding pipeline. No database.
Structure I reuse:
memory/
index.md # loaded every session, keep under 2k tokens
projects/acme.md
people/sara.md
decisions/2026-06-db-choice.md# Acme (client)
Stack: FastAPI + Postgres. Ships Fridays.
Owner: Sara. Prefers Slack, ignores email.
2026-06: rejected pgvector, latency budget too tight.The index holds pointers plus a one-line summary per file. Everything else gets pulled on demand with grep or glob, so retrieval is exact, fast, and debuggable at 3am.
Why does it work so well? Markdown is the format these models have seen more of than anything except code. Memories stay readable, so a wrong fact gets fixed by opening the file. Git hands you history and blame free. And when retrieval misfires you see exactly why, which beats staring at a cosine similarity score.
Limits are real, though. Grep misses paraphrase. Past a few thousand files, scanning slows and the agent guesses badly about where to look.
Where Vector Memory Starts To Pay
Vector memory works the way you’d expect: chunk past conversations, embed them, retrieve top-k by similarity. Same machinery as RAG, pointed at your own history instead of a document corpus.
It earns its keep when semantic recall matters. User says “that thing about slow queries,” the note says “index scan regression,” grep whiffs and embeddings land it.
Chunking is where most of these builds quietly die. Conversation turns are short, noisy, and stuffed with pronouns that mean nothing once cut from their context, so naive splitting yields garbage vectors. My notes on chunking strategies apply directly, and hybrid retrieval beats pure similarity often enough that I default to it, as covered in the production hybrid search build.
Rough threshold: below a couple thousand memory items, files win.
The Managed Products
Three names dominate client conversations.
Mem0 is a memory layer you bolt onto an existing stack: extraction plus vector retrieval, with an optional graph tier. Mem0’s own 2026 report claims 92.5% on LoCoMo and 94.4% on LongMemEval, vendor-reported, so weigh it accordingly. Advertised pricing recently started free at 10K memories and climbed from roughly $19/month, graph features much steeper. Check their docs before budgeting.
Letta (formerly MemGPT) is a different animal. Rather than a library, it’s a full agent runtime with OS-style tiers: core memory in context, recall for history, archival for the long tail, and the model pages between them itself. Choose it when you want the agent managing its own memory.
Zep sits on Graphiti, a temporal knowledge graph. Its pitch is facts that change: Sara was at Acme, now she’s at Globex, and the system knows the order. For domains full of expiring facts, that’s a genuinely different capability, not a nicer wrapper.
None of these are bad products. They’re just heavier than most projects need, each adding a network hop, a bill, and a vendor.
The Decision Table
| Approach | When it wins | Real cost |
|---|---|---|
| Markdown files + grep | Coding agents, solo assistants, under ~2k hand-edited memories | Free. Slow past a few thousand files, blind to paraphrase |
| Files + local index (SQLite FTS, BM25) | Same shape, 2k to 50k items | An afternoon of work, plus an index to rebuild |
| Vector store (pgvector, Qdrant) | Semantic recall, multi-tenant, 10k+ items | Embedding spend, chunk tuning, opaque failures |
| Mem0 / Zep | Multi-tenant SaaS, temporal facts, no infra owner | Roughly $19 to $250+/month, plus a vendor |
| Letta | The agent should page its own memory tiers | Runtime lock-in, you adopt their agent model |
What I’d Do On Monday
Start with files. Give the agent a memory directory, an index it loads every session, and blunt instructions about when to write. Most of the value lives in the write policy, not the storage; an agent that reliably records decisions beats one with a beautiful store and nothing worth retrieving.
Add search once grep starts missing. SQLite FTS5 over the same Markdown carries you a long way, and that HN wiki project reports 85% recall@20 on BM25 alone as its ship gate.
Reach for a product when you’re multi-tenant, when facts expire and ordering matters, or when nobody owns retrieval quality. Those are good reasons. “A folder feels unserious” is not, and I’ve watched that instinct cost teams a quarter.
Wiring memory into a tool-using agent also means picking a transport, which I walked through in the MCP servers explainer.
Frequently Asked Questions
Won’t a Markdown wiki break at scale?
Eventually, yes. The pain shows up as slow scans and wrong-file guesses, usually north of a few thousand notes. That’s your cue to put a full-text index in front of the same files, keeping readable storage while fixing lookup. A vector database is a later, bigger step.
How does the agent decide what to remember?
You tell it, explicitly, in the system prompt. Mine gets rules like “record decisions and rationale, record stable preferences, never record transient state.” Left to its own judgment, an agent will happily save what you ate for lunch and skip the architecture call.
Do I need embeddings at all?
Not for most single-user agents. Keyword search over well-named files covers a surprising share of retrieval, and BM25 closes much of the rest. Embeddings earn their complexity when users describe things in wording your notes never use.
Is Letta a drop-in replacement for Mem0?
No, and comparing them directly misleads people. Mem0 is a memory service you call from your own agent loop; Letta is the agent loop, with memory management built into how the model runs. Picking Letta is an architecture decision, not a storage one.
What about privacy and compliance?
Files have a real edge. Memory in your own repo never leaves your infrastructure, deletion is rm plus a commit, and audits are a diff. Hosted memory puts user data on someone else’s servers, workable but needing a DPA and a deletion path you’ve actually tested. I covered similar self-hosting tradeoffs in my writeup on open agent stacks.