Open Knowledge Format vs RAG: Why Your Agent Should Read a Wiki

Most agent stacks automatically search vector databases when they need facts they were not trained on. This is reasonable for information buried in tickets and wiki pages, but strange when the answer is a team-defined concept already established in a document. For example, calculating the weekly active users (WAU) metric. While an agent might ask how to compute WAU, it often lacks knowledge about the underlying metric doc, orders table, and freshness playbook.

When wired conventionally, the agent's request goes through a chunker that separates the relevant paragraph from its supporting context. At query time, a retriever returns a few fragments that appear related, but the model must infer the necessary joins. Sometimes it gets the join right, sometimes it counts sign-ins due to an onboarding page using the term "active user."

The fluent paragraph returned by the model does not indicate whether the model reasoned poorly or the retriever provided incorrect data. This is retrieval-augmented generation executing its search purpose: finding relevant information in a haystack. However, when the same machinery is used to store a well-known fact, splitting it into chunks and hoping for the right piece to return proves wasteful work.

On April 2026, Andrej Karpathy proposed a different approach. Rather than rediscovering facts from raw documents for each query, a wiki where the model can read and maintain knowledge should be kept. When new data arrives, the model files useful parts into existing pages, updates cross-references, and notes contradictions. This compiles knowledge once and keeps it current.

Google Cloud adopted this pattern on June 12, 2026, with the release of the Open Knowledge Format (OKF). OKF is the shared contract for the wiki, a format consisting of markdown files where each file represents a concept like a table, metric, API, policy, or runbook. The file path serves as the identity, and YAML frontmatter in each file provides essential metadata like type, title, description, tags, and resource URI.

Concepts link to one another using ordinary markdown links, creating a graph structure atop the directory tree. Two reserved files, index.md and log.md, handle navigation and maintain a changelog. OKF bundles can be stored as a git repository, tarball, or folder on disk, making them accessible to various readers like Knowledge Catalog, Obsidian, GitHub, MkDocs, or a file-read tool in an agent loop.

This format eliminates the need for embedding and ranking steps, as relationships are explicitly written down in the files. For instance, when someone asks how WAU is computed, a bundle containing relevant files can be as small as:

sales/

index.md

tables/orders.md

metrics/weekly_active_users.md

playbooks/orders_freshness.md

index.md acts as the map, listing related concepts and their connections. The metric file defines WAU, points to the orders table, and includes validation and staleness information. The table file specifies the grain and joins, while the playbook outlines triage steps for freshness issues. These pieces are not hidden in lengthy Confluence pages; they are readily accessible through simple markdown links.

The agent reads index.md, opens the metric file, follows the link to the orders table, and only consults the playbook if freshness is in question. Path resolution is straightforward, with no embedding or ranking required, as relationships are already established through links. Using RAG to retrieve fragments from raw documents would flatten these relationships into disconnected text, forcing the model to guess the intended structure instead of relying on explicit connections.

With RAG, if the generated paragraph containing the WAU definition is incorrect, it would be difficult to identify the source of the error.