# Make it remember. > Karpathy’s wiki, Garry Tan’s GBrain, and the little repo I use to keep Claude from forgetting what we decided. Three builds, one folder tree, and a prompt you can hand your agent. - written by: GPT-5.6 Sol - edited by: Andrew Schroeder, Fable 5 - status: published · 2026-08-13 - canonical: https://www.moltolabs.ai/notes/make-it-remember/ - raw markdown: https://www.moltolabs.ai/notes/make-it-remember.md ---

Note from Andrew: Seems like I can’t take my own advice — while I’m authoring this note (including the em dash), this is the first piece we’re publishing that was written by GPT-5.6 Sol. I talked about the concept of building a corpus to get better/more personalized outputs in the last piece, and I wanted to take this opportunity to test it out. Super interesting exercise for me (you can expect to hear more in a future post). Even though Sol did the writing, I believe this is an interesting and helpful note. In fact, it might lead to some changes in how we structure codebrain in the future. I’ll also call out that this only represents a few samples of what people are doing — many of you will already have systems that work way better for whatever you’re doing. And this ecosystem is changing daily.

In [my last piece](/notes/building-a-world/) I called memory one of the three big pieces of context you can give an agent. Then I moved on after roughly a paragraph. Helpful! So let’s actually build the thing. There are a bunch of ways to give an agent memory, but three systems kept coming up as my agents dug through what people are doing right now: Andrej Karpathy’s LLM Wiki, Garry Tan’s GBrain, and my own codebrain setup. I’d heard about the first two from the general AI ether, but I hadn’t read the underlying gist or repo myself. My agents did that legwork for this piece. The fun part is that all three systems have basically the same foundation: a git repo (a folder where every change can be tracked) full of markdown files. No magical new file format. No special AI brain goo. And yet they disagree about the most basic question: who should write the memory? One vocabulary caveat: these are not the same kind of “memory.” Karpathy calls his wiki a knowledge base: compiled knowledge about the world, not an agent remembering you. GBrain’s guide draws the same border, sending preferences and operational state to a separate agent-memory layer while the brain holds people, companies, and meetings. codebrain is the odd one out: memory of a collaboration—decisions, reasoning, working state. Operationally, though, all three are memory in the sense that matters here: files an amnesiac agent re-reads across session boundaries.
llm wiki compile what you read the pen: the LLM, almost always
gbrain total recall of a working life the pen: agents at scale, human curates
codebrain decisions + the why the pen: agent drafts, human ratifies
same substrate, three jobs — the slider is who holds the pen, from human ← to → agent
That disagreement makes sense once you look at the job each person needs the system to do. ## Karpathy’s LLM Wiki In early April, Andrej Karpathy posted about how much of his AI use had shifted from manipulating code to manipulating knowledge. A couple days later he shared an [LLM Wiki gist](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f). He calls it an “idea file,” which is important. There’s no app to install. You paste the idea into your agent and build your own version together. The basic setup has three layers: ```text llm-wiki/ ├── CLAUDE.md # the rules for maintaining the wiki ├── raw/ # original articles, papers, images └── wiki/ ├── index.md # a map of what exists ├── log.md # append-only record of changes ├── concepts/ └── entities/ ``` If you use Codex, that first file might be `AGENTS.md` instead. Either way, it’s the schema: the instructions that explain the structure and tell the agent exactly what to do. The `raw/` folder holds the source material you chose. The agent can read those files but never change them. Everything under `wiki/` is generated and maintained by the LLM. Karpathy defines three operations: ingest, query, and lint. When you **ingest**, the agent reads a new source from beginning to end. It updates every concept or entity page the source touches, flags contradictions with older material, refreshes `index.md`, and adds a dated note to `log.md`. One article might update 10 or 15 different pages. When you **query**, the agent starts at the index, follows the relevant pages, and gives you a cited synthesis. If the answer is useful, it writes that answer back as a new page. The next exploration starts with what the last one figured out. When you **lint**, the agent does wiki cleanup: stale claims, missing links, orphan pages, contradictions, and gaps worth researching. Basically all the annoying bookkeeping that makes a personal knowledge base useful six months later instead of only on the day you lovingly organize it. Karpathy uses Obsidian to read the files and its web clipper to save articles as markdown. His research wiki was around 100 articles and 400,000 words when he posted. At that size, the index and links were enough. No vector database or RAG system (extra infrastructure that searches a large body of material and feeds the right pieces back to the model). This is built for compiling knowledge. The human picks good sources and asks good questions. The LLM does the writing and filing. In his words, you “never (or rarely) write the wiki yourself.” That’s a feature when the thing you want to preserve is a growing synthesis of everything you read. ## Garry Tan’s GBrain On April 5, Garry Tan open-sourced [GBrain](https://github.com/garrytan/gbrain), the system behind his OpenClaw/Hermes Agent setup. It did not grow out of Karpathy’s post. The timeline gives that away: Karpathy posted on April 2, 2026; GBrain arrived three days later already 155,795 pages deep, in a fully formed code drop. Nobody builds that over a weekend. What happened is more interesting: two people arrived independently at the same substrate. Karpathy supplied the now-famous vocabulary. Tan supplied a running production system. GBrain’s docs didn’t call it “Karpathy’s LLM wiki pattern, but extended” until April 7, two days after release. That’s retrofitted framing, not lineage. The rest of the repo’s numbers are kind of nuts too: 24,589 people, 5,340 companies, and 66 automated jobs. This is the actual brain behind his always-on agents, built from email, meetings, contacts, tweets, and years of notes. Markdown is still the source of truth. You can open a person’s file, read it normally, and use `git diff` to see what an agent learned overnight. But a simple index stops being cute somewhere before page 155,795, so GBrain also syncs those files into Postgres (a database). It uses hybrid search, meaning semantic similarity and normal keyword matching run together. It also builds a knowledge graph by extracting relationships like `works_at`, `founded`, or `invested_in` whenever a page is written. That graph is what lets the agent answer questions like “who works at this company?” without hoping the right phrase appears in a search result. The files themselves follow a useful pattern even if you never touch a database: ```text brain/ ├── RESOLVER.md ├── people/ ├── companies/ ├── meetings/ ├── concepts/ └── originals/ ``` `RESOLVER.md` is a filing decision tree. Each fact gets one canonical home instead of being copied into three places and quietly disagreeing with itself. A page starts with “compiled truth,” the agent’s current best summary, followed by an append-only dated timeline showing when each fact was learned. Then the machinery keeps it alive. Every new message passes through a signal detector. The brain gets checked before the agent goes looking elsewhere. A person mentioned once gets a stub page; repeated mentions trigger enrichment. Meetings run through a fuller pipeline. Overnight jobs deduplicate pages, fix citations, find contradictions, and prep the next day. Garry’s pitch is that he wakes up smarter than when he went to bed. This is total recall at operational scale. Garry has a gigantic professional surface area, so losing a name, company, meeting, or relationship is expensive. Agents do the writing at industrial volume. The human’s job becomes librarian: set the rules, watch the quality, and prune aggressively. That last part matters. Garry warns that an uncurated brain becomes “a garbage dump with great search.” Run the full system and you’re also running an always-on server, a database, and real API spend. I would not start here because 66 cron jobs sounds cool. I’d start here when the volume of useful information has made the simpler thing fail. ## codebrain My version started on June 1. The mildly embarrassing truth is that I hadn’t studied either system above. I’d absorbed the general idea that people were moving their working lives into Claude Code and plain repos, then I asked Claude to help design its own memory before we put anything on disk. codebrain is a few hundred markdown files. No server, database, vector index, or ingest pipeline. Any agent that can read files can use it. The layout looks like this: ```text codebrain/ ├── CLAUDE.md ├── context/ │ └── now.md ├── log/ │ └── 2026/ ├── projects/ │ └── / │ ├── CLAUDE.md │ ├── log.md │ └── notes/ ├── inbox/ └── artifacts/ ``` The job is different. I’m not trying to compile everything I read, and I definitely don’t need total recall across 24,589 people. codebrain is the working memory of a thinking partnership. The thing worth saving is a decision and why I made it, including the options I rejected. That changes who gets to write. Claude drafts constantly, but anything canonical is draft-then-ratify: I approve it before it becomes part of the record. I write plenty in my own words too. The system would be pretty useless if the agent confidently generated my judgment for me. The folder tree alone does almost nothing. The session ritual is what makes it work.
session start read CLAUDE.md, context/now.md, the project file
during strays → inbox/ the moment they surface
session end day’s thinking → log · decisions + why → project log
commit + push the repo is the memory
the ritual is the loop — tomorrow’s session starts by reading what today’s wrote ↩
Every fresh session starts by reading the root `CLAUDE.md`, the files in `context/` led by `now.md`, and the relevant project’s `CLAUDE.md`. `now.md` is rewritten, never appended, so it only holds what matters today. History goes into dated files under `log/2026/`, which are append-only. Each project gets its own small context file, decision log, and notes folder. During a session, anything that might otherwise die in the transcript goes into `inbox/` immediately. At the end, the agent writes the day’s thinking to the daily log, adds durable decisions and their reasoning to the project log, then commits and pushes the repo. Built-in agent memory can be useful, but I treat it as scratch space. The files are the record. A decision entry can be painfully simple: ```markdown ## 2026-08-13 — Keep the first version file-only - Decision: use markdown and grep; no database. - Rejected: vector search now. - Why: the vault is small enough to load and search directly. - Revisit when: retrieval starts missing things we know are there. ``` That last line is useful. It keeps “not now” from quietly becoming “never,” while stopping every new idea from blowing up the current plan. The system is intentionally small enough for a new session to load the important layer in its first minute. Descriptive filenames and `grep` handle retrieval. It would fall over long before 150,000 pages, and it only works if we actually run the start and write-back ritual. But for its job, that’s fine. It keeps my agent from forgetting between sessions and keeps both of us from changing direction based on vibes. So which one should you build? Start with the job. If you want your reading to compound, build the wiki. If your agent needs to remember a huge operational life, borrow GBrain’s one-home-per-fact rules and add search infrastructure when volume earns it. If you want a thinking partner that remembers what you chose, store decisions and make the human ratify them. You can also steal across the lines. I want codebrain’s decision record, but Karpathy’s immutable sources and GBrain’s compiled-truth-plus-timeline pattern are both useful ideas. Same substrate, different jobs. ## Hand this to your agent Start smaller than all three: ```text memory/ ├── CLAUDE.md ├── context/ │ └── now.md ├── projects/ │ └── first-project/ │ ├── CLAUDE.md │ └── log.md ├── log/ └── inbox/ ``` Then paste this: ```text Help me build a file-based memory for our work. First, interview me one question at a time about what this memory needs to do. Do not invent answers for me. Then create the folder tree above. In the root CLAUDE.md, write a short start-of-session rule: read the root instructions, context/now.md, and the active project file. Add an end-of-session rule: update the dated log, record decisions plus rejected options and why in the project log, then update now.md. Keep now.md current by rewriting it, not appending history. Use inbox/ for anything worth saving before the session ends. Put each fact in one canonical file and link to it elsewhere. Before writing any canonical file, show me the proposed text and ask me to ratify it. Keep the always-read files short. Finally, walk me through the files you created and run our first session write-back with me. ```