Open Knowledge Format vs Governance: Why Structured Memory Is Not Enough for AI Agents

What the Open Knowledge Format Is

On June 12, 2026, Google Cloud published the Open Knowledge Format announcement, releasing OKF v0.1 as an open specification. The shape is deliberately plain: a directory of markdown files, each with a YAML frontmatter block carrying fields like type, title, description, resource, tags, and timestamp (v0.2 replaces timestamp with generated). No software development kit (SDK). No proprietary runtime. No vendor lock-in. Any system that can read a file can read OKF.

That plainness is the point. OKF is vendor-neutral by construction, and it cleanly separates who writes knowledge from who consumes it. A platform team can author and version organizational knowledge once, and a coding agent, an enterprise assistant, a workflow agent, and a search index can all read the same source without any of them owning the format. OKF formalizes a pattern the industry had already been reaching for, which we have described as treating your codebase context like a large language model (LLM) wiki: knowledge written down, structured, and made retrievable instead of scattered.

The Three Problems OKF Solves

OKF is a useful piece of infrastructure, and it is worth being precise about what it fixes. It solves three real problems, all of them about getting knowledge to the agent.

• Knowledge organization. Today organizational knowledge is scattered across Confluence, Notion, Google Docs, Slack threads, and half-maintained wikis. OKF gives it a single structured representation instead of a dozen inconsistent ones.
• Knowledge portability. Because it is plain markdown with no SDK, the same knowledge directory works across coding agents, enterprise assistants, workflow agents, and search. Write once, consume anywhere.
• Knowledge discovery. Agents can reliably locate the relevant decision instead of relying on ever-larger prompts that stuff the whole wiki into context and hope the model notices.

The value here is standardization. A common language for organizational knowledge is exactly the kind of primitive the agentic ecosystem needs, and Google publishing it as an open spec rather than a closed product is the right move. None of what follows is a criticism of OKF. It is a description of the layer that sits above it.

The Retrieval Fallacy

Most knowledge-for-agents architectures carry an assumption: Knowledge Retrieved equals Knowledge Applied. Get the right document in front of the agent and the agent will act on it. OKF does not make that assumption itself; its specification calls trust tiers advisory signals rather than access control. The assumption lives in the systems that consume OKF and hand its contents to an agent. For a chatbot answering a question, that assumption mostly holds. For a coding agent that writes and ships code, it quietly falls apart.

Consider a concrete case. A team has a stored architectural decision: all database access must go through repository abstractions, with no direct SQL in application code. The decision lives in the knowledge directory. The agent is asked to add a reporting endpoint. It retrieves the decision. It references it during planning. It can quote the rule back to you. And then it writes a direct SQL query against the table, because that was faster and the query was simple.

This is the failure mode we keep returning to: memory is not governance, and the same logic applies to discovery. Retrieving a security requirement, a naming standard, or a framework convention tells the agent what the rule is. It does nothing to guarantee the agent obeys it. Knowing and complying are different systems with different failure modes, and a knowledge format only addresses the first.

The reason this matters more for agents than for people is throughput. A human engineer who reads the repository-abstraction rule internalizes it once and applies it across hundreds of changes. An agent re-reads the rule on every task and re-decides whether to honor it on every task, under local pressure to produce a working diff fast. Each decision is independent, which means the rule has to win every single time or the boundary erodes. A storage format that makes the rule easy to find does not change the odds at the moment the agent chooses to bypass it.

The Four-Layer Agentic Stack

It helps to place OKF in the stack that the agentic ecosystem is assembling. Each layer answers a different question, and the questions are not interchangeable.

Most of the public conversation lives in layers one through three. OKF is a clean layer-one contribution. Vector databases and semantic search occupy layer two. As we have argued, retrieval is not the same as memory, and neither is the same as enforcement. Agent frameworks and orchestrators own layer three.

Layer four needs its own place in the stack, and the reason is structural. Agentic AI generates actions, not text. A chatbot that ignores the docs gives a mediocre answer and the cost stops there. A coding agent that ignores the docs introduces a security vulnerability, breaks an architectural boundary, creates a compliance violation, or quietly raises technical debt, and that cost ships to production. When the output is executable, "did it follow the rules" stops being a quality nicety and becomes a control requirement.

Notice that the four layers fail in different directions. Layers one through three are permissive by design: storage holds everything, retrieval surfaces what is relevant, planning proposes whatever moves the task forward. Their job is to make more knowledge usable. Layer four is the only one whose job is to say no: to reject an action that contradicts a decision the organization already made.

You cannot build a permissive layer well enough to produce a restrictive guarantee. Better storage, better retrieval, and better planning all increase what the agent can do; none of them constrains what it is allowed to do. That asymmetry is why governance cannot be folded into the lower layers and has to sit on top of them as its own concern.

Memory, Retrieval, Storage, Governance: Four Different Questions

The vocabulary in this space is overloaded, so it is worth separating the terms by the question each one answers. They are not competing solutions to one problem. They are sequential answers to four different problems.

For architecture decisions, OKF is a storage standard. It makes the first row excellent. But better storage does not improve the last row, because obedience is a property of enforcement, not of how knowledge is filed. This is the same distinction that makes retrieval-augmented generation (RAG) insufficient for architectural governance: a retrieval system can surface the perfect constraint and still have no mechanism to stop the agent from violating it. The gap is not in what the agent can find. It is in what happens to the agent’s output when it ignores what it found.

If you are evaluating where this fits in a real workflow, the practical question is which constraints your agents must never violate, regardless of what they retrieve, the kind of thing our use cases walk through. That list is your governance layer. OKF can hold the decisions; it cannot be the thing that enforces them, and it was never designed to be.

What OKF v0.2 Changes

The OKF specification moved to Version 0.2 in July 2026. Its motivation section lists five questions a consumer needs answered once agents write most of a corpus: provenance, trust, freshness, lifecycle and attestation. Version 0.2 answers the first four with optional frontmatter: sources for provenance, generated and verified for trust, stale_after for freshness and status for lifecycle. Attestation gets a concept type of its own, covered below. type is still the only required key, and type values are not registered centrally, so consumers must tolerate types they do not recognize. OKF defines no Architecture Decision type, but a producer can write one today:

---
type: Architecture Decision
title: Payments services use PostgreSQL
status: stable
verified:
  - { by: human:principal-architect, at: 2026-10-01T09:00:00Z }
stale_after: 2027-04-01T00:00:00Z
---

status takes draft, stable or deprecated, and a missing status means stable. stale_after is an absolute instant: the concept is stale once the current time reaches it. verified lists who or what confirmed the content against its sources, and when.

Trust is not authority

A consumer derives a trust tier from verified. No entry means unverified, non-human actors only means machine-confirmed, and a human: actor means human-reviewed. The spec then limits what that tier can do: “Trust tiers are advisory signals, not access control.” A consumer must not reject a concept that carries no trust fields at all.

Take the payments record above, a different decision from the no-direct-SQL example earlier. When the principal architect signs it, they confirm that the record matches its sources. They have not told a coding agent it must comply. Trust answers whether you can believe a record. An architecture decision record (ADR) also has to answer whether the agent is bound by it, and OKF leaves that question to the consumer.

Authority is not applicability

Now suppose the payments decision is binding. It still governs services/payments/**, not docs/**, where an engineer may write a comparison of databases. Before a governance layer can judge an agent action against that decision, it needs three more facts: the scope the decision covers, the operation the agent is attempting (adding a dependency, editing a migration, writing prose), and the decision’s lifecycle state at that moment. A deprecated decision should stop constraining anything. A stale one should send a person to review it.

Mneme, an open-source tool that enforces recorded architecture decisions on AI-written code, attaches scope to the rule, not to the document. Mneme enforces a decision only when the decision is active (current in its lifecycle, not superseded or retired) and carries a typed rule, a machine-checkable rule attached to the decision. Guidance text without a typed rule can be retrieved but is not enforced. A typed rule matches exact literal text, optionally limited to paths, and a rule with no path selectors applies to the whole repository.

Literal matching cannot express a principle such as the no-direct-SQL rule from earlier. That decision stays guidance unless someone reduces it to a literal, for example the text of an import that application code must not contain.

The Attested Computation precedent

Version 0.2 adds one new concept type, Attested Computation, and it shows how far the format reaches. The concept declares a sanctioned way to compute a value: a runtime such as BigQuery or dbt, typed parameters the agent may fill, an executor that names how to run it and the receipt fields a run must return (the evidence of the run, such as a BigQuery job identifier and the SQL the job executed), and an attester, deterministic code with no LLM in it, that inspects the receipt and returns a verdict.

The consumer runs the attester to confirm the agent ran the approved query and not SQL it wrote itself. The spec is plain about the boundary: OKF records the computation and the means to check it, and executes nothing.

That division of labor carries over to architecture decisions. The organization writes down what is sanctioned, in a portable file. A runtime does the work. A deterministic check outside the model decides whether the work conformed. For a revenue figure, OKF already specifies that contract. For an architecture decision, the matching contract would name scope, operations and the check, and a governance layer on the consumer side would run it. Version 0.2 does not claim that job for code, and nothing in it rules the job out.

Mneme has no OKF importer. The chain below is a design sketch that the Mneme team is exploring, not a shipped feature.

OKF v0.2 covers the first two stages, and for computed values it specifies an attestation step that resembles the fifth. Stages three and four belong to whoever turns trusted knowledge into binding constraints.

The Next Layer Is Not Memory. It Is Governance.

Open Knowledge Format is an important common language for organizational knowledge, and standardizing how agents discover what a company knows is a real contribution to the ecosystem. But structured memory alone does not solve the hardest problem in agentic engineering. The challenge is no longer whether agents can find company knowledge. OKF and the retrieval stack around it give agents a standard way to find it.

The challenge is whether agents will follow what they find. A decision the agent retrieved, referenced, and then violated is not a discovery failure. It is a governance failure, and no improvement in how knowledge is stored or surfaced closes it. The way an enforced decision reaches every agent action is its own discipline, the one we call governance propagation: a constraint checked deterministically against each proposed change before that change becomes part of the system. OKF makes the knowledge legible. Governance is what makes it binding. The next layer of agentic infrastructure is not memory. It is governance.