Karpathy's LLM Wiki, ready for teams

AI quickly became a core part of how people work. The tools around it never caught up. Workflows break across sessions, tools, and teammates. In April, Andrej Karpathy named what's missing.

The shift you've probably felt

Anyone who has worked alongside an AI for more than a few weeks has felt the same friction. You upload the roadmap document. The AI reads it. Tomorrow, fresh session, you upload it again. A teammate asks the same AI a related question and starts from zero, because nothing from your conversation persists for them. You copy and paste context into Cursor that you already explained to Claude an hour ago.

The cost adds up. The latest founder surveys put it around 91 hours a year per person, just re-explaining what the team already knows. Multiply that across four or five tools per teammate and the picture gets worse. People used to call this "context switching." It is more specific than that. It is fragmented context, where every AI surface holds a different version of what the project is about, and the human becomes the glue.

The early answers were retrieval-augmented generation systems. Index the documents, embed them, pull relevant chunks back into the prompt on demand. RAG works. But it does not accumulate. Each query is a fresh swim through the same raw material. Nothing the system has ever figured out gets remembered for next time.

People have been groping toward something better. Notes that re-organize themselves. Knowledge bases that grow when you read into them. Personal wikis that an AI maintains. The pattern was clear in shape and unclear in detail. In April, Andrej Karpathy posted a gist on GitHub that gave the pattern a name.

Karpathy's LLM-Wiki proposal

The gist is short, and it is the kind of writing that travels. Karpathy frames it as a question:

What if your AI didn't just answer questions, but actually learned, built, and grew smarter every single day?

His proposal: replace stateless retrieval with a persistent, LLM-maintained knowledge artifact. He calls it an LLM Wiki. It is structured around three layers.

The first layer is raw sources, the immutable inputs you keep feeding the system. Articles, PDFs, transcripts, papers, images. They never change. They are the ground truth the wiki refers back to.

The second layer is the wiki itself, generated by the LLM. Cross-linked markdown that summarizes what the sources say, organizes it into pages about specific entities and concepts, and grows every time something new arrives. The wiki is the artifact you actually read and query. It is what makes the system feel smarter over time.

The third layer is the schema, a configuration document that tells the LLM how to structure the wiki. What kinds of pages exist. How they connect. When to create a new one. Karpathy uses a CLAUDE.md analogue as the example.

On top of those three layers, three operations. The LLM ingests new sources, propagating them into affected wiki pages and adding cross-references. It queries the wiki when you ask a question, synthesizing across pages instead of dredging raw documents. And it lints the wiki periodically, catching contradictions, stale claims, orphan pages, missing connections.

The core insight is the punchline: wikis fail because the bookkeeping is tedious. Cross-references, deduplication, consistency checks, freshness. Humans abandon wikis because the maintenance overhead is brutal. LLMs are very good at exactly that kind of bookkeeping. Hand them the janitorial work. Humans curate sources and direct attention.

It is a tidy idea. It also surfaces the thing RAG quietly never solved. Persistence.

The hard part: making it work for a team

Plenty of people read the gist and went to build it. Within a month, a handful of personal-scale implementations were running.

Origin is a local-first Rust tool that gives a single developer persistent memory across Claude Code and Cursor sessions. It captures decisions, distills them into wiki pages, keeps source provenance attached. Synto takes a folder of markdown notes, uses a small local model to extract concepts and a larger one to compile cross-linked articles, and only recompiles what new sources touched. nohmitaina runs a nightly "dream cycle" on a macOS desktop, extracting concepts from your writing while you sleep and surfacing them the next morning. All three are real, all three work, all three are individual tools.

A team has different needs. Multiple people. Multiple AI surfaces, because Claude is good at some things and ChatGPT or Cursor or Gemini at others, and people use what they prefer. Strategic work that spans weeks. Decisions that affect tomorrow's choices. Tasks that need to run, not just be remembered. Knowledge that is structured, not just markdown.

A team also needs the wiki to plug in to the AI tools everyone already pays for. Nobody wants a separate app to babysit. Nobody wants the wiki to live in one person's laptop. And nobody wants the work that produces and consumes the wiki to be invisible to the team.

When you list those constraints, the LLM Wiki idea stops looking like a project and starts looking like a workspace. Turns out, that was already being built.

The three layers, mapped to Octopad

Octopad is the back-office powering your team's AIs. It is the workspace where strategy, knowledge, and work live together, designed for AI to read, update, and run work from. Every teammate's AI plugs in over MCP. Karpathy's three layers all show up, with the team-grade form on top.

Raw sources

In Octopad, files are first-class. PDFs, decks, spreadsheets, transcripts, images, whatever the team needs to preserve. When something gets uploaded, the system automatically extracts text from the binary, embeds it for semantic retrieval, and makes it attachable to tasks, knowledge items, and pages. Sources stay immutable, the way Karpathy describes. The system never edits them. It refers back to them.

The wiki

This is where the team-grade upgrade lives. The wiki layer in Octopad is two things, working together.

Pages are long-form markdown documents. The architecture spec, the research write-up, the meeting notes, the strategy doc. They live in folders, they cross-link, they evolve. The standard wiki shape.

Knowledge is the upgrade. Octopad treats four kinds of atomic knowledge as first-class objects, sitting alongside the long-form pages. Key Facts are neutral atomic truths. Decisions carry rationale. Questions stay open until they are answered or deferred. Risks carry severity. Every item is vector-embedded and semantically searchable. Every item can attach to pages, tasks, and other items.

What this gives you is something Karpathy's plain-markdown wiki cannot. When the team is making a real decision, the AI does not just retrieve a passage from a page. It pulls in the four Key Facts that bear on the choice, the two prior Decisions that constrain it, the open Question someone flagged last week, and the Risk that one teammate raised in a comment. The wiki is a graph of typed knowledge, not a stack of files.

The schema

Karpathy puts the schema in a single CLAUDE.md-style file. Octopad does it in two places, structured for a team.

A workspace-level methodology ships with every session. The moment any teammate's AI connects, it receives the workspace standards: how to classify a request, what a complete task needs, when to capture a Decision versus a Key Fact, how to route knowledge into folders, what counts as "done." This arrives over MCP. It does not depend on which AI the teammate is using. The discipline is the same across Claude, ChatGPT, Cursor, Gemini.

A folder-level best-practices layer sits underneath. Each folder defines the conventions for the pages it holds. The Engineering folder has its own templates and freshness norms. The Research folder has different ones. The Competitors folder enforces a per-competitor page convention. The schema is not a global file. It is layered, the way a real team operates.

The query operation, done right

This is where Octopad pulls ahead of the wiki shape Karpathy outlined.

In the gist, "query" means searching the wiki and synthesizing the answer. That works for a person reading a personal knowledge base. It does not work for an AI about to do real work for a team. The AI needs more than a search result. It needs to know what task it is about to start, what depends on what, what was decided last week, what the linked pages say, which stream this lives under, and what the success criteria are.

Octopad ships exactly that. When an AI begins a task, the workspace assembles a per-task briefing. The briefing pulls together the task's full description, its dependencies, the pages explicitly linked to it, the typed knowledge that bears on it, the parent work stream's status, recent activity, and the methodology rules that apply. All of it arrives in one shot, before the AI takes a single action.

This is the difference between handing the AI a stack of search results and handing it a desk. The desk has the brief on it, the relevant files stacked, the open questions noted in the margin, the dependencies marked. The AI sits down and starts. That is what the wiki layer was built for. That is what makes the AI feel like it actually knows the company, not like it is searching for it.

What a personal tool can't reach

Personal-scale LLM-wiki tools stop at organized knowledge. A team needs more. Four pieces, all native in Octopad.

Tasks sit above the wiki. Strategy lives in the task tree. Parent tasks with subtasks, dependencies wired with rationale, work streams grouping related efforts, goals above the streams. The plan is not a separate document that drifts from reality. The plan is the task tree. The AI reads it as easily as it reads the wiki, and the next action is always one query away.

MCP coherence across every AI surface. Octopad is built MCP-native. Claude, ChatGPT, Cursor, Gemini, whatever the teammate prefers, all see the same workspace. Same tasks, same knowledge, same methodology. When one teammate's AI captures a Decision, the next teammate's AI sees it the next morning, in whichever tool they live in. No replatforming.

Octobots. A crew of always-on background agents that recap every session, summarize every page, log every stream's activity. They run while the team is doing other things. They produce daily progress reports without anyone asking. They keep the workspace state describable at a glance.

Methodology, loaded every session. This is the schema layer made operational. The workspace standards arrive with every connection, so every AI starts informed about how this team operates, what its priorities are, and what discipline applies to the work. It is the difference between an AI that has to be re-educated and one that walks in already aligned.

These four pieces are not extensions to the LLM-Wiki idea. They are the layer above it that turns a personal knowledge tool into a team operating system. The wiki is the floor. The workspace is the building.

Where this is going

The shift Karpathy named is bigger than RAG fading out. The interesting thing about persistent, accumulating knowledge is not that the AI gets smarter. It is that the team's work compounds. The work done in March improves what gets done in May, because the wiki carries it forward and every teammate's AI can use it.

For an individual, that is a productivity boost. For a team of five or fifteen, it is a different kind of company. The choice in front of every small AI-native company in 2026 is whether to keep gluing together a stack of human-first tools with AI bolted on top, or to operate inside a back-office built for AI in the first place.

Connect your AI. See it work.

Octopad is live. Bring whichever AI your team already pays for. Five minutes to plug in, ten minutes to see the first per-task briefing land. The wiki you read about in April is already running. Connect your AI →