Google's Open Knowledge Format Standardizes the LLM Wiki. The Whole Required Spec Is One Field.

TL;DR

On June 12, 2026, Google Cloud published the Open Knowledge Format (OKF) v0.1, an open, vendor-neutral spec for storing knowledge as a plain directory of markdown files with YAML frontmatter, so AI agents can read, write, and swap knowledge bases without a proprietary platform. It formalizes the grassroots "LLM wiki" pattern that Andrej Karpathy popularized, and its most striking design choice is how little it asks. OKF requires exactly one field on every concept: type. What types exist, what other fields to add, what the body says, all of that is left to you. The spec standardizes the handshake between tools, not what you put in the box. Karpathy wrote a gist; Google wrote a spec. That is a fair summary of this whole industry.

Where this comes from: the LLM wiki

The idea OKF standardizes is not Google's. Developers have been quietly keeping personal and team knowledge as folders of markdown that an LLM maintains, dropping in meeting transcripts, articles, and notes, and letting the model update cross-references and stitch it together. Karpathy put the appeal crisply: LLMs do not get bored, do not forget to update a cross-reference, and can touch fifteen files in one pass. His LLM Wiki gist went viral (thousands of stars) precisely because the pattern is so simple and works so well. The problem it hit at scale is boring but real: everyone's wiki has a different structure and metadata, so you cannot easily hand yours to my agent, or merge a third person's, without a translation layer nobody wants to write.

What OKF actually specifies

OKF is a "bundle": a directory of markdown files, each representing one concept (a table, a person, a project, a meeting, whatever you decide), with YAML frontmatter for metadata and a markdown body for the content. The metadata can carry fields like name, owner, and tags, and the body can link to other concept documents, which is how a bundle becomes a browsable knowledge graph. The radical part is the requirement list. There is one entry on it: type. Google's own framing is that the spec defines the interoperability surface, not the content model.

Here is the analogy that makes it click. OKF is a shipping-container standard for knowledge. The global shipping system does not standardize what goes inside a container, bananas or bicycles or car parts, it standardizes the corner fittings and the dimensions, the boring metal edges that let any crane, ship, and truck handle any box. OKF does the same trick: it standardizes the markdown-plus-type "edges" so any agent, visualizer, or pipeline can pick up any bundle, and it deliberately says nothing about the cargo. That restraint is the design, not an oversight.

What Google is shipping with it

A spec on its own is a PDF nobody reads, so Google paired OKF with two reference implementations. An enrichment agent walks a BigQuery dataset, drafts an OKF concept document for every table and view, then runs a second LLM pass that crawls authoritative documentation and enriches each concept with citations, schemas, and join paths. And a static HTML visualizer turns any OKF bundle into an interactive graph view in a single self-contained file. The first shows OKF being generated from real infrastructure; the second shows any bundle, regardless of who made it, being consumed. Together they are the argument for the format.

Can a one-field standard actually matter?

The obvious critique writes itself: a standard whose only requirement is a type field is barely a standard at all. And there is truth to it, OKF does almost nothing to guarantee that your "person" concept and mine share any fields. But that is also why it has a shot. Heavy schemas are where interoperability standards go to die; everyone disagrees about the content model, adoption stalls, and the format that wins is the one loose enough that adopting it costs nothing. Markdown already won the docs war for exactly this reason. OKF is betting that the same minimalism travels to agent knowledge: give tools a predictable envelope and get out of the way. Whether it becomes the universal standard or just a good convention, the useful part, portable knowledge bundles agents can pass around, works today.

The honest caveats

It is v0.1 and it is Google's, which are two reasons to hold your enthusiasm. Vendor-neutral is the claim, but a format published by a hyperscaler with reference agents that walk BigQuery is not exactly disinterested, and the graveyard of "open" formats that quietly served one vendor's platform is well populated. The minimalism cuts both ways: because OKF standardizes so little, two OKF bundles can still be mutually unintelligible in practice, and real interop will depend on convention layers the spec does not define. And "standard" here means one company's proposal on GitHub, not something a body has ratified. Treat it as a strong, adoptable convention worth trying for your own knowledge base, not as a settled industry standard.

Key Takeaways

• Google Cloud's Open Knowledge Format (OKF v0.1, June 12 2026) is an open spec for storing knowledge as a directory of markdown files with YAML frontmatter, for AI agents to read, write, and exchange.
• It formalizes the LLM-wiki pattern Karpathy popularized, whose whole appeal is that LLMs maintain a markdown knowledge base without getting bored or dropping cross-references.
• The only required field on any concept is type: OKF standardizes the interoperability surface, not the content model, like a shipping-container standard for knowledge.
• Google ships two reference tools: an enrichment agent that generates OKF from a BigQuery dataset, and a static HTML visualizer that graphs any bundle.
• The minimalism is the bet and the risk: loose enough to actually get adopted, loose enough that two bundles may still not truly interoperate. It is a v0.1 vendor proposal, not a ratified standard.

Sources: GoogleCloudPlatform/knowledge-catalog (GitHub), Google Cloud blog, The Decoder