Google Cloud released the Open Knowledge Format in June 2026 as a draft specification for exchanging agent-readable knowledge. OKF v0.1 defines a directory of Markdown files with YAML frontmatter, reserved index.md and log.md files, and conventions for links between documents.

That is a useful document format. It is portable, readable, easy to version in Git, and cheap to integrate with existing tools. Calling it a universal knowledge format claims much more than the specification provides.

Much of the current enthusiasm for this approach comes from tools that already work: an Obsidian vault, a folder of Markdown, an agent with grep. Filesystem and grep are programming primitives pressed into service as agentic context management. They are fast and deterministic when you already know the exact string you are looking for. That fit is real for codebases. It is a weaker fit for memory, where you recall by meaning and association rather than by filename. Semantic search improves recall, but retrieval alone cannot answer questions whose solution is a path through several relationships.

What OKF Actually Standardizes

Each OKF concept is a Markdown file. Its path is its identifier. The frontmatter requires a type string and may include a title, description, resource URI, tags, and timestamp. The body contains unrestricted Markdown.

Concepts can link to other concepts through ordinary Markdown links. The OKF specification says:

A link from concept A to concept B asserts a relationship. The specific kind of relationship (parent/child, references, joins-with, depends-on, etc.) is conveyed by the surrounding prose, not by the link itself.

It then says graph consumers should usually treat these links as directed edges with an untyped relationship.

This is the central weakness of OKF. It standardizes document identity and document metadata, then leaves the relationships between documents unstructured.

A Hyperlink Produces an Edge, Technically

Google is correct in the narrow graph-theory sense. A set of documents connected by directed hyperlinks forms a graph. Every link can be represented as an edge from one document to another.

That gives OKF a document graph, comparable to the link graph of a website. It does not give OKF the relation model expected from a knowledge graph.

A knowledge relation normally has machine-readable semantics. The relation between two entities might be DEPENDS_ON, WORKS_AT, JOINS_WITH, or SUPERSEDES. It may carry properties such as a join key, confidence score, source, creation time, or validity range. A consumer can filter and traverse those relations without interpreting the original prose again.

An OKF consumer sees the same edge for all of these cases:

orders joins with customers.

orders depends on customers.

orders mentions customers as an example.

orders cites customers as a source.

Those statements produce an identical structural representation: a directed link from one file to another. The actual relationship remains buried in text.

Surrounding Prose Is Not Queryable Edge Data

Placing relationship information near a link does not make that information part of the edge. It gives an extraction system enough text to infer a possible relation.

That distinction matters. Suppose an OKF file says:

Joined with customers on customer_id.

The link stores the target. It does not store JOINS_WITH as a relation type, customer_id as an edge property, or the direction and cardinality of the join. A downstream consumer must parse the sentence and interpret those values. Different consumers may produce different results.

The same problem appears with temporal knowledge. A sentence may say that Sarah left Acme in March 2025 and joined BetaCorp in April. The links identify two company documents. They do not represent two employment relations with separate validity ranges. A consumer cannot issue a reliable query for Sarah's current employer using the OKF link graph alone.

This is not a minor implementation detail. It determines which queries the representation can answer.

The Required type Field Does Not Fix the Relationship Model

OKF requires a type field for each concept. That supports filtering documents into categories such as table, metric, playbook, or API endpoint. It provides node typing.

Relationship typing is a separate concern. OKF does not define it.

The extension rules allow producers to add arbitrary frontmatter fields, so a producer could invent a structured relationships field. Another producer could use edges, a third could encode relations in body tables, and a fourth could continue using prose. Those bundles would all be valid OKF while remaining incompatible at the relationship level.

Extensibility lets people work around a missing standard. It does not standardize the missing part.

The Visualizer Does Not Change the Representation

OKF includes a viewer that turns a bundle into a force-directed graph using Cytoscape.js. Nodes are colored by concept type and Markdown links are rendered as arrows. Backlinks are computed by reversing those links.

This is a useful interface for browsing a document corpus. It does not add semantics to the links.

A graph visualization can make any network look like a knowledge graph. The relevant test is whether the underlying representation can answer relational queries. Can it return only DEPENDS_ON edges? Can it find active employment relations? Can it follow ownership links while excluding citations? Can it preserve properties on a relationship? OKF v0.1 cannot do those things without another extraction and indexing layer.

At that point, the additional system is providing the knowledge graph. OKF is providing its source documents.

OpenWiki Is a Wiki Maintainer

LangChain's OpenWiki began as a CLI that generates documentation for a repository, writes it into an openwiki/ directory, and adds a reference to that directory in AGENTS.md or CLAUDE.md. A scheduled GitHub Action checks new commits and updates affected pages.

That is practical. Coding agents benefit from maintained architecture notes, and loading pages on demand is better than placing the entire repository description in one instruction file.

OpenWiki Brains applies the same process to Gmail, Notion, Git repositories, web search, Hacker News, and X. Connector runs collect source material and an agent turns it into a local Markdown wiki. The wiki can then be refreshed on a schedule.

The OpenWiki Brains announcement is fairly direct about its current limits. It says the brain is a wiki on the filesystem. Full-text search, semantic search, MCP access, inter-page linking, and richer formats are listed as future work.

OpenWiki currently provides automated collection and synthesis into files. Those are worthwhile capabilities. They do not provide semantic retrieval, graph traversal, typed relationships, or structured handling of changing facts.

Calling the result a "brain" makes the product sound further along than its representation and retrieval systems are.

Karpathy's LLM Wiki Has a Better Claim

OpenWiki and OKF both cite Andrej Karpathy's LLM Wiki idea. Karpathy describes an LLM-maintained set of Markdown pages that sits between raw sources and the user. The agent updates existing pages, records contradictions, adds cross-references, and keeps summaries current.

The useful part of that proposal is the maintenance process. An agent integrates new material instead of indexing every document as an isolated chunk. This improves on basic retrieval pipelines that repeatedly rediscover the same facts from raw sources.

Still, the consistency of the wiki depends on the agent following instructions correctly. Contradictions, relation types, provenance, and temporal changes remain prose conventions unless another system represents them structurally. The wiki can describe knowledge well while remaining a weak substrate for querying it.

Scaffold Stores Relationships as Data

Scaffold uses an embedded LadybugDB database with separate representations for entities, relationships, and episodes.

The graph contains Entity nodes connected through EntityRel edges. Each relation has a semantic type property, such as WORKS_AT, LOCATED_IN, or PREFERS. Relations can also carry arbitrary properties and the temporal fields valid_at and invalid_at.

The physical database uses one relationship table, with semantic relation types stored as data. This still provides typed relations at the application level because queries can filter, reconcile, and traverse by that type. The information does not need to be recovered from nearby prose.

A change in employment can invalidate the old WORKS_AT relation and create a new one. History remains available, while queries can distinguish current and expired facts. A Markdown file can describe that sequence. Scaffold can query it.

Tulving's Distinction Is Reflected in the Architecture

Scaffold loosely maps Endel Tulving's distinction between episodic and semantic memory onto two machine representations.

Episodes preserve narrative content in vector space. They retain the surrounding language, source material, and context that would be lost by reducing everything to entities and relations.

The graph stores structured facts and connections. It supports direct relationship queries and paths between entities.

The comparison with human memory is functional, not biological. A vector index is not a hippocampus, and a property graph is not the neocortex. The useful point is that similarity and explicit relations support different retrieval operations. Scaffold queries both representations through separate agents and combines their results.

OKF and OpenWiki place narrative and relationships in the same Markdown body. That keeps authoring simple, but it also forces consumers to extract structure from prose whenever they need it.

Scaffold's Retrieval System

Scaffold does not run one search over one representation. A request can reach both vector memory and the knowledge graph through separate agents, giving the caller narrative episodes alongside structured entities and relations. Within the graph, entity retrieval is itself a three-part hybrid system: lexical matching, vector similarity, and graph traversal.

The lexical leg searches entity names, descriptions, tags, and aliases. Names receive the strongest weight because an exact or partial entity name is usually the clearest signal of intent. Description matches receive less weight, followed by tags and aliases. This leg is deliberately simple substring scoring, not BM25, and it remains useful for names, product terms, and phrases whose spelling matters.

The vector leg embeds each query variation and searches the entity embedding index by cosine similarity. It can retrieve an entity when the query and stored text use different language. A query about someone who "handles login security," for example, can surface an entity described in terms of authentication without requiring a shared keyword. The search takes the best vector rank found across the supplied query variations rather than averaging good and bad formulations together.

The traversal leg starts from the strongest lexical and vector candidates. It selects up to eight seeds, follows their incident relationships for as many as two hops, and ranks neighboring entities by distance and the number of connections back to those seeds. This allows retrieval to include an entity that is relevant because of where it sits in the graph, even when its own name and description do not match the query. A search that finds a person and an authentication system can also surface the project, policy, or company connecting them.

These legs produce scores with unrelated meanings. Lexical points cannot be added directly to cosine similarity, and neither can be compared cleanly with hop-weighted graph connectivity. Scaffold therefore uses reciprocal rank fusion, or RRF, which discards the raw scores and combines each leg by rank position. An entity receives a contribution for every result list in which it appears:

score(entity) = keyword_rrf + vector_rrf + 0.5 * traversal_rrf

Each contribution is 1 / (60 + rank). Keyword and vector rankings have equal weight, while traversal has half weight so graph proximity can improve a result without allowing a dense neighborhood to dominate the original query. Agreement matters: an entity ranked well by both text and meaning will usually outrank one supported by only one leg. A strong result from a single leg can still survive, which is important when an exact name has poor semantic similarity or a paraphrase has no lexical overlap.

RRF is a good fit here because it avoids fragile score normalization. Embedding models, entity descriptions, and graph density can change without requiring cosine distances, keyword points, and traversal scores to be forced onto an invented common scale. The current constants are explicit: a vector candidate pool of 30, eight traversal seeds, two traversal hops, an RRF constant of 60, and traversal weight of 0.5. The implementation can therefore be benchmarked and tuned rather than hidden behind a generic claim of "hybrid search."

BM25 would be a possible improvement to the lexical leg, especially for longer entity descriptions and multi-term queries. It would not replace the hybrid system. BM25 cannot retrieve paraphrases through embedding similarity or discover entities through graph structure. The relevant comparison is not BM25 versus RRF, since BM25 retrieves and RRF combines. A future version could use BM25 as the lexical ranker while retaining vector search, traversal, and RRF.

Vector episodes are searched separately by embedding similarity, preserving the longer narrative material that entity retrieval intentionally compresses. The knowledge graph also supports bounded shortest-path search, sequential relationship traversal, random walks, bridge detection using betweenness centrality, and discovery of peripheral entities. These operations cover directed lookup, connection finding, and open-ended exploration. A directory of linked files offers none of them unless a separate retrieval and graph system is built on top.

A Graph Agent Can Reason Between Queries

The more important difference appears when an answer requires several graph operations. A graph agent can issue a query, inspect the returned entities and relations, then decide what to query next. It can walk outward from a person, compare candidate paths, inspect the properties attached to each relationship and rerun the search with a new constraint.

This makes verbs such as traverse, walk, reroute and backtrack concrete operations. Each step changes the state of the investigation. The agent may begin with a shortest-path query, reject one branch after reading an edge property, inspect a neighboring organization and continue from there. The database handles the graph operations while the model decides which operation follows from the evidence it just received.

BM25 and vector search remain valuable. BM25 can find documents that share precise terms, and vector search can retrieve passages with similar meaning. Both return items ranked against a query. A graph query can ask how those items are connected, which relation types join them, where two paths converge or which route remains after an edge is excluded. Those questions depend on topology.

I tested this with a synthetic network of roughly 30 people spread across AI companies, policy organizations and research groups. Each person had a profile, employment history and relationships to other people in the network. I asked the graph agent for the best way to reach one person.

The shortest route was four hops. The agent inspected the people and relationships along that route and noticed that one intermediary had not made a work transition public. Contacting the target through that chain would reveal knowledge the user was not expected to have. The route was structurally short and socially expensive.

The agent searched again and found a six-hop route that avoided the private transition. It recommended the longer introduction because it preserved the intermediary's confidence and the user's social capital. The useful answer came from combining pathfinding with the facts attached to the path, then running another query after evaluating the first result.

A language model could invent a plausible networking strategy from a prompt. It could not ground that strategy in this particular 30-person network unless the relevant people, relations and disclosure states were supplied in context. A Markdown corpus makes that grounding costly and unreliable. The agent would have to locate the right files, infer every relation from prose, reconstruct candidate paths and keep the working subgraph coherent across steps.

The graph stores that topology once and makes it queryable. This supports use cases that are difficult to anticipate when designing a fixed document schema. A future agent might trace how a policy idea moved between organizations, identify the person connecting two otherwise separate research communities or explain which dependency caused a project decision to propagate across teams. The value comes from giving the agent operations over connected information.

Scaffold's vector store and knowledge graph are presented as two complementary memory systems. The graph accounts for much of the implementation work and many of the behaviors that distinguish the product. Vector retrieval finds relevant material. Graph operations let an agent work through the connections inside that material.

Storage Becomes Memory During Integration

Scaffold checks new information against existing information before committing it.

A proposed episode is embedded and compared with nearby episodes. When the similarity crosses the reconciliation threshold, an analyzer decides whether the new material should be stored separately, merged into an existing episode, treated as a correction, or rejected as a duplicate.

Graph entities and relations go through a related process. Candidate entities are found through hybrid retrieval. The analyzer can merge duplicates, update fields, append information, or preserve separate entities. Relationship reconciliation can invalidate a previous relation when a new fact supersedes it.

This processing is implemented with LLM agents, so it still depends on model quality and prompts. It is not a database constraint and should not be presented as one. The architectural difference is that reconciliation is an explicit write-time operation rather than an instruction hidden in a wiki-maintenance document.

Markdown Still Has an Important Role

Markdown works well for writing, review, interchange, and long-form explanation. OKF makes those strengths easier to use across agents and organizations. OpenWiki reduces the labor required to maintain those files.

Scaffold also ingests Markdown, alongside documents, articles, videos, and conversations. The source remains readable and portable. During ingestion, the system extracts episodes, entities, and relations into representations designed for retrieval and reasoning.

The disagreement concerns where knowledge lives after ingestion. OKF treats the document as both the human artifact and the machine representation. Scaffold keeps the document as source material while maintaining queryable state in vector and graph structures.

What OKF Would Need to Standardize

OKF could add first-class relations without becoming a platform or requiring a database. A relation record needs a source concept, target concept, relation type, direction, and an optional property map. Temporal bounds and provenance would cover common cases involving changes and evidence.

Those records could still live in YAML or another plain-text encoding. Producers could write them by hand or generate them with agents. Consumers could import them into RDF stores, property graphs, relational databases, or search indexes without inferring relation semantics from prose.

The Markdown body could continue explaining the relationship for human readers. The structured relation would give machines a stable contract.

Until that exists, OKF provides interoperability for concept documents and their links. It does not provide interoperability for the knowledge relations those documents describe.

OKF is a useful draft format for exchanging curated Markdown documentation. Its portability, Git compatibility, and low implementation cost are real advantages. OpenWiki is useful automation for generating and updating such documentation.

The inflated claim is that linked Markdown supplies a sufficient knowledge representation. It supplies a document graph with typed documents and untyped links. Any consumer that needs typed relations, temporal facts, graph queries, semantic search, or reconciliation must build those capabilities separately.

Scaffold already implements those systems: vector episodes, semantically typed graph relations, temporal validity, hybrid retrieval, pathfinding, exploration, and write-time reconciliation. It also accepts the added complexity and model dependence that come with them.

Google has standardized a good container for agent-readable documents. Calling that container an open knowledge format is premature until the relationships become part of the format rather than prose placed near a hyperlink.