Skip to content

Module new 6 min

Open Knowledge Format

Google Cloud's June 2026 spec: knowledge as a directory of cross-linked markdown files with YAML frontmatter, readable by any agent without scraping.

Open Knowled…What OKF declares (one concept per file)OKF vs llms.txt vs schemaWhen publishing an OKF directory pays
v0.1 published by Google Cloud, June 2026, Apache-2.0; one required field, five recommended, two reserved filenames

Why it mattersThe first agent-readable content spec backed by a major platform; it formalizes the "markdown for machines" pattern llms.txt only gestured at.

01

Definition & Foundation

New in June 2026: for agents, not (yet) search

The Open Knowledge Format (OKF) is Google Cloud's attempt to formalize what llms.txt only gestured at: knowledge as a directory of cross-linked markdown files, one concept per file, each with YAML frontmatter. A product, a policy, an API, a metric: each gets its own file, and files link to each other with ordinary markdown links, so an agent can assemble context by following them wiki-style, with zero custom tooling. Published as v0.1 in June 2026 under Apache-2.0, it carries one required frontmatter field (type), five recommended ones (title, description, resource, tags, timestamp), and two reserved filenames: index.md for a folder's contents and log.md for its change history.

The critical framing: OKF was built for the "context assembly problem" faced by coding, research, and enterprise agents, not as an AI-search retrieval signal. No answer engine treats OKF as a ranking or retrieval input today. So the honest GEO position mirrors llms.txt: adopt OKF if you have agents that read your content directly (internal tools, partner integrations, coding assistants consuming your docs), and treat any future search upside as a free option, which is why, like llms.txt, it earns no impact score yet.

02

The Spec, and How It Compares

What OKF declares, and where it sits next to llms.txt and schema

the core rule

One concept per file

Each markdown file describes exactly one thing: a product, policy, API, or metric. This is the same "self-contained unit" instinct as passage optimization, applied to a whole knowledge base: an agent grabs the file it needs without parsing an entire site.

the metadata

YAML frontmatter

One required field, type, plus five recommended ones (title, description, resource, tags, timestamp) and any producer keys you invent. Deliberately minimal, and forgiving by design: a conformant consumer must never reject a bundle over an unknown type, an unknown key, or a broken link. Low ceremony is the point; it is what lets a spec survive contact with real adoption.

context assembly

Wiki-style cross-links

Files reference each other with plain markdown links, so an agent follows them to build context on demand: no bespoke API, no scraping. This is the actual innovation: it solves how an agent assembles what it needs, not how a search engine ranks you.

index.md & log.md

Reserved files

Two filenames are special. index.md lists what lives in a folder, so an agent reads the map before drilling into details (progressive disclosure); log.md records changes newest-first. Everything else is a concept. It is the "clean table of contents plus a changelog" instinct, written for a machine reader instead of a human one.

there is no discovery

Loaded, not crawled

A bundle is not something an engine spiders. There is no official discovery mechanism: you tell a named agent where the directory is (a link from llms.txt, a /.well-known/okf pointer, or an agent config path). That single fact is why "publish it and wait for AI traffic" misreads the format entirely.

pick the right tool

OKF vs llms.txt vs schema

Schema annotates facts inside your public HTML for search engines (proven, used today). llms.txt is an informal content map (unproven). OKF is a structured knowledge directory for agents (new, vendor-backed, agent-focused). They layer; they don't replace each other.

03

Myths vs Reality

Common misreadings, corrected

Myth"Google published OKF, so publishing an OKF directory will boost our AI Overviews."
RealityOKF is a Google Cloud spec for agent context assembly, explicitly not an AI-search signal; its first consumers are coding, research, and enterprise agents. AI Overviews still run on the Search index via Googlebot. Adopt OKF for agents that read you directly, not for a search lift that doesn't exist yet.
Myth"OKF replaces schema and llms.txt; we should migrate everything."
RealityThey serve different consumers: schema for search engines, OKF for agents assembling context, llms.txt as an informal hint. Keep the proven schema layer; add OKF where you actually have agents consuming your knowledge. Migration, not addition, would cost you the thing that works today.
Myth"If we publish an OKF bundle, agents and AI search will discover it."
RealityThere is no crawl and no discovery standard yet; bundles are explicitly loaded, not crawled. You point a named consumer at the directory. Publishing one on the open web is a deliberate early-mover bet, and a fine proof asset if you sell the work, but it is not a channel that fills itself. If you can't name who loads it, that is the free option, not the reason.
04

Putting It to Work

Adopt for agents you can name

OKF pays off when a real agent reads your content directly. The test before investing is simple: can you name the agent? If yes, publish a small, clean directory; if no, watch the standard mature. When you are ready to build one, our step-by-step walks the whole mechanism end to end: How to Create an OKF Bundle for AI Agents.

The agent-readable-knowledge playbook

1

Identify a concrete agent consumer

Do you have coding assistants reading your API docs, partner integrations pulling your specs, or internal agents querying your policies? A named consumer justifies OKF. "An AI search engine might use it someday" does not; that's the free option, not the reason.

2

Model your knowledge as one-concept files

Break the knowledge that agent needs into a directory of markdown files (one product, policy, API, or metric each) with the required type frontmatter and the reserved fields where they apply. Reuse your existing canonical facts and docs as the source.

3

Cross-link for context assembly

Connect related files with plain markdown links so an agent can traverse from a product to its pricing to its policies. The value is in the graph of links, not any single file; mirror the relationships your agent needs to answer real questions.

4

Keep it in the repo, versioned and fresh

Because OKF is just markdown files, it diffs cleanly in git and rides your normal review and deploy flow. Wire timestamps to real updates so agents can trust freshness, the same discipline as content freshness, applied to your knowledge directory.

5

Treat search upside as a free option

If an engine later adopts OKF as a retrieval signal, you're early, but don't budget for that. Invest to serve the agent you named today; log OKF in your standards-watch so you notice the day its status changes.

05

Works Together With

The nodes this one leans on

Tools for this from Technical GEO

Go deeper from Technical GEO

Always current

These links resolve live: what you get is generated or filtered the moment you click.

Sources