The End of Context Fragmentation

The primary bottleneck for foundation models is no longer raw compute or parameter count; it is context. While models can execute code and analyze datasets, they remain limited by the quality of their internal knowledge—the schemas, metrics, and runbooks currently trapped in disconnected silos. Google Cloud has introduced the Open Knowledge Format (OKF), an open specification designed to formalize the LLM-wiki pattern into a portable, vendor-neutral standard.

The problem is structural. Organizational knowledge lives in incompatible surfaces: metadata catalogs with proprietary APIs, wikis, shared drives, and code comments. When an agent attempts to answer a specific query regarding internal data streams, it must assemble an answer from these scattered sources. Because every vendor offers its own schema and SDK, none of this knowledge is portable across products or organizations. This fragmentation forces every agent builder to solve the same context-assembly problem from scratch.

OKF v0.1 addresses this by representing knowledge as a directory of markdown files with YAML frontmatter. It is a format, not a service or a platform. There is no new runtime, no compression scheme, and no required SDK. A bundle of OKFS documents remains simple: it is just markdown and YAML that can render on GitHub, ship as a tarball, or mount on any filesystem.

This approach scales the concept articulated in Andrej Karpathy’s April 2026 LLM Wiki gist. The core insight is that while humans abandon personal wikis due to the burden of bookkeeping, LLMs do not get bored and can edit many files in one pass without forgetting cross-references. By formalizing conventions used in tools like Obsidian, Notion, or Hugo, OKF aims to make these patterns interoperable.

The move toward a vendor-neutral spec suggests that the value in AI orchestration will shift from proprietary data ingestion to the ability to utilize standardized, curated context. If successful, the industry may move away from bespoke implementations like AGENTS.md or metadata-as-code repos and toward a unified layer of machine-readable institutional memory.

Consider whether your current internal documentation strategy is building an asset that can be used by any agent, or if you are simply creating another silo.