Google’s OKF Isn’t Replacing RAG. It’s Replacing Something Else.

I have spent the better part of a year building RAG pipelines. Vector databases, embedding models, rerankers, chunking strategies, evaluation frameworks. And then Google announced OKF. It is a folder. Of markdown files. And I cannot stop thinking about it.

On June 12, 2026, Google Cloud published something called the Open Knowledge Format, or OKF. No new model. No new database. No SDK to install, no account to create, no API key to manage. Just a specification for how to write organizational knowledge as markdown files with a few structured fields at the top.

If that sounds underwhelming, I thought so too. And then I actually sat with the problem it is trying to solve, and I finally understood why the simplicity is the entire point.

The Problem Nobody in AI Engineering Talks About Loudly Enough

Here is a scenario every AI engineer has lived through at least once.

You are building an agent that needs to answer questions about your company’s data. “What does the weekly_active_users metric actually count?" "Which table do I join to get order revenue?" "What does the status column in the events table mean?"

The answer to each of these questions exists somewhere. In the data catalog that one team maintains but nobody else can access. In the Notion wiki that another team wrote three years ago and mostly stopped updating. In a Confluence page that only the senior data engineer knows about. In a Slack thread from six months ago that nobody archived. In the head of the person who originally built the pipeline and has since left the company.

Your agent cannot answer these questions reliably because the knowledge it needs is scattered across incompatible systems that were never designed to talk to each other. So you do what everyone does. You build a RAG pipeline. You ingest every document you can find, chunk it, embed it, and hope the retrieval step surfaces the right piece at query time.

And it mostly works. Until it does not. Until the agent retrieves a stale wiki page and confidently returns the wrong metric definition. Until the chunking splits a table schema across two chunks and the model only gets half the picture. Until the same unchanging context gets re-retrieved thousands of times a day and your vector search bill quietly climbs toward something you have to explain in a meeting.

Every time a new AI agent is built, teams are forced to solve the exact same context-assembly problem from scratch. When I read that line in Google’s official announcement, I stopped scrolling. Because it is not an abstract engineering observation. It is an accurate description of something I have personally done, and watched other engineers do, on repeat for the past year.

OKF is Google’s answer to this. And the answer is disarmingly simple: stop re-deriving what you already know. Write it down once, in a format that anyone and anything can read, and let agents use it directly.

What OKF Actually Is

An OKF bundle is a directory of markdown files representing concepts: anything you want to capture, including tables, datasets, metrics, playbooks, runbooks, and APIs. Each concept is one file.

Each file has two parts. A small YAML block at the top for structured, queryable metadata:

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

And then a plain markdown body below it where you write everything else. Schema definitions. Example queries. Edge cases. Join paths. Deprecation notices. Anything that belongs with this concept and would be useful to a human or an agent reading it six months from now.

Concepts link to each other with normal markdown links, turning the directory into a graph of relationships that is richer than the parent-child links implied by the file system.

The only required field is type. That is it. One field. Everything else is optional by design.

Google calls this “format, not platform,” and they back it up with three principles: minimally opinionated, meaning the spec defines the interoperability surface not your content model; producer-consumer independence, meaning knowledge can be written by a human, generated by a pipeline, or synthesized by an LLM, and consumed by anything that can read markdown; and no lock-in, ever, meaning it will never require a proprietary account or SDK.

The idea itself traces back to AI researcher Andrej Karpathy, who in April 2026 articulated what he called the “LLM Wiki” pattern. His core observation: instead of having AI search raw documents on every single request, have the AI incrementally build and maintain a persistent, living wiki. LLMs do not get bored, do not forget to update a cross-reference, and can update fifteen files in a single pass. The bookkeeping that causes humans to abandon personal wikis is exactly the kind of task LLMs are built for. OKF takes that pattern and gives it a standard format so it works across teams, tools, and organizations without any translation layer in between.

RAG Has a Blind Spot. Here Is Exactly What It Is.

I want to be careful here because I have seen takes calling OKF “the RAG killer” and that framing is both lazy and inaccurate. RAG is not being replaced. It is being exposed for solving problems it was never designed for.

RAG is genuinely excellent at what it was built to do. When you have thousands or millions of unstructured documents and you need to dynamically find the right pieces based on an unpredictable user query, RAG is the right architecture. That retrieval problem is real and RAG solves it well. Nothing in OKF changes that.

But here is where RAG quietly breaks down in production.

RAG treats everything as a search problem, including things that are not search problems. If your agent needs to know what weekly_active_users means, that is not a retrieval problem. That is a lookup problem. The answer is known, stable, and should be identical every single time an agent needs it. Running vector search to retrieve that answer on every query is the engineering equivalent of Googling your own phone number every time someone asks for it. You already know it. Write it down once.

RAG re-derives knowledge it could have simply stored. RAG re-derives knowledge at query time from raw chunks. An OKF bundle stores curated, cross-linked concepts that an agent reads and updates directly. Re-deriving costs time and compute. More importantly, re-deriving from unstructured text introduces variance. The same question can pull slightly different chunks on different runs, producing slightly different answers. For stable organizational facts, that inconsistency is not an acceptable trade-off. It is a reliability failure.

RAG has no portability layer. Knowledge is often scattered across catalogs, wikis, repositories, shared drives, and other internal systems. Every team builds their own ingestion pipeline for each of these sources. Nothing is portable between teams. Nothing is reusable between agents. A RAG system built by the data team cannot share its knowledge base with an agent built by the platform team without significant custom integration work. OKF is specifically designed to make that portability the default, not the exception.

The Comparison That Actually Matters

The table below is the clearest way to see where each approach belongs.

What OKF Solves That RAG Structurally Cannot

The deepest thing OKF addresses is not retrieval quality or cost. It is the interoperability problem, and it is a problem the AI engineering community has been quietly working around for years without a clean solution.

Think about what becomes possible if OKF achieves real adoption. Your data team writes OKF files for every table and metric in your warehouse. Your engineering team writes OKF files for every API endpoint and runbook. Your product team writes OKF files for every core domain concept. Any agent, from any team, using any framework, reads that knowledge directly. A new agent built six months from now by a completely different team inherits all of it for free. A vendor ships you their catalog as an OKF bundle and your agent consumes it without a single line of integration code.

The most important word in the announcement is not. OKF is not tied to a cloud, a database, a model provider, or an agent framework. That vendor-neutrality is not a nice-to-have. It is the entire value proposition. If OKF achieves the adoption its design deserves, it becomes for AI agents what HTTP became for the web: the shared language layer that makes everything above it interoperable without anyone having to negotiate a custom integration.

Google has already started moving in this direction. Knowledge Catalog can now natively ingest OKF. They also shipped concrete reference implementations alongside the spec: an enrichment agent that walks a BigQuery dataset and drafts OKF concept documents for every table and view, a static HTML visualizer that renders any OKF bundle as an interactive knowledge graph with no backend required, and three live sample bundles built from GA4 e-commerce, Stack Overflow, and Bitcoin public datasets.

What OKF Does Not Solve

I would be doing you a disservice if I stopped at the upside. Here is where the spec is genuinely incomplete right now.

It is v0.1 and the ecosystem is essentially empty. Google published OKF v0.1 on June 12, 2026, describing it as a starting point rather than a finished standard. Outside of Google’s own reference implementations, there are no mature libraries, no established community patterns, no LangChain loader, no LlamaIndex reader. Adopting it today is a real early-mover bet, not a safe production choice.

Curation is still human work. OKF does not generate itself from raw documents. An AI can draft the files and a human has to verify them, decide what concepts matter, and keep them current over time. That work does not disappear, it just changes shape. For teams without a culture of maintaining documentation, this is a real adoption barrier.

There is no shared type taxonomy yet. Nobody has agreed yet on what the types should be. There is no shared taxonomy. One team’s “Article” might be another’s “BlogPost” and someone else’s “Page”. Until conventions settle, two OKF bundles from two producers will not necessarily speak the same language, even though both are technically valid. This is the spec’s deepest unsolved problem. The interoperability promise hinges entirely on producers using compatible types, and right now there is nothing enforcing or even recommending that.

Adoption is genuinely unknown. A format standard is only as valuable as the number of systems that speak it. If adoption stays within Google’s own tooling, OKF is not a standard. It is a convention. The real question is whether LangChain, LlamaIndex, Weaviate, or any of the major open source frameworks ship native OKF support in the next six to twelve months. That is the signal worth watching.

My Take After a Year of Building RAG in Production

I built TraceIQ as a production RAG platform with hybrid retrieval, cross-encoder reranking, and multi-query expansion. I know what a well-engineered RAG pipeline looks like and I know where it quietly fails over time.

And here is what I keep coming back to: a meaningful portion of the retrieval load in most production RAG systems is not retrieval at all. It is lookup. The same table definitions, the same metric explanations, the same domain glossary, being re-retrieved thousands of times a day because there was never a better place to put them.

OKF is not a revolution. It is Google formalizing something that thoughtful engineering teams were already doing informally in Notion, Obsidian, or Confluence, and making it interoperable by specification rather than by luck. The insight that you should maintain a living, structured wiki rather than re-search raw documents on every query is not new. What is new is the standard format that makes that wiki readable by any agent without custom integration.

The architecture that actually wins long term is not RAG or OKF. It is both together, each doing what it is actually designed for. OKF for stable, high-frequency, curated organizational knowledge. RAG for large, dynamic, unstructured corpora that cannot be pre-organized. The mistake is using a search engine for lookup problems, or expecting a static wiki to handle a dynamic retrieval problem.

The format is simple. If the ecosystem moves, the implications will not be.

Resources

• Google Cloud Official OKF Announcement, June 12, 2026
• OKF GitHub Spec and Reference Implementations
• MarkTechPost OKF Deep Dive
• RAG Original Paper, Lewis et al. 2020
• RAGAS Evaluation Framework
• LangChain Documentation

Connect with me on LinkedIn or see what I am building on GitHub.