Standardizing Agent Memory: Building a Self-Updating Codebase Knowledge Graph with Google's OKF

Google's new one-page spec standardizes AI context, but keeping a thousand-file codebase knowledge graph accurate is up to you. Here is the pipeline.

AI agents are burning your token budget re-deriving the structure of your codebase on every single task, yet the industry's answer is either naive full-repo dumps or unpredictable RAG. Google's newly released Open Knowledge Format (OKF) offers a cure — a spec so minimal it fits on a single page — but it leaves the hardest systems problem as an exercise for the reader: how do you keep a thousand-file knowledge graph accurate when a team is shipping forty commits a day?

We built the solution: a git-hook-triggered codebase enrichment pipeline that automatically drafts, links, and lints an OKF bundle on every commit. This changes context costs by an order of magnitude and moves codebase memory from ad-hoc retrieval to a compiled, self-maintaining cache.

The One-Page Spec That's Hiding a Systems Problem

On June 12–13, 2026, Google Cloud's Sam McVeety and Amir Hormati published the Open Knowledge Format (OKF) v0.1: a directory of Markdown files with YAML frontmatter, where the only mandatory field across the entire spec is type. That's it. As they put it:

"Today, we're introducing the Open Knowledge Format (OKF)… a vendor-neutral, agent- and human-friendly standard for representing the metadata, context, and curated knowledge that modern AI systems need."

Google is explicit about the lineage: OKF formalizes Andrej Karpathy's April 2026 "LLM Wiki" pattern. The core premise is that an LLM should maintain a compiled, cross-linked Markdown wiki as durable external memory, the same way source code is compiled once and reused rather than re-parsed on every read. That's a direct rebuttal of RAG's default assumption, which re-derives relationships from raw documents at query time, every time. As Google's own materials explain:

"LLMs don't get bored, don't forget to update a cross-reference, and can touch 15 files in one pass. The bookkeeping that causes humans to abandon personal wikis is exactly what LLMs are good at."

Here is the part every explainer skips. The full OKF v0.1 conformance spec fits on a single page — three conformance rules, total. That minimalism is the story engineers keep missing: the spec was never meant to be a product. It's a wire format. The actual system — the thing that turns a live, changing codebase into an accurate, cross-linked, agent-consumable graph — doesn't exist in any of these posts. Nobody shows how to programmatically generate and keep an OKF graph honest for a repo that's still being edited. That's the gap this piece fills: we are building the pipeline, not just reading the folder structure.

Why Minimal Is the Feature, Not a Limitation

Before building anything, you need to understand the data model precisely, because the design choices here aren't accidents — they're the reason OKF is adoptable at all.

A bundle is a directory of Markdown files. A concept is one file, representing one unit of knowledge — a table, a service, a runbook, an API endpoint — and the file's path is its identity; there's no separate ID system to keep in sync. Of the recommended frontmatter fields (type, title, description, resource, tags, timestamp), only type is required. As the authors put it: "OKF requires exactly one thing of every concept: a type field... The spec defines the interoperability surface, not the content model." A canonical concept file looks like this:

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

Two reserved filenames give the bundle structure without adding required fields:

• index.md is a directory listing that enables progressive disclosure—an agent starts at the root and follows links only as deep as the task requires, which is a direct token-budget control.
• log.md is a chronological, date-grouped change history, distinct from git log, meant to answer "what changed in what this system knows," not "what changed in the files."

Conformance is deliberately lenient: consumers must not reject a bundle for missing optional fields, unrecognized type values, unknown frontmatter keys, or broken links. That's "format not platform" as a design principle, and it's why Alphamatch's analysis calls it "the USB-C cable of AI knowledge — a universal connector that anyone can produce and anyone can consume, without proprietary SDKs, APIs, or lock-in." Compare that to prior enterprise metadata-catalog and knowledge-graph standards, which typically demand schema registries, validation servers, and vendor SDKs before you write a single entry. Google's own GA4 demo bundle—17 markdown files spanning indexes, references, datasets, and tables—is proof that this restraint scales to something real, not just a toy example.

From Spec to Codebase: What an OKF Concept Looks Like for Code, Not Data

Google's reference use case is BigQuery tables. The pivot that matters for software teams is recognizing that the same shape maps directly onto services, modules, and APIs — you're just swapping resource from a console URL to a repo path, and # Schema for # Responsibilities and # Dependencies:

---
type: Service
title: billing-service
description: Handles subscription billing, invoicing, and payment webhooks.
resource: https://github.com/acme/monorepo/tree/main/services/billing
tags: [billing, payments, python]
timestamp: 2026-06-30T09:12:00Z
---
# Responsibilities
Owns the `Invoice` and `PaymentEvent` domain models. Consumes Stripe webhooks via
[stripe-webhook-handler](/services/billing/stripe-webhook-handler.md).

# Dependencies
- Calls [customer-service](/services/customer-service.md) to resolve account state.
- Publishes events consumed by [notifications-service](/services/notifications-service.md).
rea
# Citations
[1] [Billing runbook](https://wiki.internal/billing-runbook)

The cross-links aren't decoration. Bundle-relative Markdown links (/services/customer-service.md) turn a flat directory into a dependency graph that's richer than your filesystem's parent/child hierarchy—billing-service now formally points at everything it calls and everything it emits to, independent of where those services physically live in the repo tree.

The root index.md is the entry point a coding agent reads before touching any file:

# Billing Domain

* [billing-service](services/billing-service.md) - subscription billing, invoicing, webhooks
* [customer-service](services/customer-service.md) - account and subscription state
* [Runbooks](runbooks/) - on-call playbooks for billing incidents

That single file replaces a full-repo re-scan or re-embed. A coding agent can read an OKF bundle before touching a repo, and a data assistant can consult OKF documents before generating SQL. The bundle acts as a pre-flight context load, not a search index you query mid-task.

The Gap Nobody's Filling: Building the Enrichment Agent

Here's the central claim of this piece: adopting OKF is trivial — one required field, a folder convention, plain Markdown links. The real engineering work is something else entirely:

"The real engineering work… isn't adopting OKF, it's building the enrichment-agent pipeline that keeps a codebase's OKF graph accurate and current as the code changes."

OKF has no opinion on how a bundle gets generated or stays true — that is left entirely to whoever adopts it.

Google's own reference implementation for BigQuery is the template. It's a two-pass agent: pass one walks every table/view in a dataset and drafts an OKF concept document per asset from its schema; pass two adds citations by cross-referencing existing documentation. Translate that directly to code: pass one walks every module/service/API in a repo and drafts a concept file from its interfaces and call graph; pass two adds citations back to runbooks, ADRs, and PRs.

You don't have to build this from zero. The independent okf CLI (Go, Apache-2.0, superops-team) already proves the shape works—including the exact "keep it current automatically" piece:

# Scan the current repo and scaffold a .okf/knowledge bundle
okf init

# Install a git hook so the bundle auto-updates on every commit
okf hook install

# Query concepts by keyword
okf search -q "database"

# Enforce the 13 built-in spec-compliance rules
okf lint

That hook install step is the whole pitch: on every commit, the tool rescans the repo and refreshes the affected concept files, so the graph never drifts far from the code before something forces it back into sync. Put together, the pipeline you're actually building looks like this:

commit pushed
     |
     v
diff-scoped module scan  (which services/files changed?)
     |
     v
draft/update concept docs  (two-pass enrichment agent, per Google's BigQuery pattern)
     |
     v
re-link cross-references   (update Dependencies/Responsibilities links)
     |
     v
lint  (okf lint — 13 spec-compliance rules)
     |
     v
publish  (commit bundle / push to CI / register to catalog)

Scoping the scan to the git diff — not the whole repo — is what keeps this cheap enough to run on every commit instead of nightly.

Wiring It Into a Multi-Agent Workflow

None of this matters unless agents actually consume the bundle, and this is where progressive disclosure stops being a spec detail and becomes a budget lever. An orchestrator agent reads index.md first, decides which sub-agents need which concept files based on the subtask, and routes accordingly—nobody loads the whole bundle for a task that touches one service.

The programmatic wiring point is straightforward. The Go-based CLI tooling exposes exactly the load/search primitives you can bolt into an orchestration layer:

bundle, err := okf.LoadBundle(".okf/knowledge", nil)
if err != nil {
    log.Fatal(err)
}
results := bundle.Search("database")
result := lint.LintBundle(concepts, lint.DefaultConfig())

bundle.Search is the hook your orchestrator calls before dispatching a sub-agent; lint.LintBundle is the hook your CI calls before trusting the bundle enough to let agents act on it.

For teams that want the bundle consumable outside their own tooling, the third-party Kiso engine compiles an OKF bundle into a static site — HTML for humans, plus auto-generated llms.txt and sitemap.xml for crawler-style agents—and is designed to run in CI on every merge, so the published bundle never lags the source of truth.

One workflow-level decision matters more than any tool choice: where OKF stops and RAG starts. OKF is for the stable, curated slice of your codebase's knowledge — the services, the ownership boundaries, the dependency graph, the runbooks you've bothered to write. RAG is still what you reach for on the long tail: unstructured tickets, Slack threads, and one-off design docs. Treating OKF as a RAG replacement is the wrong frame; treating it as a compiled cache that RAG doesn't need to re-derive is the right one. On that framing, early analyst commentary claims a token-consumption reduction of up to roughly 95% versus naive document loading for focused, stable knowledge domains. While this figure is anecdotal and needs validation in large-scale production, it highlights the potential savings of pre-compiling agent context.

Where This Breaks: The Honest Limitations

None of the above works if you skip the failure modes, so here they are without hedging:

• No built-in search or retrieval: OKF is a file format, not a platform. You own the indexer, the search layer, and the serving layer; okf search and Kiso are early, unofficial attempts to fill that gap, not finished infrastructure.
• No type registry and no schema enforcement: The single required field, type, is producer-defined and unvalidated against any canonical list. Multiple teams contributing to the same bundle will drift—"API Endpoint" here, "Endpoint" there, "Route" somewhere else—without external governance and linting to hold the line.
• Untyped, unenforced links: A cross-reference is just a Markdown link with relationship semantics implied by surrounding prose, and consumers must tolerate broken links by spec. That caps how much formal graph reasoning — dependency traversal, impact analysis — an agent can safely automate compared to an actual RDF/OWL knowledge graph.
• Markdown doesn't fix knowledge quality: If your source docs and comments are stale or contradictory, OKF preserves that faithfully in a nicer folder structure. It has no mechanism to detect or resolve conflicting concepts on its own — that is still your enrichment agent's job, or nobody's.
• Extremely early ecosystem: The spec v0.1 was published in June 2026, tooling outside Google is fragmented and unendorsed, and there are no long-running production case studies of large, actively-changing codebases to validate maintenance overhead over time. As the authors themselves note: "OKF v0.1 is a starting point, not a finished standard."

Next in this series: From Self-Updating OKF Wiki to Production Trust System — how to add the validation, provenance, and freshness controls that make self-updating context safe to use in production.

Should You Build This? A Decision Framework

Given those limitations, here is the ROI calculus rather than a hand-wave toward "it depends."

Build it if you already run multiple agents against your own repo or knowledge base. In that world, the enrichment-agent pipeline pays for itself directly: fewer tokens spent re-deriving context per task, and fewer stale-context bugs from an agent acting on an outdated mental model of the codebase.

Skip it — for now — if you're not yet running agentic workflows against your code. OKF's entire value proposition is agent consumption; without agents consuming it, you are maintaining a wiki nobody reads.

If you decide to build, the minimal viable pipeline fits in an afternoon: okf init plus a git hook, one enrichment pass over your most-changed services (not the whole repo), and index.md as the single entry point every agent reads first. Cost-wise, the format itself is nearly free to prototype—one required field, six recommended, no SDK, no lock-in, no schema registry to stand up. The ongoing cost is the enrichment agent's own compute and the drift-monitoring you build around it, not the spec. As the FAQ puts it: "If you can cat a file, you can read OKF; if you can git clone a repo, you can ship it."

Conclusion

Stop evaluating OKF as a format decision and start prototyping it as a pipeline decision. Point a git hook and a two-pass enrichment agent at your most-active service this week, measure the token delta on your next multi-agent task, and decide from data — not from a spec's minimalism — whether the maintenance cost is worth it for your repo.

Edit : I've also written a separate article comparing Graphify with its alternatives — feel free to check it out if you're interested

I've written a follow-up article, "Graphify, OKF, or Both? Choosing a Trustworthy Codebase Knowledge Layer Beyond RAG." It examines where Graphify, OKF, and RAG differ, where they overlap, and how they can work together in a production architecture.

What is your take?

If you were implementing this codebase knowledge graph today, would you choose the ready-made okf CLI and Git hooks, or would you build a custom multi-pass enrichment pipeline to route metadata to different LLMs? Let us know in the comments, and please highlight the section of this guide you expect to reuse in your own workflow!

Resources

1. 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
2. Google Cloud Platform. (2026). Open Knowledge Format Specification (v0.1). GitHub Repository. https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md
3. Open Knowledge Format FAQ. https://okf.md/faq/
4. Karpathy, A. (2026). LLM Wiki Memory Pattern. https://gamgee.ai/blogs/karpathy-llm-wiki-memory-pattern/
5. Superops Team. (2026). okf CLI: Go implementation of the Open Knowledge Format. GitHub Repository. https://github.com/superops-team/okf
6. Oak Invest. (2026). Kiso: Publishing engine for OKF bundles. GitHub Repository. https://github.com/oak-invest/kiso