Industry

Google Cloud Publishes the Open Knowledge Format for AI Agents

Updated: RSS
A directory of Markdown files with YAML frontmatter headers flowing along data lines into a single AI agent node.
OKF represents curated knowledge as a directory of Markdown files with YAML frontmatter that AI agents can read. Illustration: AI-generated.

In June 2026, Google Cloud published the Open Knowledge Format (OKF), a draft open specification for representing curated organisational knowledge in a portable, vendor-neutral format that both humans and AI agents can read. It formalises the “LLM-wiki” pattern, inspired by Andrej Karpathy’s LLM Wiki concept, into a documented convention.

OKF is not a search or SEO standard. Google scopes it to a specific problem: the institutional knowledge that organisations need their AI agents to use is scattered across metadata catalogs, wikis, code comments, and people’s heads. OKF gives that knowledge a common representation so agents can consume it without a proprietary platform.

What is the Open Knowledge Format?

OKF v0.1 represents knowledge as a directory of Markdown files with YAML frontmatter. Each file describes one thing (a dataset, a table, a metric, a definition) and links to related files with ordinary Markdown links, producing a graph-like structure of curated context.

The design is deliberately minimal:

  • Just Markdown that renders in any editor or on GitHub
  • Just files that ship as a tarball or live in a git repository
  • Just YAML frontmatter with queryable fields such as type, title, description, resource, tags, and timestamp

Only the type field is required. There is no SDK, no new runtime, and no platform dependency, which is the point: a knowledge bundle written by one producer can be read by a different consumer’s agent without translation.

A bundle is just a folder. A sales knowledge base might look like this:

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

Each file pairs structured frontmatter with a human-readable body, and links to related files with ordinary Markdown links:

---
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
---

# Schema

| Column | Type | Description |
|--------|------|-------------|
| `order_id` | STRING | Globally unique order identifier. |
| `customer_id` | STRING | FK to [customers](/tables/customers.md). |

An agent can query the frontmatter as structured fields (find every file where type is BigQuery Table, or filter by tags) while still reading the Markdown body for context. The same file renders cleanly in any editor or on GitHub.

What did Google ship alongside the spec?

Google updated its Knowledge Catalog to ingest OKF and serve it to agents, and published reference tooling: an enrichment agent that auto-generates OKF documents from BigQuery datasets, a static HTML visualiser for browsing a bundle, and sample bundles built on the GA4 e-commerce, Stack Overflow, and Bitcoin public datasets.

Google is explicit that OKF v0.1 is “a starting point, not a finished standard,” and expects the format to evolve as more producers and consumers emerge and as practice shows what knowledge representations agents actually need.

Update: OKF v0.2 adds provenance and trust (July 2026)

On 24 July 2026 Google migrated the specification and its reference tooling to OKF v0.2, which makes provenance, trust, lifecycle and attestation first-class frontmatter rather than leaving them to the producer. The stated reason is that a knowledge corpus is now continuously written and maintained by agents rather than authored once, so a consumer needs to know what a concept derives from, how it was verified, and whether it is still current.

Two additions carry most of that weight. sources records the materials a concept derives from, with optional per-source IDs so individual claims can be attributed rather than the document as a whole. generated and verified record how the content was produced and who checked it, and a consumer derives a trust tier from the latter: unverified where verified is absent, machine-confirmed where only non-human actors signed off, and human-reviewed where a person did. A status field (draft, stable, deprecated) and a stale_after date cover lifecycle.

A fourth sample bundle, Acme Retail, exercises the new machinery: sanctioned SQL held as Attested Computations, executor instructions for running them, and deterministic attesters that check the resulting receipts.

Two v0.1 fields are superseded: timestamp gives way to generated.at, and the body # Citations list moves into frontmatter as sources. The example above is therefore v0.1 form. Nothing in v0.2 changes the format’s scope: it remains internal-knowledge infrastructure, and no AI platform has confirmed it reads externally published bundles.

Could OKF work for websites?

This is where OKF becomes interesting for publishers, though the framing comes from the SEO community rather than from Google. The format is structurally close to conventions already debated for the agentic web: a folder of Markdown files with frontmatter is not far from llms.txt or Markdown versions of pages served to agents. Commentators including Suganthan Mohanadasan and No Hacks have asked whether a site could publish an OKF bundle as an external, agent-readable knowledge layer, and there is already a request to support the format in the Hugo static site generator.

The case for caution is the same one that applies across agent-readiness. Google built OKF for internal data shared with an organisation’s own agents; nothing in the announcement positions it as a web-search or AI-citation signal, and no AI platform has confirmed it reads externally published OKF bundles at inference time. Treating it as a ranking or citation lever would repeat the mistake made with llms.txt: assuming that because a format is easy to publish and intuitively useful, agents must be consuming it.

What this means

For content and editorial sites, OKF changes nothing today. It is internal-knowledge infrastructure, not a visibility signal, and the website application is speculative extrapolation by practitioners, not a Google proposal.

Two reasons to track it. First, the pattern matters: OKF is another data point in a clear direction of travel, where Markdown-with-frontmatter is becoming the lingua franca for handing curated knowledge to AI agents, the same shape as llms.txt, agents.md, and content negotiation. Second, if an external use case does emerge, the cost of producing an OKF bundle from existing structured content is low. Until a major agent platform confirms it reads external bundles, OKF belongs in the watch column alongside the other draft conventions of the agentic web, valued for where it points rather than for any confirmed citation impact.

Sources

More news

Add as a preferred source on Google