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 the Studio gives 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.

Built on Karpathy’s LLM wiki

The format borrows heavily from Andrej Karpathy’s LLM wiki gist. 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, 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. The Studio’s wiki is a direct adaptation of that pattern for an engineering org.

What agents read

Before starting a ticket, the agent loads the Wiki Index — a one-page catalog of every wiki entry with a 1–2 line summary. On the screenshot above that’s the amber hub at the center. 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 actually 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 Compactor 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 agents write

After shipping a change, the agent updates the wiki. Sometimes that’s patching a single sentence in an existing page (“the Jobber 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 the shape of it, visible in the graph view, is a pretty honest read on where the product is under heavy iteration.

Why a graph, not a doc

Most documentation is a tree: folders, subfolders, pages. Trees are lossy for code. 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.

Sprint over sprint

Week one, an agent picks up a new codebase and has to re-derive 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 — often more so 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.