On June 12, Google's Data Cloud team published version 0.1 of the Open Knowledge Format. Today we adopted it for our three primary specification documents. Total cost: about thirty-five lines of YAML frontmatter across three files. Total time: under an hour. This post is the record of what we did, why we did it, and where it fits in the Agentry stack.
The short version, before the details: OKF is a specification for representing durable knowledge as markdown files with a small YAML frontmatter block. That's the whole thing. No SDK, no runtime, no service, no cloud dependency. It formalizes the LLM-wiki pattern that has been emerging under a dozen names — AGENTS.md, CLAUDE.md, Obsidian vaults, metadata-as-code repositories — into something that different producers and consumers can actually exchange without translation.
We adopted it because the marginal cost is negligible, the format sits cleanly beneath our existing primitives without disturbing them, and the option of interoperability with any OKF-aware consumer downstream — including Google's BigQuery Knowledge Catalog — is now open to us for essentially free.
What OKF actually is
Strip away the marketing surface and OKF v0.1 requires one thing of every document: a YAML frontmatter block that contains at minimum a type field. That's it. The spec suggests five other structured fields — title, description, resource, tags, timestamp — but only type is required. Producers are free to add whatever custom fields they need. The body of the file is normal markdown.
A bundle is a directory of these files. The file path is the concept's identity: datasets/customers/orders.md means what it looks like it means. Concepts link to each other with normal markdown links. The result is a browseable graph of durable knowledge that any tool speaking OKF can consume without an integration.
Reading the spec, I was struck by how much of it we were already doing accidentally. Our TEMP protocol specification was already a markdown file. Our internal engineering specs were already markdown files. What OKF adds is the tiny convention layer that turns "a bunch of markdown documents" into "a bundle any OKF-aware system can read."
Where it sits in the stack
This is the strategic point of the whole exercise. OKF is not a competitor to anything Agentry does. It sits beneath our existing primitives, at the knowledge layer:
┌───────────────────────────────────────────────────────────┐
│ Transaction: TEMP escrow (Nostr kind 30090) │ ← the signed
│ Signed collaboration memory │ memory of a
│ │ specific deal
├───────────────────────────────────────────────────────────┤
│ Reputation: Soulbound attestations (kinds 30022–30027) │ ← who this
│ Verifier binding + KYC + settlement history │ agent is,
│ │ cryptographically
├───────────────────────────────────────────────────────────┤
│ Discovery: MCP + A2A + Nostr relay │ ← how agents
│ Live protocol surfaces │ find each
│ │ other
├───────────────────────────────────────────────────────────┤
│ Knowledge: OKF bundles (this post) │ ← durable
│ Specs, docs, agent metadata, runbooks │ context
└───────────────────────────────────────────────────────────┘Each layer has a different data model, a different signing story, a different mutability profile, and a different consumer:
- Transaction memory (TEMP, kind 30090) is per-contract, mutable via appended events, cryptographically signed, and consumed by escrow counterparties in real time.
- Reputation attestations (kinds 30022–30027) are per-agent, replaceable, cryptographically signed by the issuer, and consumed by trust systems and other registries.
- Discovery surfaces (MCP, A2A, Nostr relay) are live protocol endpoints that agents call on demand.
- Durable knowledge (OKF) is static, human-authored, unsigned, and consumed by anyone who needs to read about the system rather than interact with it: engineers, agents doing research, partners evaluating an integration, catalogs indexing the space.
These layers do not compete. A TEMP escrow contract is not an OKF concept; it's ephemeral signed state. An OKF concept is not an escrow contract; it's a durable description that outlives any specific transaction. Both are useful, and neither replaces the other.
The strategic value of adopting OKF at the knowledge layer is that we do not have to invent a knowledge format ourselves. Every trust-infrastructure project I've seen eventually gets a request from a partner or a customer asking "how do I browse your metadata programmatically?" and the answer up to now has been "call our API, here's the OpenAPI spec." OKF gives us a second answer: "clone this repo, it's markdown."
The three documents we converted
Three specifications, three frontmatter blocks, one commit. Every one of these documents already existed before today; nothing was rewritten. We simply added a YAML block at the top of each.
1. TEMP protocol specification
agentry.com/nip-temp.md — the public NIP draft for kind 30090 (Transaction Escrow Memory Protocol). This is the document other agent builders read when they want to implement TEMP.
---
type: protocol_spec
title: "TEMP — Transaction Escrow Memory Protocol"
description: "A Nostr NIP (kind 30090) that attaches
cryptographically signed collaboration memory
to escrow contracts between AI agents."
resource: https://agentry.com/nip-temp.md
tags: [nostr, nip, escrow, agent-commerce, kind-30090, protocol]
timestamp: 2026-05-18T04:37:00Z
status: draft
nostr_kind: 30090
version: 0.1
license: MIT
---2. Verification v2 spec
Our internal spec for the paid verification tier — soulbound Nostr binding, KYC at issuance, reputation accrual. Not yet public (we'll publish under github.com/agentry-protocol/specs when the org is live), but the document itself is now conformant and portable.
---
type: internal_spec
title: "Verification v2 — Soulbound + KYC + Reputation"
description: "Internal specification for Agentry's paid
verification tier: cryptographic identity binding,
KYC at issuance, and reputation accrual via
signed Nostr events."
resource: https://github.com/agentry-protocol/specs/blob/main/verification-v2.md
tags: [verification, kyc, soulbound, reputation, nostr, internal-spec]
timestamp: 2026-06-16T01:31:00Z
status: draft
owner: ryan-clark
target_ship: 2026-07
nostr_kinds: [30022, 30023, 30024, 30025, 30026, 30027]
---3. First TEMP transaction execution plan
The runbook for our first real end-to-end TEMP escrow contract, using Sun Gazette and Lantrn as counterparties. Also destined for github.com/agentry-protocol/specs.
---
type: execution_plan
title: "First TEMP Transaction — Sun Gazette ↔ Lantrn"
description: "Step-by-step execution plan for Agentry's first
end-to-end TEMP escrow contract using Bitcoin/Lightning
settlement, with Sun Gazette and Lantrn Editorial
as counterparties."
resource: https://github.com/agentry-protocol/specs/blob/main/first-temp-transaction.md
tags: [temp, escrow, execution, sun-gazette, lantrn, first-run]
timestamp: 2026-06-16T01:33:00Z
status: ready-to-execute
owner: ryan-clark
target_date: 2026-06-22
counterparties: [sun-gazette, lantrn-editorial]
---That's the whole change. If you want to see it live, load agentry.com/nip-temp.md and the frontmatter block is right at the top.
Why interoperability at the knowledge layer matters
Agentry's core products — the registry, the escrow service, the verification tier — are consumed through live protocol surfaces: HTTPS APIs, MCP tool calls, Nostr subscriptions. Those are the right substrates for the things they represent. Real-time trust decisions belong on real-time protocols.
But there is a second class of question that never fits well on a live protocol: "how does your system actually work?" That's a question about durable knowledge, not runtime state. Today, if you want to answer it about Agentry, you read our blog, our OpenAPI docs, our NIP drafts, and hopefully some engineering specs that we haven't published yet. Each of those lives in a different format on a different surface with different conventions.
OKF gives us a single place, a single format, and a single set of conventions for that entire class of documents. It also gives downstream consumers — anyone building an agent search engine, a metadata catalog, a trust aggregator — a machine-readable way to browse our knowledge without calling an API.
Google has stated that their BigQuery Knowledge Catalog now ingests OKF bundles. We haven't verified this end-to-end ourselves; that's on our list. But even without validating that specific integration, the value proposition is straightforward: any tool that eventually speaks OKF (and given how minimal the format is, that's likely to be a lot of tools) can index our specs without a bespoke connector.
The case for the cheap version
I want to be honest about the calculation here. OKF is four weeks old. Its adoption curve is entirely unproven. Every previous "here is the new metadata standard" moment in software history has produced roughly one hit and thirty misses. There is a meaningful chance that this specific format doesn't stick, and that the world moves on to something else in twelve months.
So why do this today?
Because the cost of getting it wrong is zero. If OKF fades, the frontmatter blocks we added today are still valid YAML in valid markdown, harming nothing and consuming no runtime. Nothing we do downstream depends on OKF being adopted; we still expose our real interfaces via HTTPS, MCP, and Nostr. The frontmatter is a hedge, not a commitment.
And the cost of getting it right is enormous relative to the cost of adopting. If OKF becomes an actual interoperability standard — even a limited one, adopted by a few catalog vendors and a couple of large clouds — then the specs and metadata we've already written in OKF format are automatically consumable. We didn't have to migrate. We didn't have to run a translation layer. We were early enough to be part of the initial cohort of producers whose bundles the ecosystem indexes.
This is what infrastructure companies should do with formats that are cheap to adopt, easy to reverse, and possibly load-bearing later. The bar for adoption is not "we are certain this will succeed." It is "the marginal cost is negligible and the option value is real."
What we deliberately didn't do
Adopting a knowledge format is one of those decisions that invites scope creep. A few things I explicitly considered and rejected:
- Rewriting the backend to store agent records as markdown. This would be silly. Our store is JSON, and it should stay that way for query performance and consistency. If we later want to expose the registry as an OKF bundle, that's a build step that generates markdown from JSON at export time. Not a runtime migration.
- Adopting Google's reference visualizer or enrichment agent. These are useful proofs of concept, but they're not our category. We are not building a general-purpose knowledge browser. We are building agent trust infrastructure that happens to publish some of its documentation in a portable format.
- Publishing the entire registry as an OKF bundle today. This is a real option and I think we should do it eventually, but it needs 100–200 lines of Python and a design decision about update frequency. It's a medium-cost step, not a cheap one. Deferred until we see actual OKF-aware consumers asking for it.
- Writing an OKF producer library or SDK. The whole point of OKF is that no SDK is required. Producing an OKF document is "write a markdown file with a YAML block at the top." Anyone writing an SDK for this is missing the point of the format.
The discipline of picking the cheap step and shipping it — rather than the expensive step and planning it — is what makes hedges actually work. This week the hedge cost thirty-five lines of YAML.
What comes next
Two things on the near-term list, both conditional:
- If any OKF-aware consumer surfaces — a partner, an investor's portfolio company, a catalog vendor, or a monitor asking us to publish more of our metadata in OKF — we'll expand from three documents to a full bundle covering the registry itself. That's the medium-cost step: nightly export of the agent list as one
.mdper agent, hosted atagentry.com/okf/registry/or in a GitHub repo. Not doing it until there's demand. - When the
github.com/agentry-protocolorg exists, all three of these specs move there as the public canonical sources, and the frontmatterresource:fields become live GitHub URLs instead of the placeholder ones we published today.
Neither is urgent. Both are cheap when the trigger event happens. That's the shape of the decision.
In the meantime, our three primary specs are now OKF-conformant. You can see the frontmatter yourself at agentry.com/nip-temp.md. The okf.concepts_published field on our public telemetry reads 3. If it later reads more than three, that means an OKF-aware consumer showed up and it was worth the expansion.
This is what infrastructure work looks like most of the time. Small, cheap, reversible, and boring — except in aggregate, over years, when the right small bets compound into the interoperability layer everyone assumed was always there.
— Ryan
Founder, Agentry