The LLM wiki and Open Knowledge Format for agent knowledge

Karpathy's LLM wiki, shown for personal research, has an LLM write and keep updating a markdown wiki from collected raw sources, and Google turned the pattern into an open specification, the Open Knowledge Format (OKF), designed so that other tools and organizations can exchange it as is ^[1][3]. Version 0.2, merged into the repository in July, assumes more and more documents are written by agents and adds frontmatter fields for who wrote a document, where it came from, and who confirmed it ^[4]. In Google's own public samples, those fields are not yet filled in ^[5].

We read Karpathy's X post and gist, the Google Cloud blog, and the OKF specification (SPEC.md) in October 2026 and cross-checked them against each other ^[1][2][3][4]. The sample-bundle counts are our own, taken from commit 5d1345c of the official repository ^[5]. We have not used the OKF tooling ourselves and have no relationship with Google.

What is an LLM wiki and how is it different from RAG?

An LLM wiki answers questions from a wiki the LLM has already compiled from raw sources and keeps updating, instead of re-finding the source on every question ^[2]. On April 2, 2026, Karpathy posted "LLM Knowledge Bases" on X, writing that a large share of his recent token throughput goes into manipulating knowledge rather than code ^[1]. The flow is to index sources into a raw/ folder, have an LLM "compile" a markdown wiki of summaries, backlinks, and concept articles, ask the wiki questions, and file the answers back into it ^[1].

His observation on scale is specific. His research wiki was about 100 articles and 400K words, and although he expected to need fancy RAG, the LLM maintained index files and short summaries of every document well enough to read the relevant material at that scale ^[1]. The LLM writes and maintains the wiki; he rarely touches it directly ^[1].

The gist "LLM Wiki" he also published lays this out in three layers ^[2]. Raw sources are an immutable source of truth, the wiki is a directory of markdown the LLM owns entirely, and the schema (a file such as CLAUDE.md or AGENTS.md) tells the LLM the wiki's structure and workflows ^[2]. The operations are ingest, query, and lint, and lint means finding contradictions between pages, stale claims superseded by newer sources, and orphan pages with no inbound links ^[2].

Karpathy frames the difference from RAG as accumulation. NotebookLM and upload-style RAG re-find and stitch fragments every time a question needs five documents, while an LLM wiki starts with cross-references and contradiction flags already in place ^[2]. People abandon wikis over the cost of bookkeeping more than over reading or thinking, and LLMs do not get bored and can touch 15 files in one pass, so that cost drops to near zero ^[2].

Figure 1. An LLM wiki keeps updating a wiki compiled once from raw sources, and answers are filed back into it ^[1][2].

What is the Open Knowledge Format?

OKF is an open specification that lets different producers and consumers exchange the LLM wiki pattern without translation ^[3]. Sam McVeety and Amir Hormati of the Google Cloud Data Cloud team announced v0.1 on the Google Cloud blog on June 12, 2026, citing Karpathy's gist directly ^[3]. Their point: Karpathy's wiki, a team's wiki, and a vendor's catalog export all look alike (markdown, frontmatter, cross-links), but none were designed to cooperate, so there is no agreement on which fields every document carries or what filenames mean ^[3].

So OKF ships a format, not a service ^[3]. A bundle is a directory of markdown files, each file is one concept, and the file path is the concept's identity ^[4]. In the frontmatter only type is required; title, description, resource, and tags are recommended ^[4]. index.md (a directory listing for progressive disclosure) and log.md (change history) are reserved filenames, and concepts link with ordinary markdown links, forming a graph richer than the folder tree ^[4].

Table 1. How the wiki elements Karpathy describes in the gist map onto the OKF specification ^[2][4]. The mapping is ours, drawn by comparing the two documents.

Three principles guide the design: be minimally opinionated (type is the only requirement), keep producers and consumers independent (a bundle a person wrote can be read by an agent, and one LLM's bundle can be queried by another), and stay a format rather than a platform (no proprietary account or SDK to read or write) ^[3]. Alongside the spec Google released a reference agent that walks a BigQuery dataset, writes a concept document per table, and enriches it from official documentation, a static HTML viewer that renders a bundle as a graph, and sample bundles ^[3]. The repository is Apache-2.0 licensed, and the blog says Google Cloud's Knowledge Catalog was updated to ingest OKF ^[3].

Figure 2. One concept document from the official GA4 sample. Only type is required, and provenance links frontmatter sources to body footnotes ^[4][5].

How can you trust documents written by AI agents?

Version 0.2 starts from the premise that a bundle is continuously rewritten by agents ^[4]. The specification says that when most concepts are machine-generated, a consumer needs five answers: what it was created from (provenance), how much to trust it (trust), whether it is still true (freshness), whether it is the current version (lifecycle), and whether a number was produced the way it must be (attestation) ^[4]. According to the specification in the repository, the move to v0.2 happened on July 24, 2026 ^[4].

Provenance goes in a sources list, and per-claim provenance links a body footnote label to a sources id ^[4]. The reason for stable ids over positions is telling: agents keep rewriting these documents, the list gets reordered, and a positional reference silently attaches a source to the wrong sentence ^[4]. Each source can record its author, usage count, and last modification time, but the format stores no credibility score, because a score is subjective, differs across consumers, and goes stale ^[4].

Trust separates who wrote a document from who confirmed it. generated records who wrote it and when, verified records who confirmed it and when, and a human confirmer must use an id starting with human: ^[4]. Consumers read no verified field as unverified, confirmation by processes or agents only as machine-confirmed, and a human confirmer as human-reviewed ^[4]. status is draft, stable, or deprecated, and stale_after is an absolute instant after which the content is stale ^[4]. A document must not be rejected for lacking these fields, and the tiers are advisory signals, not access control ^[4].

Counting the official sample bundles ourselves showed that making room for a field and filling it are separate things. The 44 concept documents in the three bundles Google's reference agent built from public GA4, Stack Overflow, and Bitcoin data all carry generated and sources, and none carries verified ^[5]. Read by the spec, all 44 are unverified. The bundle with verification records filled in is acme_retail, built as an example around a fictional retailer: 8 of its 9 concept documents name a human verifier and 7 carry an expiry ^[5].

Figure 3. The 44 public sample documents built by Google's agent all name an author and sources, and none records a verification ^[4][5].

What format should a knowledge base for AI agents use?

A directory of markdown files with frontmatter, which a person reads in any editor and an agent parses without extra tooling, is where the two lines of work meet ^[1][4]. You do not need the whole spec on day one. OKF requires only type and says a bundle must not be rejected for missing fields or broken links ^[4]. A small starting sequence:

1. Put one concept per file, with type and a one-line description in the frontmatter ^[4].
2. Give each folder an index.md listing its documents with one-line descriptions, and record dated changes in log.md. Karpathy notes that starting every log entry with the same prefix lets one grep line pull the latest entries ^[2].
3. For documents an agent wrote, put the model name in generated, and link supporting sentences to sources ids through footnotes ^[4].
4. Add verified only to documents a person has confirmed, and set stale_after on content that ages quickly, such as numbers ^[4].
5. Put the wiki's structure and workflows in a schema file such as CLAUDE.md or AGENTS.md. OKF does not specify this part ^[2][4].

At TRAIL Labs we also keep company facts as a directory of markdown files and have agents read it before writing anything that mentions the company. The problem we ran into matches one part of what v0.2 addresses, the time of confirmation. As more sentences are edited by agents, we need to know when a file was last confirmed, so each file carries a last-verified date and changes are logged separately. We have not moved to the OKF format, and our verification records stay at the file level.

What are the limits of this article?

OKF is a v0.x specification, and we could not confirm how widely it has been adopted outside Google. Neither the Google blog nor the specification reports a measurement of how much agent answer accuracy changes with OKF ^[3][4]. What the spec promises is that conforming documents can be read across tools.

Karpathy's observation comes from one person's research wiki at about 100 articles ^[1]. He notes that proper search becomes necessary as a wiki grows and that he built a small search engine over his own wiki ^[1][2]. There is no public evidence on whether the same approach works without RAG for an organization's wiki of thousands or tens of thousands of documents.

The sample counts reflect the official repository on October 21, 2026, and cover only public examples produced by the reference agent ^[5]. How often verification records are filled in for real working bundles, inside Google or elsewhere, is unknown. A trust tier records that someone confirmed a document, which falls short of guaranteeing the content is correct, and the spec itself calls the tiers advisory ^[4].