LLM wiki for a team: Markdown in Git, readable by agents over MCP

An LLM wiki is a folder of Markdown pages that an AI agent writes and keeps up to date, instead of searching raw documents again for every question. Andrej Karpathy described the pattern in April 2026. It works well for one person. For a team it needs rights, shared editing, history and review, and a wiki that stores pages as Markdown in Git can give an agent those through MCP.

This post says what the pattern is, where it breaks when more than one person uses it, and what Folio does and does not do about each break. What Folio does is taken from its code and documentation; what Karpathy wrote is taken from his gist, as it stood on 2 November 2026.

What is an LLM wiki?

Karpathy's gist is an "idea file": a description of a pattern that you paste into an agent such as Claude Code, which then builds the details with you. The idea is that, instead of retrieving from raw documents at question time, the model builds and maintains a lasting set of linked Markdown pages between you and your sources. Knowledge is compiled once and kept current, so it adds up. You choose the sources and ask the questions; the model does the summarizing, cross-referencing and bookkeeping.

The gist describes three layers and three operations:

• Raw sources. Articles, papers and data that the model reads and never changes.
• The wiki. Markdown pages the model writes and maintains: summaries, pages for entities and concepts, comparisons.
• The schema. A configuration file such as CLAUDE.md or AGENTS.md that tells the model how the wiki is structured and what workflow to follow.
• Ingest, query, lint. Ingest reads a new source and updates the pages it touches. Query searches the wiki and answers with citations. Lint checks for contradictions, stale claims and pages nothing links to.

Two plain files hold it together: an index of pages with one-line summaries, and an append-only log of what was done. The gist names Obsidian as the place a person browses the result and says the wiki is, in the end, a Git repository of Markdown files, with the history, branching and collaboration that come with Git. It also mentions a team wiki fed by Slack threads and meeting transcripts, but as a use case, not a design: it does not say how several people share one wiki.

Why does it work well for one person?

Alone, almost every hard question is already answered by the setup. Everything in the vault is yours, so there are no rights to check. Nobody else edits at the same moment. You read what the model changed, and the history is whatever you commit. People who want this in Obsidian can do it with a folder and a coding agent, and our post on an Obsidian vault as a team wiki covers how far that goes.

Where does an LLM wiki break for a team?

Four things change when the wiki has more than one reader or writer.

• Rights. Some pages are for some people. An agent that reads the whole folder tells everyone what is in it. The agent needs the rights of the person it works for, not of the folder.
• Editing at the same time. A person and an agent, or two agents, change one page. Files in a folder have no answer for that besides a merge conflict afterwards.
• History. When an agent can touch ten or fifteen pages from one source, you need to see who changed what, and to undo it.
• Review. A wrong sentence written by an agent is read as fact by the next person and by the next agent. Someone has to be able to find and correct it.

The last point is the real risk of the pattern. The model does the bookkeeping, so errors compound unless people can see what changed. That is a reason to keep the wiki in a system with history and rights, not a reason to avoid the pattern.

How does this look in Folio?

Folio is a self-hosted wiki where each page is a Markdown file in a Git repository, and PostgreSQL holds only the index, rights and editing state. That matches the gist's "just a git repo of Markdown files" literally. What it adds for a team:

• Git is the store. Every space is a Git repository or a folder in one. A write reaches the file at once, and the commit follows after about 90 seconds of quiet, authored by the person whose token or session made the change. You can also clone the repository, edit files locally, push, and ask Folio to re-sync.
• An agent over MCP. The /mcp endpoint has 49 tools: 23 read and 26 write. An agent can search, read pages and earlier versions of a page, follow backlinks, list pages nothing links to and links that lead nowhere (list_orphans, list_unresolved_links), read the link graph, read tags and properties, and create or update pages, tables, boards and forms. The orphans and broken links are the lint step of the pattern, done with tools instead of by eye.
• A built-in assistant. The sidebar has an assistant with two modes: Ask can only read, and Agent can also write. It calls the same tools with the signed-in person's rights. It runs on a Cursor API key that each person or an admin provides, and the admin can add rules for the space in a .agent folder. See the AI onboarding assistant post.
• Rights follow the person. Pages have the space role and can be restricted to named people and groups. The tree, search, backlinks, the graph and MCP all leave out pages the person cannot open. A token can only narrow what its owner may do.
• People together, history for everyone. Documents, tables and boards are edited live by several people, and the history says who changed a page. An agent's writes are authored as the token's owner, so they show up under that name.

Connecting an agent takes one command. Create a token under the user menu, API tokens, with the read scope, and add the server:

claude mcp add --transport http folio https://your-folio.example.com/mcp \
  --header "Authorization: Bearer folio_pat_..."

Claude Code, Cursor and Codex can use a token like this; claude.ai, Claude Desktop and ChatGPT connect with OAuth. Exact steps are on the Claude Code page, the Claude page and the integrations hub. The rights model and tokens are explained in MCP security for a wiki, and the comparison with Confluence and Notion is in our post on wiki MCP servers.

What does Folio not do?

• No built-in ingest, query and lint workflow. Folio does not run Karpathy's loop for you. You write the schema (your instructions to the agent) and drive the agent yourself, or use the .agent rules for the built-in assistant. Folio gives the agent the pages and the tools.
• No approval step for agent edits. An agent with write access changes pages directly. The protection is that its edits are in Git history, under its owner's name, and can be reverted; start with a read token and give write access only where you accept that.
• Obsidian markup is read, not written. Folio shows [[wikilinks]], embeds and callouts and keeps your files unchanged, but it does not support Dataview queries or community plugins.
• The history is not instant. A page's history can be empty for a minute and a half after an edit.
• The assistant needs a Cursor API key. Folio does not run a model itself; an agent over MCP uses whichever model its own client uses.

How to start

Run Folio from the install guide, or open an existing Git repository of Markdown as a space. Put your schema in a page the agent reads first, connect one agent with a read token, and let it answer questions for a week before you give it write access to one space. If your notes are in an Obsidian vault, Folio notices the .obsidian folder when you create a space from it, and a repository that already has files opens with a light footprint, without ids written into your files.

All posts