What is the Karpathy LLM-wiki pattern? (and why every serious org is quietly building one)
Andrej Karpathy sketched it. Farza at F Inc built the first. Garry Tan productized it as gbrain. Cole Medin ported it to Claude Code. Here's what the LLM-wiki pattern is, why it matters, and the four open-source implementations you can run today.
The short version: Your AI agent works with you for an hour, makes good decisions, then forgets everything. The LLM-wiki pattern fixes that by letting the agent compile what it learned into a Markdown wiki at the end of each session. Next time it opens, it reads the wiki first. Over weeks, the wiki becomes your company's brain — human-readable, git-versioned, and every agent your team runs can read it.
Andrej Karpathy described the shape of this. Farza built the first shipping version. Garry Tan packaged it as gbrain. Cole Medin wired it into Claude Code. It's not one product — it's a category, and the category is growing fast.
The problem the pattern solves
Every AI-native team is running into the same wall:
- An agent helps with a real task — architecting a feature, drafting a pitch, onboarding a hire.
- The agent gets smart about your company over the course of a session. It asks the right questions. It references real context.
- The session ends. That context dies.
- Tomorrow, you (or a teammate) open a new agent session. It knows nothing about yesterday.
You try CLAUDE.md. You paste in the important bits. You repeat the architecture tour every Monday. Eventually, you accept that the agent is a clever amnesia patient and move on.
The LLM-wiki pattern is the fix. Instead of relying on the human to summarize what the agent should remember, the agent compiles its own wiki. Every session contributes. Every session starts by reading what previous sessions learned.
The pattern in one paragraph
At the end of each agent session (or on a cron), a compiler LLM reads the raw session logs and produces structured Markdown pages about people, projects, decisions, systems, and recurring patterns. Pages cross-link. The output is a human-readable wiki — Obsidian-compatible, git-versionable, legible to anyone on the team. When the next session starts, the agent reads the relevant wiki pages as context. Its first action isn't "hello, I have no idea who you are" — it's "I see you were mid-way through the Q3 pricing work last week."
The four shipping implementations
All four are in the Cognition Memory registry, each with a plain-English install guide. Here's how to think about them:
1. llm-wiki — the reference implementation
Karpathy's sketch turned into a runnable reference. It's deliberately small and opinionated. Read this one first if you want to understand the pattern itself before picking a production tool.
2. gbrain — the company-brain flavor, inspired by Farza, popularized by Garry Tan
gbrain is the version that went mainstream when Garry Tan (CEO of Y Combinator) started talking about running a company brain on Markdown + git. It organizes the wiki around people, projects, and decisions — the shape of how a company actually thinks. If you're a founder who wants one wiki your whole team reads, gbrain is the natural fit.
(Credit where due: Farza at F Inc built the first serious implementation off Karpathy's sketch. gbrain is the branch of that tree that got most mainstream traction.)
3. claude-memory-compiler — the Claude Code-native version
Cole Medin's project. Installs as a Claude Code hook + MCP server. Silently captures your sessions, runs a compiler LLM, writes Markdown pages to a directory you control (we recommend your main repo so it's version-controlled). Every hire that git clones the repo gets the institutional memory for free.
→ /memory/tools/claude-memory-compiler
4. obsidian-wiki — the vault-native version
A Python framework that compiles any content source (meeting transcripts, Slack exports, email archives) into structured pages in an Obsidian vault. Best fit if your team already uses Obsidian and wants the wiki to live inside the vault your humans already read.
How to pick between them
| You are... | Pick |
|---|---|
| A founder who wants one company brain in Markdown + git | gbrain |
| An engineering team living in Claude Code all day | claude-memory-compiler |
| Already in Obsidian, want the wiki in your vault | obsidian-wiki |
| A hacker who wants to understand the pattern before choosing | llm-wiki |
All four produce Markdown. All four are git-versionable. All four stay human-readable. That part is the point — the wiki is for your team, not just for the agent. If someone quits, the wiki stays. If the agent provider changes, the wiki stays. Markdown is the only memory format that survives changes of vendor, model, and tool.
Why this matters more than "regular" agent memory
Vector-DB memory (mem0, letta, memory-mcp) is great for per-user personalization: "remember that this user prefers dark mode." It's not what you want for organizational memory — the stuff you need your whole team to read.
The LLM-wiki pattern is built for organizations:
- Human-readable. A new hire reads the wiki on day one. A vector DB is opaque.
- Git-versioned. You can see what the company "learned" last quarter by diffing the wiki.
- Auditable. If the agent misremembers something, you can find the page, fix it, commit.
- Portable. Obsidian, VS Code, any AI client. No lock-in.
For teams building real AI-native ops, this is the memory layer. Vector DBs are the cache.
The gap the pattern doesn't fill
The LLM-wiki pattern gives your agent memory. It doesn't give your team memory.
Here's what that means: the wiki might say "our Q3 pricing strategy is tiered by seat count." Your agent reads it and references it correctly. But does your sales lead actually remember the strategy? Does your ops manager know the three exceptions? When was the last time anyone refreshed on it?
This is the forgetting problem at the team level — and it's where Cognition CLO comes in. CLO sits on top of whatever wiki / memory your agent uses and models per-concept retention per employee. The wiki tells the agent what your team knows. CLO tells you what your team is forgetting before it shows up in a shipped bug or a blown deal.
Rule of thumb: wiki is the content, CLO is the pedagogy. You need both.
A common stack in 2026
For a tech-forward 20–50 person company:
- gbrain or claude-memory-compiler writes your living Markdown wiki, compiled from AI sessions.
- The wiki lives in a git repo your whole team can clone.
- Anthropic's memory-mcp (or mem0 if you need per-user scopes) handles tactical, per-session memory.
- CLO layers on top and tracks what each person is actually retaining from the wiki.
- Your X account publishes a weekly thread about one OSS tool you added to the registry.
Zero vendor lock-in. Full auditability. The AI gets smarter and the humans retain more.
FAQ
Who actually originated this pattern?
Andrej Karpathy sketched the shape publicly. Farza (F Inc) built the first shipping open-source implementation off that sketch. gbrain is the flavor that became popular when Garry Tan (YC) started showing it off. Cole Medin built the Claude Code-native version. Credit belongs to all of them.
Is this just "write a markdown file"?
Functionally similar, but the automation is the unlock. CLAUDE.md requires you to notice what's important and write it down. The LLM-wiki pattern lets the agent do that for you, across every session, with cross-linking you wouldn't bother to write yourself.
How much does the compile step cost?
Depends on model. Routing the compile step to Claude Haiku or GPT-4o-mini keeps it under a few dollars per week for a solo founder. Teams tend to run it once a day; the cost is trivial next to the time saved.
What if the generated pages are wrong?
Commit them to git, edit the wrong bits, commit again. The compiler respects your edits on the next run (all four implementations handle this). This is exactly the workflow git was built for.
Does my team need to use Obsidian?
No. The Markdown works anywhere — VS Code, Cursor, GitHub, Notion-with-import, plain cat in a terminal. Obsidian is a nice-to-have because the backlinks render graphically, but it's optional.
Does this replace my product documentation?
No — product docs are user-facing and carefully edited. The LLM-wiki is internal memory: decisions, context, who-did-what, why you picked one vendor over another. Different audience, different rigor.
What's next for the pattern?
Auto-promotion (the wiki curates itself — frequently-read pages get promoted, stale ones get archived), multi-agent compilation (different agents write different subsystems of the wiki), and retention modeling on top (knowing which pages your team is actually reading vs. ignoring). That last one is what we're building at Cognition.
Ready to start? Go to cognitionus.com/memory — all four implementations have plain-English install guides. Or hit /stack, describe your company, and the recommender will pick the right one for your team.
Share this post: