Open Knowledge Format (OKF): Google's Standard for AI Agent Memory

On June 12, 2026, Google Cloud published the Open Knowledge Format (OKF) v0.1—an open specification that turns the emergent "LLM wiki" pattern into a portable standard for AI agent knowledge.

Sam McVeety (Tech Lead, Data Analytics) and Amir Hormati (Tech Lead, BigQuery) announced on the Google Cloud Blog:

OKF is a vendor-neutral, agent- and human-friendly standard for representing the metadata, context, and curated knowledge that modern AI systems need.

No new runtime. No required SDK. Just markdown files with YAML frontmatter in a directory—shippable in git, readable on GitHub, consumable by any agent.

@Karpathy's LLM Wiki gist (5,000+ stars) predicted this shape; Google formalized the interoperability layer. See our complete LLM Wiki guide. @DataChaz called it Google formalizing "the power of the LLM Wiki."

This post explains OKF's structure, design principles, what Google shipped, and how it fits alongside CLAUDE.md and agent skills.

TL;DR

The Problem OKF Solves

Foundation models improve faster than most organizations can assemble context. When an agent needs to answer "How do we compute weekly active users from our event stream?", the answer fragments across:

Every agent builder re-solves the same context assembly problem. Every catalog vendor reinvents schemas. Knowledge stays locked to the surface that created it.

OKF's bet: the missing piece is a format, not another platform.

What an OKF Bundle Looks Like

An OKF bundle is a directory of concept documents. File path = concept identity:

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

Each concept file:

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

# Joins

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

Markdown links turn the directory into a graph richer than filesystem hierarchy alone.

Reserved files

The full v0.1 spec—including conformance criteria—fits on one page.

Three Design Principles

1. Minimally opinionated

Only type is required. What types exist, what other fields to use, what body sections to include—producer's choice. OKF defines interoperability, not content models.

2. Producer/consumer independence

Same format, swappable tooling at each end.

3. Format, not platform

No proprietary account or SDK required to read or write. Value scales with adoption breadth, not vendor lock-in.

OKF vs Existing Patterns

OKF does not replace CLAUDE.md—it can contain the structured knowledge CLAUDE.md points at. Example: CLAUDE.md says "read /okf/sales/metrics/weekly_active_users.md before analytics tasks."

Compare to MCP for live tool access; OKF for curated static knowledge.

What Google Shipped

Reference producer: BigQuery enrichment agent

Walks a BigQuery dataset, drafts OKF concept docs for every table/view, then runs a second LLM pass to enrich with citations, schemas, and join paths from authoritative documentation.

Reference consumer: Static HTML visualizer

Turns any OKF bundle into an interactive graph view—single self-contained HTML file, no backend, no data leaves the page.

Sample bundles (on GitHub)

See our hands-on GA4 & Bitcoin sample bundle guide for starter SQL, dataset limitations, and how OKF maps raw tables to concept pages.

Cloud Knowledge Catalog integration

Google updated Knowledge Catalog to ingest OKF bundles and serve them to Google Cloud agents—enterprise path for teams already on GCP.

The Karpathy Connection

Andrej Karpathy's LLM wiki gist (5,000+ stars) argues:

LLMs don't get bored, don't forget to update a cross-reference, and can touch 15 files in one pass.

Humans abandon wikis when bookkeeping fails; agents excel at it. The pattern keeps reappearing—Obsidian + coding agents, AGENTS.md repos, index.md/log.md artifacts.

OKF's contribution: agree on what fields every document carries and what filenames mean, so your wiki and my wiki and a catalog export cooperate without translation.

Three-layer mapping (Karpathy → OKF)

Both reserve index.md (catalog) and log.md (change history). See the full LLM Wiki guide for ingest/query/lint operations and the implementation ecosystem (AutoSci, memwiki, secure-llm-wiki, synthadoc, and others).

Format wars context (from the gist community)

OKF v0.1 addresses interoperability first; contradiction semantics, trust tiers, and typed relationships remain open design space.

OKF vs Vector Search and RAG Pipelines

A natural question for anyone who has built a retrieval-augmented generation pipeline: why maintain hand-written markdown files at all when you could just embed everything and let a vector database handle retrieval?

The two approaches solve different problems, and most production agent stacks end up using both.

In practice, a mature agent knowledge stack layers both. OKF documents are small enough and important enough (a metric definition, a table schema, an incident runbook) that they belong in an exact, versioned, human-readable format—the same reasoning that keeps CLAUDE.md as plain markdown instead of a database row. Vector search remains the right tool for the long tail of unstructured content that nobody has time to manually curate into concept docs. Google's own BigQuery enrichment agent effectively bridges the two: it uses LLM-driven synthesis (closer to a RAG-style read of authoritative docs) to produce the curated, exact OKF output.

Writing Your First OKF Concept Document

The fastest way to understand OKF is to write one by hand. Here is a worked example for a metric—arguably the most common concept type teams reach for first, since "how do we calculate X" is the question that most often stalls an agent mid-task.

Step 1: Pick the file path. Concept identity is the file path, so metrics/weekly_active_users.md should live under the domain it belongs to (e.g., sales/metrics/), mirroring how your team already organizes dashboards.

Step 2: Write the frontmatter. Only type is mandatory, but a useful metric doc adds resource (a link to the dashboard) and tags for discovery:

---
type: metric
title: Weekly Active Users
description: Unique customers with at least one completed order in a trailing 7-day window.
resource: https://console.cloud.google.com/bigquery?p=acme&d=sales&t=weekly_active_users
tags: [sales, engagement, north-star]
timestamp: 2026-06-10T09:00:00Z
---

Step 3: Write the body with cross-links, not just prose. The value of OKF over a plain wiki page is that every reference to another concept becomes a graph edge an agent can traverse:

# Definition

A customer counts toward this metric if they have a row in
[orders](/tables/orders.md) with `status = 'completed'` and
`order_date` within the trailing 7 days.

# Known exclusions

Test accounts (see [customers](/tables/customers.md) `is_test` flag)
are excluded. Refunded orders still count—see `log.md` for the
2026-04-12 decision to keep refunds in this metric.

# Owners

Data platform team. Questions: #data-platform on Slack.

Step 4: Add a log.md entry. Because log.md is a reserved filename, an agent that has learned the OKF convention will check it automatically for context on why a metric changed—the refund-exclusion decision above is exactly the kind of tribal knowledge that otherwise lives only in a Slack thread nobody can search six months later.

Step 5: Validate with the visualizer. Drop the bundle into Google's static HTML visualizer to confirm the cross-links resolve into a connected graph rather than orphaned pages—a broken link here is the OKF equivalent of a 404 inside your own knowledge base.

This is deliberately unglamorous. There is no SDK to install and no new query language to learn—the entire skill is "write a markdown file with one required field and link it to its neighbors," which is precisely why Google is betting adoption will outpace more heavyweight metadata-catalog approaches.

Getting Started

Google's recommended path:

1. Read the spec — okf/SPEC.md (short)
2. Browse sample bundles — GA4, Stack Overflow, Bitcoin in repo
3. Try the visualizer — open a bundle in the HTML tool
4. Write a producer — export from your DB, docs site, or wiki
5. Write a consumer — agent that reads OKF before tasks; search index; viewer
6. Contribute — file issues, PRs; v0.1 designed for backward-compatible growth

For Claude Code users: OKF bundles mount like any markdown corpus—agents with file tools traverse index.md hierarchies naturally.

Open Questions (v0.1 Is a Starting Point)

Google explicitly calls v0.1 a starting point, not a finished standard:

• Contradiction handling — Two OKF docs disagree; no merge semantics yet
• Faceted search — Some practitioners want richer tagging than minimal spec
• Live vs static — OKF is file-based; stale docs are a process problem
• Name collision — Unrelated "OKF" supply-chain spec exists (OKF-SCIS); Google's OKF is data/analytics/agent knowledge

Community feedback will shape v0.2.

Who Should Care

Summary

Open Knowledge Format (OKF) v0.1 is Google's bid to make agent knowledge portable: markdown files, YAML frontmatter, markdown links as graphs, one required type field, no mandatory SDK.

It formalizes what Karpathy, Obsidian users, and CLAUDE.md authors already discovered—LLMs work better with curated, linked, maintainable markdown libraries than with repeated document search.

The spec is the contribution. BigQuery agent, visualizer, and sample bundles lower the cost of trying it. Whether OKF becomes lingua franca depends on producers outside Google adopting it.

Related Reading

• OKF Sample Bundles: GA4 & Bitcoin BigQuery Guide
• What Is an Obsidian Vault? — vault anatomy and self-writing agent pattern
• Karpathy LLM Wiki: Complete Pattern Guide
• What is CLAUDE.md? Persistent Memory in Claude Code
• What Are Agent Skills? Complete Guide
• What is MCP? Model Context Protocol
• Files.md: Private Local-First Note-Taking
• Agent Markdown Files Complete Guide
• Design.md: Open Spec for AI Design Systems

OKF v0.1 structure and tooling cited from Google Cloud Blog and GoogleCloudPlatform/knowledge-catalog as of June 14, 2026.