If you work with Claude day after day, it builds up a memory of your work - and it turns out to be nothing fancy: a pile of plain markdown files. One index, a lot of small notes, a few rules. It's basically Karpathy's "LLM Wiki," and the interesting part is that nobody designs it. Claude's own memory nudges you into it.
The thing I expected to build, and didn't
I work with Claude on the same projects for weeks at a time, and the useful part is that it remembers. I can come back a week later and it already knows what we decided, how I like things done, and what's still open. I don't have to re-explain.
I assumed making that work would be complicated - that somewhere there'd be a special database doing the remembering. That's how "give the AI a memory" usually sounds.
There's none of that. What Claude keeps is a folder of plain text files - notes it writes and reads on its own. That's the whole memory. And I never set it up. It built up one note at a time, just from using Claude day after day, and two small habits shaped it along the way.
Andrej Karpathy described this same pattern in a short writeup he calls the LLM Wiki - an agent that keeps its own interlinked markdown notes instead of querying a database. What surprised me is how little I did to get there. I didn't go looking for the pattern, I landed in it. So this is a writeup of the version I backed into - what it looks like, why it ends up that shape, and where it stops working.
What it actually looks like
There are two kinds of file.
One index. It's called MEMORY.md, it loads into context at the start of every session, and it's nothing but one line per note:
- [User Profile](user_profile.md) - who I am, role, accounts
- [Writing Preferences](feedback_writing.md) - keep it short, plain hyphens, don't exaggerate
- [Project X status](project_x.md) - PRIMARY entry for project X; read first
Then the notes themselves. One fact per file, each with a few lines of frontmatter so Claude knows what it's looking at:
---
name: feedback_writing
description: "how I want drafts written - used to decide if this note is relevant"
metadata:
type: feedback
---
Keep writing short and plain. No em-dashes, use plain hyphens. Don't
round a real number into a nicer wrong one.
Why: the plain, honest voice is the thing people trust.
See [[reference_writing_style]].
That's the whole system. A note links to related notes with [[name]], the same way a wiki does. There are four flavors I use - who I am, feedback on how to work, ongoing project state, and pointers to external resources - but the type tag is a convenience, not essential.
Looking things up is just as plain. At the start of a session Claude reads the index. When something might be relevant, it uses that one-line description to decide whether to open the full note, then reads it. There's no search engine and nothing to set up. A short index it can read top to bottom, plus plain text search across the files, does the job.
Why this shape, and not a database
Two habits produced it, and they're the actual point. The structure just comes out of them.
The first is keeping things lean. The model can only hold so much text at once, so an index that loads every session has to stay small, or it crowds out the real work. That one limit drives most of the design. One fact per file, so each index line stays short. Notes get updated or deleted when they go stale, not added to forever, because a note that keeps growing is one you can no longer afford to load. Keeping the index cheap to read is what keeps the whole thing usable. It's the step the dump-everything-into-a-database approach skips.
The second is writing with rules. Left to improvise, an agent will make a fifth note for something four older notes already cover, and you end up with a mess. What keeps that from happening is a small set of rules - the frontmatter, the types, and the one that matters most: before writing a new note, check whether one already covers it and update that instead. Claude comes with these rules already, which is why I never had to add them. They're what turn it into a careful note-keeper instead of a generic chatbot, and they're boring on purpose.
There's a deeper reason the file approach works well. The usual way answers each question by digging back through your raw documents from scratch, so nothing builds up. A wiki is different: the thinking gets done once and written down. When I correct a wrong assumption, Claude doesn't add a new scrap to a pile - it edits the note, or deletes it. The understanding lives in the notes, not in redoing a search each time. Knowledge adds up instead of starting over.
Where it stops working
A quick honesty check, because "markdown beats databases" is the kind of overclaim that makes a post worse.
This is a small, personal tool: one person, one agent, notes on disk. It works fine up to a few hundred notes - Karpathy puts the limit around a hundred sources before you really want search, and that matches what I've seen. Past that you add real search on top of the markdown rather than replace it; the files keep working, you just outgrow finding things by hand.
The bigger change is people, not note count. Put this on a server with several agents and multiple teams writing the same memory, and a folder of files stops being enough - many writers at once, and people who need to find things by meaning, not by filename. That's where the heavier tools earn their place: a managed memory store, a vector database, a graph store like neo4j, graph-based search like GraphRAG. Those terms are answers to that bigger problem, not this one. Reaching for them first is the mistake - at personal scale they're cost and setup you don't need.
It also goes stale if nobody keeps it current, but that's true of any memory, a database included. The one upside here is that cleanup is cheap: Claude does the tedious part, pruning dead notes and fixing links. You just have to keep asking.
None of this is new or special. It's markdown files in a folder. Same idea at any size - keep a structured memory and look things up - just sized for who's using it.
If you want to try it
There's almost nothing to set up. On Claude this already happens on its own. It keeps the notes, writes the index, links them, and avoids duplicates without being told. I never handed Claude those rules - I noticed them afterward, by reading what it had already built.
So the advice is small: use Claude on a real project for a few weeks, then open its memory folder and look. The structure will be there.
That's the part I keep coming back to. I didn't build a memory system, and I didn't set one up. I just worked, and it was already there when I looked.
Karpathy's LLM Wiki gist: https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
Top comments (0)