What is the Open Knowledge Format (OKF)? Google's Markdown standard for AI agents

On 12 June 2026, Google Cloud’s data team published the Open Knowledge Format (OKF), an open specification for representing a body of knowledge as a directory of Markdown files. No new product, no SaaS, no SDK: and that’s exactly what makes it interesting. At a time when every vendor tries to lock you into its platform, Google publishes a format that nobody owns: Markdown, files, full stop.

This article explains what OKF is, how it’s structured, why it lands at just the right moment for AI agents, and what sets it apart from a knowledge graph or a tool like NotebookLM.

The problem OKF sets out to solve

When an AI agent has to answer a business question (“compute weekly active users”), it assembles its answer from fragmented sources: a metadata catalog here, a wiki there, comments in the code, a metric definition in a spreadsheet. Each agent reinvents this gleaning work, and each organization structures it differently.

OKF formalizes an already-emerging pattern that Google calls the “LLM-wiki” pattern: a curated knowledge library, written once, that any agent can consult. The core idea is to cleanly separate producer from consumer: whoever writes the knowledge needn’t know who will read it, and vice versa (Google Cloud Blog, How the Open Knowledge Format can improve data sharing).

The structure: just files, just Markdown

An OKF bundle is a directory of Markdown files, organized by concept. A concept is anything you want to capture: a table, a dataset, a metric, a runbook, an API, a novel’s character. The founding rule: the file path is the concept’s identity.

sales/
├── index.md
├── datasets/
│   ├── index.md
│   └── orders_db.md
├── tables/
│   ├── index.md
│   ├── orders.md
│   └── customers.md
└── metrics/
    ├── index.md
    └── weekly_active_users.md

Three properties follow, and that’s all there is to OKF:

Just Markdown: readable in any editor, rendered on GitHub, indexable by any search tool.
Just files: deliverable as a tarball, hostable in a git repository, mountable on a filesystem.
Just YAML frontmatter: for the few structured fields you want to be able to query.

No exotic compression, no runtime, no database. If you can write a .md file, you can produce OKF.

The frontmatter: a single required field

Each concept document carries a YAML frontmatter at the top. And here OKF makes a radical choice of simplicity: a single field is required:

---
type: BigQuery Table
title: Orders
description: One row per completed customer order.
resource: https://console.cloud.google.com/bigquery?p=acme&d=sales&t=orders
tags: [sales, revenue]
timestamp: 2026-05-28T14:30:00Z
---

type: the only required field. It describes the nature of the concept (table, metric, character, endpoint…). It’s what lets an agent know what it’s reading without guessing.
title, description, resource, tags, timestamp: optional standard fields. resource points to the real resource (URL), timestamp dates the last update in ISO 8601.

Beyond these fields, producers define their own. The specification dictates neither the available types, nor the content model, nor the body’s sections. It is, in Google’s words, “minimally opinionated”.

Cross-links: a graph with ordinary Markdown links

This is the element that turns a folder of files into a knowledge base. Concepts link to each other with plain Markdown links:

| `customer_id` | STRING | Foreign key to [customers](/tables/customers.md). |

Joined with [customers](/tables/customers.md) on `customer_id`.

The result is a graph of relationships richer than the filesystem’s simple parent/child hierarchy. An agent reading orders.md discovers, by following the link, that a customers table exists and how they join, without anyone having to explain it in the prompt.

Reserved files: `index.md` and `log.md`

The specification reserves two filenames, both optional:

index.md: enables progressive disclosure. As an agent descends the hierarchy, each folder’s index.md gives it an overview before diving into individual concepts.
log.md: a chronological history of changes made to concepts.

The full specification, conformance criteria, cross-linking rules and reserved names included, fits on a single page (official specification, GoogleCloudPlatform/knowledge-catalog).

”Format, not platform”

This is the guiding principle, and it’s worth pausing on. Google insists: OKF is vendor-neutral. No proprietary account, no imposed cloud, no required SDK. An OKF bundle:

survives the move between systems, organizations and tools;
versions with git, alongside the code it describes;
is readable by humans and machines in the same file, with no translation layer.

Google even provides reference implementations to bootstrap the ecosystem: an enrichment agent that walks BigQuery databases to generate LLM-enriched OKF, a static HTML viewer (a single standalone file, no backend) that renders a bundle as a browsable site, and sample bundles (GA4 e-commerce, Stack Overflow, Bitcoin).

OKF, knowledge graph, NotebookLM: three different things

The confusion is common. Let’s untangle it.

OKF vs knowledge graph

A knowledge graph is an abstract data model: entities and relationships, often stored in a graph database (RDF triples, properties, etc.). OKF is a concrete file format that can express relationships via Markdown links. One is a theory of data, the other is a way to write it to disk. You can serialize part of a knowledge graph into OKF, but they aren’t the same objects.

OKF vs NotebookLM (or any other application)

NotebookLM is an application: you upload documents, you ask questions in its interface, and everything stays with Google. OKF is a format: it defines how to structure files so any tool can read them.

These two things are orthogonal. You can perfectly well drop an OKF bundle into NotebookLM. But you can also hand it to Claude, to GPT, to a homemade agent, to a Python script, without being locked into a platform. The real question is: do you want an interactive question-and-answer session (an application does that well), or a portable, programmatic knowledge base that agents can traverse, that you version with git, and that lives alongside your code or your texts? OKF answers the second.

The right moment, the right level of ambition

OKF arrives precisely where the need is felt: AI agents everywhere, and nowhere a simple way to give them curated context. Google chose to publish early and light, a one-page spec rather than a three-year standards committee, and that’s good news. The format is already usable today, and designed to grow cleanly:

The type catalog, free by default, lets each domain invent its vocabulary before the most useful conventions establish themselves.
Interoperability is the central promise: a wiki written by one, consumed by another without a translator. That’s exactly what a bare file format makes possible.
The versioning of the specification is designed from the start to stay backward-compatible.

In short

OKF = a directory of Markdown files + YAML frontmatter, published by Google Cloud on 12 June 2026 to give curated context to AI agents.
A single required field: type. The rest (title, description, resource, tags, timestamp) is optional; producers add their own fields.
Concepts link through plain Markdown links, forming a graph. Optional reserved files: index.md, log.md.
Format, not platform: no SDK, versionable in git, readable by humans and machines.
Different from a knowledge graph (abstract model) and from an application like NotebookLM (platform): it’s a format portable from one tool to another.

OKF shifts the question from “which tool consumes my knowledge?” to “is my knowledge written in a format that any tool can read?”. And since that format is nothing but tidy Markdown, any Markdown editor, like Draft_, can already serve to produce it.