1 · The problem

Wiki memory, explained with one question

An agent has five documents about one project. Here is what plain retrieval hands it when someone asks one simple question.

The question

Plain retrieval searches the five raw documents and returns the best-matching passages:

Retrieval finds text; it doesn't know which text is still true.

Three numbers, from three documents written at different times. Nothing in the passages says which one is current, so the model has to guess every time it is asked. Passages ranked with BM25 over the raw documents (computed).

2 · The idea

What is wiki memory?

Instead of searching the raw documents every time, the agent keeps its own notebook.

Wiki memory is a way for an AI agent to remember what it has read. Each time a new document arrives, the agent reads it once and updates a small set of pages, one per project, person, system or policy: it writes down what is new, rewrites what changed, and crosses out what is no longer true. When a question comes in, the agent reads the one or two pages that cover it, not the raw documents.

Without

Question→ Search 5 raw documents→ Conflicting passages: 7, 30 or 90 days?

With

Each document, read once→ Agent updates its wiki pages

Question→ Read 1–2 up-to-date pages→ One current answer, with its history

The work moves from question time to the moment a document arrives, and it is done once.

Five words used below

Page: A short markdown file about one thing (the project, a person, a policy) that the agent writes and rewrites. Facts that can change sit one per line, with the document and date they came from.
Link: A reference from one page to another, such as [[billing-api]].
Index: A list of every page with a one-line summary. The agent reads it first to find the right pages.
Log: A dated list of what the agent changed, one entry per document.
Lint: A check across all pages for values that disagree and links to pages that don't exist.

4 · The payoff

Ask the same question again

After five documents and one check, the wiki answers from one page. Plain retrieval still returns the same three passages.

Two more questions

5 · How conflicts are resolved

A rule decides most conflicts. A person decides the rest.

Real documents disagree all the time. The agent writes each fact down with its scope, source and date; code then applies one ranking rule, and anything the rule can't decide goes to a person.

Computed by src/resolve.ts from the facts above, which come from the five documents plus two extra runbooks added for this example. The rule is a design choice you would set for your own organisation.

6 · Who does what

The model, the code and a person

Wiki memory is not just a prompt. The model does the reading and writing; plain code keeps the wiki honest; a person settles what neither can.

The model

Reads each new document.
Decides which pages it affects.
Writes and rewrites page text.
Crosses out old facts, with the reason.
Spots contradictions that need understanding.
At question time, picks the pages and writes the answer.

Code

Stores the files, with Git history.
Rebuilds the index and the log.
Checks that links point to real pages.
Compares structured fact values (lint).
Applies the source-ranking rule.
Checks that every quote exists verbatim in its source.
Enforces rules: the agent edits only wiki files; pages stay under a size limit.

A person

Approves sensitive edits.
Decides disputed facts from the review queue.
Owns the ranking rule and the schema.

In this demo the model's part is written by hand: the page edits and plain-language notes are scripted. The code's part is real and tested: tracked changes, index and log, link and fact checks, the ranking rule and the quote checks.

7 · Taking it to production

From five documents to thousands

This demo has five short documents. Real systems have thousands of large documents that change and conflict, so the same idea needs a pipeline around it.

Design guidance. This demo does not test it.

8 · Recap

So what is wiki memory?

The agent keeps its own notebook of pages and updates it as each new document arrives, instead of re-searching the raw documents for every question.
Old values are crossed out, not deleted, with the document that replaced them. The pages say what is true now and how it changed.
A periodic check (lint) catches disagreements that no single update could see. A ranking rule in code settles most of them; a person decides the rest.

Use it when

Knowledge builds up and changes over weeks: a project, a research topic, an agent's notes about a codebase or a customer. Questions are asked far more often than documents arrive.

Plain retrieval is enough when

The documents are many and rarely change, each answer sits in one passage, or nobody will review what the agent writes. The third question under “Two more questions” is one such case.

Not a knowledge graph. A knowledge graph stores typed facts that code traverses. A wiki stores pages of prose that the agent reads and rewrites.

This is a small demo, not a production system. Five short documents and hand-written edits. Real deployments have many large documents and need routing, page splitting, search over the wiki, a review queue, provenance and access control: see Taking it to production.

Read the full article: the pattern, its trade-offs and how to run it in production

Also on GitHub: Full article on GitHub

About this demo

The pattern comes from Andrej Karpathy's “LLM Wiki” (April 2026). The five documents, the pages the agent writes and the plain-language notes were written by hand to show what a careful model should produce; no model was called. The page changes, links, index, log, lint findings and retrieval rankings are computed by tested code from those pages. It is one small example, not a benchmark.

Sources: Karpathy, LLM Wiki · Anthropic, Memory tool · Claude Code memory · MemGPT · Zep · LangMem · A-MEM. Part of AI Engineer Help; discuss it in Agents & Workflows.