Google's Open Knowledge Format Explained: Is OKF the Future of AI Memory?

CLAUDE.md, AGENTS.md, GEMINI.md, every AI tool speaks a different language. OKF is Google's fix for portable AI memory.

Google's Open Knowledge Format Explained

You're Paying an AI Tax, and You Didn't Even Get a Receipt

Every time you re-explain your project to a fresh AI session, you're paying an invisible tax, and you've been paying it for months.

Picture it. You just wrapped a three-hour planning session with your AI coding agent. Architecture, API conventions, naming standards, the deployment pipeline, you laid it all out. The agent delivered. Beautiful work. You feel like a genius.

Tomorrow, you open a new session.

You explain it all again.

Then you switch to Codex. Again. Cursor? Again. Gemini? Again. Each one staring back at you like a golden retriever that's never seen you before in its life.

That's the AI tax. Not the API bill, the context bill. The invisible cost of re-explaining everything your AI should already know, over and over, to every tool you touch. Run any serious agentic workflow, and it quietly eats hours every week.

Google noticed. On June 12, 2026, they shipped their answer: Open Knowledge Format (OKF) v0.1, a vendor-neutral, agent-readable spec for packaging an organization's knowledge in a format any AI can read. No translation. No plugins. No starting from scratch.

Sounds modest.

It's a bigger deal than the launch post lets on.

The Real Problem: Your AI Has the Memory of a Goldfish

AI agents are stateless by design; every conversation is a fresh case of amnesia, and the whole industry has been duct-taping around it.

Here's what's actually broken. Each conversation starts as a blank slate. So developers invented a workaround: cram the relevant context into a file at the start of every session. Clever. Fragile. Very human.

That's where CLAUDE.md came from Anthropic's convention for handing Claude a persistent project context. Then OpenAI's Codex got AGENTS.md. Cursor rolled its own memory folder format. Gemini CLI showed up with GEMINI.md.

Every tool has its own format. None of them on speaking terms.

The result is a patchwork held together by hope:

Claude reads CLAUDE.md but ignores your Codex setup
Codex reads AGENTS.md but has no clue about your Cursor rules
Gemini reads neither, so you paste everything in by hand like it's 2022
Every new agent or teammate starts cold

This isn't just annoying. It actively caps the sophistication of your workflows.

Reality check: You cannot build a multi-agent pipeline, Claude on architecture, Codex on implementation, and a third agent on deployment if all three are working from different, incompatible pictures of your project. That's not a pipeline. That's three strangers arguing in a trench coat.

And it gets worse the bigger you scale. None of these formats was designed to grow up.

A CLAUDE.md file starts life at a tidy 50 lines. It ends up at 500. It becomes a monolith hard to search, miserable to maintain, and expensive to load, because every token in that file burns the context window every single session. You're paying rent on knowledge that the agent uses maybe 10% of the time.

But What About RAG?

RAG (Retrieval-Augmented Generation) was supposed to ride in and fix all this. It didn't. It just brought different problems.

RAG re-derives answers at query time by retrieving raw document chunks and synthesizing them on the fly. It doesn't accumulate knowledge. It just searches better.

Andrej Karpathy, OpenAI co-founder and one of the most influential voices in applied AI, nailed the limitation in his April 2026 GitHub gist. RAG, he said, is like cooking a meal from scratch every time you're hungry.

Nothing compounds. Nothing sticks. You're brilliant for exactly one query, then back to zero.

Karpathy Lit the Match (The Whole Thing Started With a Gist)

Before Google formalized anything, one throwaway GitHub gist quietly rewired how people think about AI memory.

In April 2026, Andrej Karpathy published a gist titled, with maximum drama, "llm-wiki."

It wasn't a product. It was an idea file. Barely a page long. The kind of thing most people scroll past.

The concept: instead of pointing agents at raw documents and letting them re-retrieve chunks on every query, have the LLM compile those documents into a structured, interlinked Markdown wiki. Then query the wiki. New information arrives? Update the wiki. Let knowledge compound instead of evaporating.

The architecture was almost insultingly simple:

Three layers of raw sources, the wiki, and a schema file like CLAUDE.md
Three operations: ingest, query, lint

That's the whole thing.

The gist crossed 5,000 stars in two weeks. Dozens of open-source implementations appeared. VentureBeat covered it. Commercial products started quietly repositioning to pretend they'd thought of it first.

Why did it hit so hard?

Because it named something developers had been feeling but couldn't say out loud: the difference between retrieving information and knowing it. A compiled wiki doesn't just find the answer. It already understands the question.

Karpathy's sharpest observation was this: LLMs don't get bored. They don't forget to update cross-references. They can edit fifteen files in a single pass without sighing once.

Translation: The tedious bookkeeping that makes humans rage-quit their personal wikis is exactly the part LLMs are freakishly good at. The maintenance economics flip completely.

Google watched this play out and recognized the pattern surfacing everywhere under different costumes: Obsidian vaults wired to coding agents, AGENTS.md convention files, "metadata as code" repos. Each one bespoke. None of them is interoperable.

That's the mess OKF is trying to clean up.

What OKF Actually Is (And What It Absolutely Isn't)

OKF is a portable AI context, a standard way to package what a project knows, so any agent from any vendor can read it. It is not "documentation," and confusing the two misses the entire point.

Let's be precise, because the lazy instinct is to file OKF under "docs" and move on.

Don't.

OKF is a standardized way to package what a project, team, or organization knows, so that any agent from any vendor can read and use it, without translation.

And the format is aggressively, almost suspiciously simple. An OKF bundle is just a directory of Markdown files:

knowledge/
├── index.md
├── systems/
│   ├── database.md
│   ├── network.md
│   └── architecture.md
├── apis/
│   ├── billing-api.md
│   └── customers-api.md
└── playbooks/
    └── incident-response.md

Each file is a single concept: one table, one metric, one API, one runbook. Every file gets a small YAML front-matter block:

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

That's it. The entire spec demands exactly one mandatory field: type. Everything else is recommended but optional.

No compression scheme. No proprietary SDK. No required account. No backend humming in some data center, billing you by the hour.

An OKF bundle renders on GitHub, ships as a tarball, and mounts on any filesystem. It's Markdown with agreed-upon manners.

The Actual Clever Bit

Here's the insight people miss:

Google didn't invent Markdown. They invented the conventions around Markdown.

The structure. The naming. The linking pattern. The reserved filenames index.md are the entry point log.md for the change history. Those are the contributions.

Concepts cross-link to each other with standard Markdown links, and that's your relationship graph. No graph database. No proprietary link syntax. No PhD required.

| customer_id | STRING | FK to [customers](/tables/customers.md). |

That one cross-link turns a flat directory into a navigable knowledge graph.

Simple. Durable. Human-readable. Git-diff-able. The four adjectives enterprise software usually forgets exist.

The Lineage: Google Didn't Start This (And, Refreshingly, Admits It)

The most honest thing about OKF is that Google copping to the fact that they invented none of it, they're standardizing a pattern the community already converged on.

Here's the actual timeline:

The industry didn't sit around waiting for Google. It invented a dozen incompatible versions of the same idea first, and now Google is trying to promote the best one as a shared standard.

That's not a criticism. That's literally how good standards get made.

HTML didn't fall out of the sky. It formalized what people were already hacking together with SGML and hypertext. OKF wants to be the HTML of AI context, the layer of agreement that makes knowledge portable across tools, teams, and vendors.

Ambitious? Sure. But someone has to be.

OKF vs. What You're Already Using

Concrete comparison time because "it's better" is what every vendor says right before it isn't.

CLAUDE.md is fantastic for getting started. It falls apart the moment your project gets complex, your team grows, or you dare to use more than one agent.

The cleanest summary:

LLM-Wiki is an idea. OKF is a specification.

The good news for anyone already running the pattern: you can make an existing LLM-Wiki-style wiki OKF-conformant in about a morning. Mostly, you're just adding YAML front-matter and a type field. That's it. That's the migration.

The Knowledge Maturity Model (Or: Which Rung Are You Stuck On?)

Most teams are sitting on Stage 2 long after they've outgrown it, carrying all the pain of scale with none of the architecture.

The most useful way to understand OKF is to see where it fits within how teams evolve their AI context. It's a ladder:

Most developers are parked at Stage 2. OKF is Stage 4.

This isn't about replacing what came before. It's about matching the tool to the job:

Solo personal project → README is fine
Claude-heavy single project → CLAUDE.md is right
Growing project, one team → LLM-Wiki pattern is worth adopting
Multiple agents, multiple tools → OKF is where you want to be
Enterprise-scale, hundreds of projects → You're wandering into Knowledge Graph / GBrain territory

Here's the trap most teams fall into.

They stay at Stage 2 long after they've outgrown it. A bloated 300-line CLAUDE.md is Stage 2 cosplaying as Stage 4, all of the pain, none of the architecture.

Sound familiar? It should.

OKF vs. GBrain: Storage vs. Cognition

OKF stores knowledge. GBrain reasons over it. Confusing those two is like confusing a bookshelf with a librarian.

This distinction is worth nailing down, because it's easy to blur.

An OKF bundle can tell you: "Here's the schema for the Orders table. Here's the billing API spec. Here's the incident runbook for database failures."

Useful. Static. A library.

GBrain's longer-horizon organizational intelligence layer can answer the questions that actually keep engineers up at night:

Who owns this API?
What changed in the last sprint?
Which docs just went stale because of this migration?
Which three engineers should review this PR based on the dependency graph's ownership?
Which projects break downstream?

One is a library. The other is a librarian who's read every book, remembers who checked out what, and notices when a chapter contradicts itself.

**OKF vs. GBrain: Storage vs. Cognition**

Here's why this matters even if GBrain sounds like distant sci-fi.

OKF is the right foundation to build toward it. Structure your team's knowledge in OKF bundles today, and feeding it into a reasoning layer tomorrow gets dramatically easier.

Good formats create good options. Bad formats create migration projects nobody volunteers for.

OKF with Claude Code, Codex, and Multi-Agent Systems

Here's the part that should make anyone running serious agentic workflows sit up: none of these agents need to "support" OKF. It just works.

The elegant trick neither Claude Code nor Codex nor any other major agent requires native OKF support. They just read Markdown files in the project context.

OKF works because it's plain Markdown with predictable structure. Not because of some special runtime handshake or a partnership press release.

A practical project layout:

project/
├── CLAUDE.md          ← points to .okf/index.md
├── AGENTS.md          ← also points to .okf/index.md
└── .okf/
    ├── index.md
    ├── architecture.md
    ├── api.md
    ├── database.md
    └── deployment.md

Your CLAUDE.md shrinks to a one-liner:

@.okf/index.md

So does your AGENTS.md. Now Claude, Codex, Gemini, and Cursor are all drinking from the same well. One update propagates to every agent. No more context files quietly drifting out of sync while you're not looking.

The Claude Code workflow becomes:

Work with the agent as normal
At the end of the session, update the relevant OKF concept files with what changed
Commit the OKF bundle alongside your code
Next session, any agent, any tool, picks up right where you left off

Where It Gets Genuinely Interesting

For multi-agent pipelines, this is the whole ballgame. Picture an orchestrated system:

Hermes (or your AI Ops Manager) reads the OKF bundle to understand system architecture and orchestrates work accordingly
Claude Code implements features while consulting the same shared knowledge
OpenAI Codex generates code with the OKF API specs loaded as context
A deployment agent follows the OKF runbook for your deployment pipeline

Every agent operates from the same ground truth. API spec changes? One file update propagates to all of them.

That's not just convenient. That's the difference between a collection of AI tools and an actual coordinated system.

For OpenClaw and agentic workbenches specifically, OKF serves as the shared memory layer that enables real multi-agent coordination. Instead of every sub-agent hoarding its own partial picture of the world, the OKF bundle serves as the authoritative shared state that every agent reads from and writes to.

No more agents confidently disagreeing about basic facts. Well, fewer of them, anyway.

Best Practices Worth Following

OKF's simplicity is also its trap; it's dead easy to adopt the format while completely violating its spirit.

A few principles separate useful OKF bundles from expensive Markdown clutter.

Keep concepts small. One file, one idea. If a file is getting long, it's probably two concepts pretending to be one. Agents load individual files a 10KB file burns context; ten 1KB files give you surgical precision.

Link everything. Cross-links are the relationship model. And orders.md that doesn't link to customers.md an island. Islands don't compound. Islands just sit there.

Never duplicate information. If the same fact lives in two files, you've created two maintenance burdens. When the fact changes, and it will, you'll update one and forget the other. Guaranteed.

Treat docs like code. OKF lives in git. Changes are pull requests. Reviews are required. A stale OKF bundle is worse than no bundle it actively lies to your agents with total confidence.

Update automatically. The best implementations hook OKF updates into the CI/CD pipeline or Claude Code's post-task workflow. Knowledge that depends on a human remembering to update it is knowledge that will be wrong by Thursday.

Common mistakes to avoid:

❌ One giant OKF file (congratulations, you reinvented the monolith)
❌ Auto-generating content without curation (garbage in, garbage out, agent confidently repeating the garbage)
❌ Files with no cross-links (that's a folder of docs, not a knowledge graph)
❌ No ownership metadata (who maintains this? when was it last verified? "nobody" and "never" are not answers)
❌ Documenting everything indiscriminately (capture what agents need, not your entire corporate autobiography)
❌ Never pruning (a knowledge base that only grows eventually becomes noise with good posture)

Why This Actually Matters

The practical impact of OKF is bigger than it looks, and it's all in the second-order effects nobody puts in the launch post.

Context is the new code. An AI agent's output is only as good as its context. We're deep in the era of "context engineering," curating what the agent knows before it starts working. OKF gives that practice a scalable structure, rather than a Markdown file that metastasizes.

Vendor lock-in is a real risk, not a talking point. Invest heavily in a custom CLAUDE.md system, then decide to switch primary agents, and you're migrating everything by hand. An OKF bundle is vendor-neutral by design. It's a hedge against the platform shifts that are absolutely coming in a market moving this fast.

Multi-agent systems need a shared state. The next phase of AI isn't single agents getting smarter. It's networks of agents collaborating on complex tasks. Networks need shared memory. OKF is a credible early answer to what that memory format looks like.

Knowledge compounds. This is the Karpathy insight at OKF's core, and it's the whole point: instead of paying the AI tax every session, you invest once in curating a knowledge bundle and redeem that investment forever.

Every session starts smart. Every agent starts informed. The value accumulates instead of evaporating.

That should bother you in a good way about how much time you've already burned doing it the other way.

What's Coming Next

OKF v0.1 is explicitly a starting point, not a finished standard, and Google, to its credit, isn't pretending otherwise.

Google's been direct about the gaps: no merge semantics for conflicting updates, no built-in search behavior, no live data support. Version 0.2 will be shaped by community feedback.

The real test isn't the spec. It's whether the broader ecosystem, Anthropic, OpenAI, Cursor, and the open-source crowd adopt it or fragments even further.

And the stakes are high.

The AI tooling space is at an inflection point. We've all felt the pain of incompatible context formats. The question is whether the industry converges on a shared standard like HTML for the web, or OpenAPI for REST APIs, or keeps splintering into tool-specific silos, each convinced its silo is special.

If OKF gains real adoption, the second-order effects get significant:

Enterprise AI governance gets a clear, auditable knowledge layer one that lives in git, reviews as PRs, and travels with the code
AI agent marketplaces can ship knowledge bundles alongside their agents, gutting integration work
Knowledge portability becomes a default assumption instead of a wishlist item
Organizational intelligence layers like GBrain get a clean, standardized input format to reason over

There's also the wilder open question: do AI agents start generating and maintaining OKF bundles autonomously, not just reading them?

It's not hypothetical. The reference implementations Google shipped include an enrichment agent that walks a BigQuery dataset and automatically drafts OKF concept documents.

That's a preview of something much larger: AI-maintained, AI-readable, human-verified organizational memory. Memory that updates itself while you sleep and doesn't demand a receipt every morning.

The Takeaway

The industry quietly converged on the same idea from six different directions, and Google is just the one writing it down.

Developers building with Claude invented CLAUDE.md. Developers building with Codex invented AGENTS.md. Karpathy articulated the underlying pattern. Dozens of open-source implementations proved it worked.

Google is simply trying to take what the community already figured out and turn it into something every team doesn't have to reinvent from scratch.

That's what good standards do. They don't replace innovation. They provide a stable foundation to build on.

So here's the real question. If you're running multi-agent workflows today, it isn't whether you need portable AI context. You already do. You're just managing it badly, probably in a monolithic Markdown file that doesn't travel and doesn't scale and quietly judges you every time you open it.

The spec is 451 lines. It has one required field. It works with tools you already own.

The only real question left is whether you organize your agents' knowledge before the complexity forces your hand or after it's already made a mess you get to clean up.

You know which one's cheaper.