Your AI Agent Keeps Forgetting. Open Knowledge Format (OKF) Is the Cure

How Andrej Karpathy's idea + Google's new open standard are changing how AI agents learn, remember, and share knowledge — and why RAG alone is no longer enough.

TL;DR — RAG forces your AI to rediscover knowledge from scratch on every query. The LLM Wiki pattern fixes this by letting the AI maintain a persistent, growing knowledge base. Open Knowledge Format (OKF) is the new open standard that makes these wikis portable across tools, teams, and organizations.

1. The Problem: Your AI Agent Forgets Everything

You've built an AI agent. You fed it your company's documentation, your database schemas, your runbooks. It answers questions pretty well.

But then something breaks.

You ask the same question two weeks later. It gives a slightly different answer. You update a metric definition. The agent doesn't know. You onboard a new dataset. The agent has never heard of it unless you re-explain everything from scratch.

The root cause: most AI agents are built on RAG — Retrieval-Augmented Generation. RAG is powerful, but it has a fundamental limitation.

RAG has no memory. Every single query, the agent searches your raw documents, grabs chunks it thinks are relevant, and builds an answer. Then forgets everything. Next query? Same thing again. Your agent never gets smarter.

At small scale this is fine. But as your data grows — more tables, more metrics, more documentation — your agent gets slower, more expensive, and less accurate. Because it's rediscovering the same knowledge every single time.

2. The Analogy: Two Research Assistants

Imagine you hire two research assistants. Same job: answer your questions about your company's data.

Assistant A wakes up every morning with their memory completely wiped. You ask "how is weekly active users defined?" — they sprint to the filing cabinet, read through 200 documents, piece together an answer, hand it to you. Tomorrow you ask again? Back to the filing cabinet. They never learn. Every answer costs the same effort.

Assistant B keeps a personal notebook. The first time they research a topic, they write it down — clearly, with cross-references. "WAU is defined here, it links to this table, this definition changed in Q1 2026 because of this RFC." Next time you ask? They open the notebook and answer in seconds. When something changes, they update the relevant notebook pages. After six months, their notebook is the single most valuable asset in your company.

Figure 1 — Same job, different memory model. RAG is Assistant A. The LLM Wiki is Assistant B.

That notebook is what Andrej Karpathy called the LLM Wiki.

3. The Idea: Let the LLM Maintain the Notebook

In early 2026, Andrej Karpathy — AI researcher, former OpenAI leader — published a short note on GitHub called "LLM Wiki." The core insight:

"Instead of using models to search the same documents for the same facts over and over, give your agents a shared markdown library that grows more useful over time. Let your agents take on the drudgery of reading and updating their own files."

The pattern has three layers:

·       Raw sources — your documents, articles, database exports. Read-only. The LLM reads them but never modifies them.

·       The wiki — markdown files the LLM writes and maintains. Concept pages, entity pages, summaries, an index. You read it; the LLM writes it.

·       The schema — a CLAUDE.md or AGENTS.md file that tells the LLM the rules: what pages to create, how to handle contradictions, how to cross-reference. This is the difference between a disciplined wiki and a random pile of notes.

When you add a new source, the LLM reads it and integrates it into the wiki — creating new pages, updating existing ones, flagging contradictions. When you ask a question, the LLM reads the wiki (not the raw docs) and answers. When the answer is good, it files it back into the wiki.

Figure 2 — RAG rebuilds knowledge from zero on every query. The LLM Wiki compiles it once and compounds over time.

The result: your AI assistant gets smarter with every document you add and every question you ask. Knowledge compounds instead of evaporating.

4. What Was Still Missing: A Standard Everyone Could Use

Karpathy's pattern spread quickly. Teams started building their own wikis: Obsidian vaults wired to agents, CLAUDE.md files, "metadata as code" repos. The pattern was clearly powerful.

But everyone was building it slightly differently.

Your team's wiki uses different field names than your colleague's. Your vendor's catalog export is close but not quite compatible. You want to share your knowledge bundle with another team's agent — but there's no agreed format, so you'd need to write a custom integration.

This is the same problem the web faced before HTML. Browsers existed. Documents existed. But there was no agreed format — so nothing could talk to anything else. HTML solved that. Not by being fancy. By being agreed upon.

What the LLM Wiki pattern needed wasn't a new tool or a new platform. It needed a format. A simple, agreed-upon standard so any producer could write knowledge and any consumer could read it.

5. Enter OKF: The Open Knowledge Format

On June 12, 2026, Google Cloud published the Open Knowledge Format (OKF). It formalizes Karpathy's LLM Wiki pattern into a portable, open standard.

The spec is one page long. Here is the entire rule:

Every knowledge document must be a markdown file with YAML frontmatter. The frontmatter must contain one field: type. That's it.

That's the whole mandatory surface. Everything else — what types exist, what other fields to add, how to structure the content — is up to you. OKF defines the minimum needed for interoperability.

Here's what an OKF document looks like:

---
 type: Metric              	← the only required field
 title: Weekly Active Users
 description: Users with >=1 event in the last 7 days.
 tags: [growth, north-star]
 timestamp: 2026-07-01T00:00Z
 ---

 ## Definition

 COUNT(DISTINCT user_id)
 FROM [events](/tables/events.md)
 WHERE event_date >= CURRENT_DATE - 7

 ## History

 Changed from 30-day to 7-day window in Q1 2026.
 See [RFC-014](/rfcs/014.md).

 ## Known issues

 Bots not yet filtered. Tracked in [issue-88](/issues/88.md).

Notice: this is just a markdown file. No database. No SDK. No account. Open it in Obsidian, render it on GitHub, load it into any LLM — it just works.

And that link to /tables/events.md? That's the key. Links between files turn a folder of markdown into a knowledge graph. Your WAU metric knows which table it reads from. Your events table knows which metrics depend on it. The connections are as valuable as the documents themselves.

Figure 3 — An OKF bundle is a folder of markdown files. The only rule: every file needs a "type". Links between files create a knowledge graph.

6. OKF vs RAG: Not Competing, But Complementary

A common question: "Isn't this just RAG with extra steps?"

No. They solve different problems:

Think of it this way: RAG is great when you have a static document collection and need to search it. The LLM Wiki is what you build when your knowledge evolves — when definitions change, new tables get added, incidents happen and get resolved. You want that history, that synthesis, already compiled when your agent needs it.

RAG answers "what's in these documents?" The LLM Wiki answers "what do we know, how did we learn it, and what's changed since?"

7. What Google Shipped With OKF

Google didn't just publish a spec — they shipped three things to make it real:

A reference enrichment agent

Point it at any BigQuery dataset and it automatically produces a conformant OKF bundle. First pass: schema metadata. Second pass: the LLM crawls documentation URLs you give it and enriches each concept with join paths, usage examples, and citations. The agent figures out the context that lives in docs but not in schema.

An interactive knowledge graph visualizer

One command turns any OKF bundle into a self-contained HTML file — an interactive graph where nodes are concepts and edges are links. Click any node to see its full definition. No backend, no install, no data leaves the file. Share it as an email attachment.

Three production-quality sample bundles

GA4 e-commerce data, Stack Overflow, and Bitcoin transactions — real public BigQuery datasets, processed by the reference agent, checked into GitHub and browsable today. Not toy examples.

Figure 4 — Any tool can produce OKF. Any tool can consume it. Google shipped a producer (enrichment agent) and a consumer (visualizer) as proof-of-concept — the format works with anything.

8. A Concrete Walkthrough: Before and After

Before OKF

A data engineer joins your team. They want to understand how "weekly active users" is computed. They:

1.     Search Confluence — find a page from 2021 that may be outdated

2.     Ask on Slack — get two conflicting answers

3.     Find a notebook cell that references "legacy_metrics.sql"

4.     Open legacy_metrics.sql — no one has touched it in 18 months

5.     Give up and ask the senior engineer directly

The senior engineer answers, mentions "oh there was an RFC that changed it in Q1" — knowledge that exists only in their head.

After OKF

The same data engineer opens the team's OKF bundle:

6.     Finds metrics/wau.md — one file, clear definition

7.     Sees the Q1 change documented, with a link to the RFC

8.     Clicks through to tables/events.md — sees the exact schema

9.     Finds a "Known issues" section noting bots aren't filtered

The whole thing takes 90 seconds. The knowledge was already compiled. The senior engineer's interrupt never happened.

When your agent needs this context? Same story. It reads the bundle, finds the metric page, answers correctly. No searching through stale Confluence. No hallucinating a definition that changed six months ago.

9. How to Get Started This Week

Option 1: Start with Karpathy's pattern (zero setup)

Create two folders: raw/ and wiki/. Write a CLAUDE.md with your conventions. Drop documents into raw/ and tell your agent to ingest them. The pattern works immediately. Migrate to OKF conventions (add type to your frontmatter) when you want interoperability.

Option 2: Use the reference agent on BigQuery

Clone github.com/GoogleCloudPlatform/knowledge-catalog. Follow the README to run the enrichment agent against one of the public sample datasets first — see what a finished bundle looks like before generating your own. Then point it at your real data.

Option 3: Read the spec and write your own producer

The OKF spec is one page. The conformance requirement is one field. If you maintain a data catalog, a docs site, or a schema registry, adding an OKF export is a few hours of work — and immediately makes your knowledge consumable by any OKF-compatible agent or tool.

10. Why This Is a Big Deal

Internal knowledge has always been expensive to maintain and hard to make available to AI systems. That's why RAG systems mostly work on static external documents — Wikipedia, web pages, PDF uploads — rather than the living, evolving knowledge inside your organization.

The LLM Wiki pattern flips this. The expensive part — synthesis, cross-referencing, keeping things current — is exactly what LLMs are good at and what humans hate doing. The maintenance problem that killed every internal wiki you've ever tried goes away.

OKF makes this portable. Instead of every team solving the same problem in their own bespoke way, you get a shared language. Knowledge moves between tools, teams, and organizations without custom integrations.

Karpathy described the vision simply: "LLMs don't get bored, don't forget to update a cross-reference, and can touch 15 files in one pass." OKF is the format that makes this vision interoperable.

The internal wiki has been a graveyard for twenty years. Not because of the idea — the idea was always good. Because of the maintenance cost. That cost is now near zero.

Sources

·       Karpathy, A. (2026). LLM Wiki — a pattern for building personal knowledge bases using LLMs. GitHub Gist. https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f

·       McVeety, S. & Hormati, A. (2026). How the Open Knowledge Format can improve data sharing. Google Cloud Blog. https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing

·       Open Knowledge Format v0.1 Specification. https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md

·       Google Cloud Knowledge Catalog — reference implementation & sample bundles. https://github.com/GoogleCloudPlatform/knowledge-catalog

Written July 2026. Original content synthesized from the sources above. Not sponsored by Google or Anthropic.