The Agent Wiki

Every engineering org builds a folklore: the why-we-do-it-this-way, the where-the-bodies-are-buried, the integration quirk that only one person remembers. Agents don’t get that memory for free. So we give them a wiki.

It’s a living document of your codebase, written by agents, for agents. Pages are short. Cross-links are dense. The whole thing is structured for progressive disclosure: an agent starts at the index, reads the one-line summary of every page, and pulls in only the ones it needs for the ticket in front of it.

Where does the agent wiki come from?

From Andrej Karpathy’s LLM wiki gist. The format borrows heavily from it. The core move: rather than performing RAG on raw sources every time you want an answer, an LLM incrementally builds a structured markdown wiki that “compounds over time.” Three layers sit underneath it: immutable source documents, the LLM-maintained wiki pages, and a schema that describes how pages are shaped and linked.

Three operations drive it. Ingest reads a new source, extracts what matters, and updates the relevant pages and cross-links. Query pulls the minimum set of pages needed to answer a question and files anything worth keeping back into the wiki. Lint runs periodically, checking for contradictions, orphaned pages, and dead links. Our wiki is a direct adaptation of that pattern for an engineering org.

What does an agent read before it starts a ticket?

The Wiki Index: a one-page catalogue of every wiki entry with a one- or two-line summary. The index fits in a couple hundred tokens, which is the whole point. The agent can scan the entire knowledge base cheaply, decide which pages apply, and load only those in full.

When a page references another page, the agent follows the link on demand. A backend agent editing the action processor pulls in Action Processor; if that page says “see also: known inconsistencies,” the agent pulls that in only if the work looks edge-case-y. The context window stays clean. Every token in it is earning its keep.

What does an agent write after it ships?

Whatever the next agent will need. Sometimes that’s patching a single sentence in an existing page (“the scheduling API now accepts visitId as a batch parameter”). Sometimes it’s a whole new page for an integration that didn’t have one. Sometimes it’s a gotcha added to the “known inconsistencies” page, the place every agent is told to check before trusting a field name.

Cross-links get maintained, too. If two pages now reference the same concept, a link gets added. If a page has grown too big, it gets split. The lint pass catches orphans. The graph grows as the codebase grows, and its shape, visible in the graph view, is an honest read on where the product is under heavy iteration.

Why store agent knowledge as a graph instead of a document tree?

Because trees are lossy for code. Conventional documentation is a tree: folders, subfolders, pages. A single fact, “the action processor can receive placeholder forwarding events,” belongs in four places: action processor, inbound SMS, known inconsistencies, and backend overview. A tree stores it once, picks a parent, and hopes you remember to look there. A graph stores it once and links it four times. Agents follow the link that matches the question.

The graph also surfaces drift. When a page sits on the edge with no inbound links, it’s probably stale. When a cluster tightens, that area of the product is under active churn. The shape tells you something about the code without you having to read it.

What changes by week twelve?

The agent stops re-deriving. Week one, an agent picks up a new codebase and has to work out every integration detail by reading source. Week twelve, the same agent reads a paragraph from the wiki and knows what to expect. The wiki is how the org gets faster over time without adding headcount.

You can read it, too. The agents write for themselves, but the pages are still human-readable, and in places more readable than the docs a human would have written, because an agent doesn’t skip “obvious” context or assume you were in the room when the decision was made.