The Open Knowledge Format Ecosystem: A Field Guide

1. What OKF is, and why an ecosystem is forming

A language model is a stateless predictor with a rolling context window, so it forgets between sessions (Micheal Lanham's "goldfish" framing covers the why). Agent harnesses paper over that by writing to the workspace: a TODO.md and a task list, a .plan scratchpad, a session-summary dump, a memory/ folder of undated notes. Call the pile agent exhaust, the files a harness leaves behind to simulate the memory the model lacks. No two harnesses agree on its shape; it is an undefined folksonomy. The deliberate files fragment too (one harness reads AGENTS.md, the next wants CLAUDE.md, a third expects .cursorrules), but those are at least authored on purpose. Either way the knowledge is real and its shape is ad hoc, so it stays trapped in whatever tool produced it. The Open Knowledge Format (OKF) exists to give that knowledge a portable shape. OKF standardizes the shape of durable knowledge, not agent behavior and not runtime memory: it does not curate the pile for you, and it is an at-rest interchange format rather than a live session-memory store. Those are adjacent problems that other tools own.

The idea of an agent keeping its knowledge as linked markdown is not new, and OKF did not arrive alone. Andrej Karpathy's "LLM Wiki" gist (April 2026) framed the pattern: raw sources plus LLM-maintained markdown pages the agent reads and rewrites. Within a quarter, Google published OKF and Garry Tan open-sourced a markdown-file agent setup, three bets on the same substrate. As The New Stack put it, the moat is shifting from the model to the markdown a team owns and accumulates. OKF is the vendor-neutral version of that bet, and the ecosystem in this guide is what grows once the substrate is shared.

OKF is, by design, almost nothing. It's an open format for representing knowledge, the metadata, context, and curated insight that surrounds data and systems, in a way that both people and AI agents can read and write. The spec (currently version 0.2) describes it in one line: "a directory of markdown files with YAML frontmatter. There is no schema registry, no central authority, and no required tooling. If you can cat a file, you can read OKF; if you can git clone a repo, you can ship it."

If you've never met YAML frontmatter, it's the little block of key/value metadata fenced by --- at the top of a markdown file:

---
type: Playbook
title: Onboarding a new data source
tags: [ingestion, runbook]
---

# Onboarding a new data source
Standard markdown from here down...

That's close to the whole format. A bundle is a directory tree of these files (the unit you distribute, as a git repo, tarball, or subfolder). Each markdown file is one concept, and its ID is just the file path minus .md. Ordinary markdown links between files carry the relationships between concepts. The only field OKF requires is type: a short free-text label like Metric or Decision, not drawn from any registry, and consumers are told to tolerate types (and any other keys) they don't recognize. There's an optional vocabulary for provenance and trust (sources, generated, verified, trust tiers, lifecycle status), but you can ignore all of it and still be conformant.

An ecosystem is forming around something this minimal because it's minimal. The format itself is trivial to parse: conformance amounts to "every non-reserved .md has parseable frontmatter with a non-empty type." The valuable work lives around the format: getting your existing content into OKF, exploring the graph of relationships once it's there, and making OKF readable and writable by AI agents. That's where the tools are appearing. This guide walks through them along the four questions a newcomer usually asks.

2. "I want a desktop app"

If you want to look at an OKF bundle (browse concepts, see the relationship graph, search, validate), there are three options at different maturity levels.

OKF Studio (saschb2b/okf-studio) is the most complete GUI. It's a Rust + Tauri 2 desktop app (a Rust core plus the system webview, with a React/TypeScript front end), MIT-licensed, at v0.9.1 with ~24 stars. It targets OKF v0.2 and does a lot: a force-directed concept graph plus treemap/sunburst visualizations, a markdown reader with frontmatter and backlink panels, full-text search with type/tag filters, spec-conformance validation, "knowledge health" and lifecycle views, integrated git, and an in-app agent host for agent-mediated editing (staged, reviewed diff-by-diff before anything touches disk). It can even open a bundle straight from a URL and adapt some non-markdown sources (PDF, CSV). A few caveats come with it. It ships prebuilt installers for Windows and Linux only; on macOS you build from source. It's a young, single-maintainer project. And its reader/validator understand v0.2, but its own "create bundle" feature still writes the older v0.1 frontmatter.

openknowledge (openknowledge-sh/openknowledge) is a Go, Apache-2.0 tool (v0.12.0, ~44 stars) that includes a web viewer (its view command) alongside a broad CLI. Because it's a Go binary plus a web front end, it sidesteps the per-OS build friction of a native desktop app, a good pick if OKF Studio's macOS story is a dealbreaker for you. It also exports to HTML, JSON, tarball, and graph formats, and ships an "insights" agent.

factile (factile/factile) is a Go, Apache-2.0, local-first tool (v0.6.0, ~2 stars) that includes a local UI bridge. It's more context/skill-oriented than the other two and its viewer is the least prominent of its features, but if you're already in the factile world it's there.

Rule of thumb: for the richest desktop experience today, use OKF Studio if you're on Windows/Linux or willing to compile on macOS. For a cross-platform, no-build web viewer, use openknowledge.

3. "I want agent tools (skills, MCP servers)"

OKF was designed with agents in mind, part of a broader shift toward software built to be consumed by agents. The tooling splits across two layers: runtime tool interfaces like MCP (the Model Context Protocol), and authoring artifacts like Agent Skills and Plugins that teach an agent how to work with OKF.

MCP servers you can point an agent at today

• factile ships a built-in MCP server. Running factile mcp serve --stdio turns the same binary into an MCP endpoint (it even offers a --read-only mode). factile hand-rolls its MCP implementation with no external SDK dependency, which shows the pattern is cheap in Go. Its tools are read/context-oriented.
• openknowledge has an mcp command and an HTTP MCP projection, so you can expose OKF operations to an agent over stdio or HTTP.
• binder ships binder mcp, a stdio MCP server that exposes binder's additive verbs (convert, validate, review, lint, graph) as MCP tools. Each tool returns the same binder.report/v1 payload as the corresponding binder <cmd> --json, and it is produce-and-validate oriented rather than read/search. Wire it into a host with claude mcp add binder -- binder mcp.
• OKF Studio consumes agent tooling rather than serving it: it's an MCP client (via the Rust rmcp SDK) and an ACP agent host.

An agent in Claude Code, Cursor, or Zed can query or validate an OKF bundle through factile, openknowledge, or binder's MCP server mode. factile and openknowledge handle reading and searching existing bundles, while binder handles conversion and validation.

Agent Skills and Agent Plugins

Agent Skills and Agent Plugins are emerging open standards for packaging instruction sets and tools for an agent (see Agent Skills on Apple Silicon). A skill is the atom: markdown instructions with optional scripts. A plugin bundles skills and the tool servers they need into a single unit. Where OKF defines what an agent knows, skills and plugins define how it behaves: atoms compared to the knowledge molecules of an OKF bundle.

OKF-specific skills

Two skills packages handle OKF workflows today:

• okf-authoring (in ghchinoy/agent-skills) is a tool-agnostic Agent Plugin bundling two skills, okf-author and okf-validate. Together they teach an agent to write and check a conformant OKF v0.2 bundle by hand: one concept per file, required type, bundle-relative links as edges, and the v0.2 provenance, trust, and lifecycle vocabulary. It needs no external binaries; it writes conformant frontmatter directly and optionally uses a CLI if one is installed.
• okf-convert is binder's companion skill and plugin. Where okf-authoring teaches an agent to write individual concepts from scratch, okf-convert teaches an agent to drive the binder CLI for bulk ingestion across an entire markdown corpus. It carries the judgment the deterministic CLI cannot encode: which conversion flags a corpus needs, what to remediate before converting, and how to triage unresolved links from the review report. For a hands-on guide to choosing among binder's surfaces, see Best Practices with binder.

The reference agent and Gemini SDKs

Google's knowledge-catalog repo (where the OKF spec lives, ~8,600 stars, Apache-2.0) ships a Python reference agent (built on Gemini/ADK) that produces OKF bundles, plus a reference-agent CLI and a viewer script. If you're building agents that emit OKF and you like Python, that's the canonical starting point.

For the SDK layer underneath agents: Go has an official, actively-maintained Gemini SDK, googleapis/go-genai (Apache-2.0, at v1.68.0). Rust has no official Google Gemini SDK, only community crates such as jeremychone/rust-genai. That asymmetry matters if you're choosing a language for an OKF-plus-Gemini agent (more in §5).

Put the pieces together and a newcomer faces a real fork, and both branches are legitimate. One branch is an all-in-one agent. Point Google's OKF reference agent (the Gemini/ADK producer described just above) at a source and let it write. It is batteries-included and strong on semantics: it generates descriptions, schema summaries, and example queries that didn't exist before, and it asks nothing of you but credentials. The cost is what generation always costs. It runs an LLM loop, so re-runs vary; it bills Gemini and BigQuery time; it needs the network; and its prose and citations are the agent's assertions rather than facts a tool derived from your files.

The other branch is BYO: bring your own agent harness (Claude Code, Cursor, Zed, or a plain script), add the OKF skills, and drive binder. The semantics come from you or your agent, while binder does the mechanical, byte-reproducible work: the same corpus in gives the same bundle out, offline, free, and CI-gateable, and it never fabricates (it stamps a generated provenance and never invents verified or a trust score). The cost is assembly. You supply the pieces and the judgment, and binder won't write a description it can't derive from what you already have.

The two branches serve different starting points. Reach for the all-in-one agent when you have a data source, no knowledge artifacts, and want semantic prose fast. Reach for BYO skills-plus-binder when you already have a corpus (agent exhaust included), need provenance you can audit, or have to run in CI with no model in the loop. They complement each other: the reference agent produces OKF from sources, binder converts a corpus you already have, and the generic okf-authoring skills work with either.

4. "I want to onboard my content to OKF (import/export)"

If you have an existing pile of markdown (a personal wiki, an Obsidian vault, a docs folder full of relative links and [[wikilinks]] and #tags) and you want to turn it into an OKF bundle with its interconnections preserved as OKF links, one tool now does this end-to-end. Until it shipped, this was the ecosystem's clearest gap.

Partial help exists around the edges:

• okfcli (okfcli/okf) has index and graph commands, but they operate on bundles that are already OKF: they build an index or a link-graph from existing OKF concepts, not from a foreign corpus.
• factile's graph code can extract markdown links for graphing, again from existing bundles, not as a corpus importer.
• OKF Studio can create a bundle and can do agent-mediated authoring (an LLM proposes concepts/edits, you review the diffs), and it has source adapters for individual PDF/CSV files. But its "create" path is single-bundle and interactive, not a deterministic batch conversion of an arbitrary markdown tree.
• Google's reference agent generates OKF bundles from sources (e.g. a BigQuery table, scraped web content). It turns a data source into knowledge; it doesn't convert an existing markdown corpus.

All of them stop at the same place: nobody ingests an arbitrary non-OKF markdown corpus and resolves its [[wikilinks]], relative links, tags, and folder structure into OKF concepts plus edges. The building blocks are easy (frontmatter injection is trivial; the format barely constrains you). The valuable, unbuilt work is the relationship extraction: walking a corpus, resolving every link and wikilink to a target concept, rewriting them into OKF's recommended bundle-relative form, folding tags and folder hierarchy into the graph, and reporting what didn't resolve. A converter like that is the on-ramp, and binder now provides it. Without one, a corpus that isn't already OKF never enters any of the viewers or agents described above.

The gap now has a tool that fills it. binder (ghchinoy/binder) is an open-source Go converter whose whole purpose is the on-ramp described above: ingest a non-OKF markdown corpus and emit a conformant OKF v0.2 bundle with the corpus's relationships turned into OKF edges.

binder is under active development, and its second phase is complete as of this snapshot. It ships a CLI with eight commands: convert, validate, index, review, lint, graph, enrich, and config. binder convert walks a plain-markdown corpus and writes a conformant OKF v0.2 bundle: one concept per non-reserved file, a root index.md declaring okf_version: "0.2", per-directory index.md navigation, and a generated provenance stamp. It preserves existing YAML frontmatter byte-faithfully on round-trip, and its native codec pairs goldmark with yaml.v3 for order-faithful output. binder validate checks OKF v0.2 §11 conformance, review summarizes a bundle (types, trust tiers, staleness, orphans, unresolved links), lint reports source-corpus health before conversion, graph exports the concept graph as dot, json, graphml, or html, enrich adds required frontmatter to a source tree in place, and config reports the resolved configuration. The output has been differentially validated against okfcli/okf v0.3.0 and opens in OKF v0.2 readers with concepts and link edges visible.

The relationship extraction the gap calls for has shipped. binder resolves standard markdown links and [[wikilinks]] (including |alias forms), #anchor targets, and in-workspace file:// URIs into OKF edges, materializes frontmatter-ref edges, merges #hashtags into tags, folds folder hierarchy into per-directory indexes, and reports what did not resolve. It also emits and preserves the full v0.2 trust vocabulary (sources, generated, verified, status, stale_after), with trust tiers and staleness derived rather than stored, and it never fabricates a credibility score. binder's whole agent-facing surface has now shipped. Machine-readable --json output and a documented exit-code contract ship across its commands; a binder-specific Agent Skill and Agent-Plugin bundle (okf-convert) ships too, installable from binder's self-hosted marketplace with /plugin marketplace add ghchinoy/binder, and a separate MCP server mode (binder mcp) exposes the same additive verbs (convert, validate, review, lint, graph) as MCP tools over stdio, each returning the same binder.report/v1 payload as --json. binder owns a thin OKF interface internally instead of leaning on another tool's parser, so it can track the spec as it evolves.

For export (the reverse direction), you're better served: openknowledge exports to HTML, JSON, tarball, and graph formats, and OKF Studio has an interoperability lab (JSON-LD / semantic-web export). And because OKF is markdown plus frontmatter, "exporting" is often as simple as reading the files.

5. "I'm a developer who wants to build on OKF"

If you want to write code against OKF, the first split is between projects that expose an importable public API and projects that keep their logic private.

Go — importable:

• factile has the widest public surface of any OKF project. Its pkg/ tree includes pkg/okf (the format core), pkg/graph (including markdown-link extraction), pkg/search, and a pkg/mcpserver you can embed. Apache-2.0. If you want a reusable Go OKF core with a ready-made MCP server, start here.
• openknowledge exposes a public okf package (ParseBundle, Validate, List, ParseAST) alongside its internal code. Apache-2.0. A solid choice for parse/validate.

Go — not importable:

• okfcli (okfcli/okf, Apache-2.0, v0.3.0) is a clean, well-organized CLI, but every functional package lives under internal/, and Go forbids importing another module's internal/ tree. You can't go get and reuse its core: you'd fork, vendor, or re-implement. It's an excellent reference design (it's v0.2-aware and small) and its Apache-2.0 license permits vendoring specific files, but it is not a runtime library. It is non-MCP by design, aiming for "agentic-first" through a machine-readable schema command, JSON-by-default output, and structured error envelopes.

Rust:

• OKF Studio factors out a GUI-free crates/okf-core (detection, parsing, graph, validation, health, retrieval, attestation), which is tested and targets OKF v0.2. It's the most feature-complete OKF core in any language, but it's a workspace crate rather than a published crates.io package, so you'd depend on it via git or a fork. MIT.

Language landscape. The two ecosystems are roughly parallel now (both have production-grade MCP SDKs and importable OKF cores), but they differ where it counts for agent tooling:

• MCP SDKs: Go has two mature options (modelcontextprotocol/go-sdk, maintained in collaboration with Google, and mark3labs/mcp-go), plus factile's proof that you can hand-roll one. Rust has one strong, production-grade option (rmcp).
• Gemini SDK: Go has the official, current go-genai; Rust has only community crates. If your build leans on Gemini, this is a real point in Go's favor.
• Desktop viewer: Rust leads here, because OKF Studio already exists on Tauri. Go's equivalent stack (Wails) is capable, but nobody has built an OKF viewer on it.

If you're writing Go: import factile's pkg/ (core + MCP + graph) or openknowledge's okf package; use okfcli as a design reference; reach for go-genai if you need Gemini. If you're writing Rust: build on OKF Studio's okf-core (via git/fork), use rmcp for MCP, and expect to lean on a community crate for Gemini.

6. Capability comparison

Legend: ✅ shipping · 🟡 partial · ❌ absent.

The projects at a glance

Capabilities × projects

binder provides the CLI, relationship extraction (wikilinks, anchors, tags, folders, file:// edges), the v0.2 trust vocabulary, JSON reports, graph export, the okf-convert Agent Skill/Plugin, and the binder mcp server.

7. Where the gaps are (and what's worth building)

Zoom out, and the ecosystem's coverage sorts into three groups:

• Well covered, so don't rebuild these. CLIs, spec validation, desktop/web viewers, relationship-graph visualization, MCP servers, and importable OKF cores exist across multiple tools. If you set out to build a Go MCP server for OKF or an OKF desktop viewer, you would be redoing released work.
• Agent Skills and Plugins. Authoring and validation skills now exist (§3 covers okf-authoring and okf-convert). Because skills and plugins are portable markdown and JSON, they are straightforward to produce and distribute across agent hosts without building custom runtimes.
• Corpus conversion. The missing piece was a converter that ingests an arbitrary markdown corpus and extracts its relationships, resolving wikilinks, relative links, tags, and folder structure into OKF concepts and edges. binder (§4) handles this ingestion path, turning scattered agent exhaust into a conformant OKF bundle with its links intact.

For a format at v0.2, the tooling around reading, viewing, validating, and serving OKF to agents is mature. The front door, turning what you already have into OKF, is now open in binder. For a hands-on walkthrough of driving it (and choosing between its CLI, Agent Skill, and MCP surfaces), see Best Practices with binder.

8. Sources & further reading

The format

• OKF spec & reference agent — GoogleCloudPlatform/knowledge-catalog (see the okf/ directory; spec is v0.2)

Tools & libraries

• openknowledge-sh/openknowledge — Go, Apache-2.0, v0.12.0 — CLI + web viewer + MCP + export + insights agent
• saschb2b/okf-studio — Rust/Tauri, MIT, v0.9.1 — desktop GUI + reusable okf-core crate
• okfcli/okf — Go, Apache-2.0, v0.3.0 — agentic-first CLI / reference design
• factile/factile — Go, Apache-2.0, v0.6.0 — CLI + built-in MCP server + importable pkg/
• ghchinoy/binder — Go, Apache-2.0, Phase 2 — corpus→OKF v0.2 converter with full relationship extraction (the ingest on-ramp); native codec (goldmark + yaml.v3), CLI convert/validate/index/review/lint/graph/enrich/config with machine-readable --json and a documented exit-code contract; a binder-specific Agent Skill + Agent-Plugin bundle (okf-convert) now ship, installable from binder's self-hosted marketplace with /plugin marketplace add ghchinoy/binder, plus a stdio MCP server (binder mcp) exposing the additive convert/validate/review/lint/graph verbs as tools
• cwest/okfctl — Go, Apache-2.0 — small author/validate/lint/search CLI
• superops-team/okf — Go, no license — "AI-agent knowledge base" (inactive)

Agent tooling specs

• Agent Skills — agentskills.io · repo agentskills/agentskills (mature; reference validator skills-ref)
• Agent Plugins — agent-plugins.org · repo agentplugins/agent-plugins-spec (v1.0.0 Working Draft)

SDKs (for developers)

• MCP: modelcontextprotocol/go-sdk · mark3labs/mcp-go · modelcontextprotocol/rust-sdk (rmcp)
• Desktop shells: wailsapp/wails (Go) · tauri-apps/tauri (Rust)
• Gemini: googleapis/go-genai (official, Go) — Rust has no official Google Gemini SDK

Background & further reading

• Andrej Karpathy, "LLM Wiki" gist (April 2026) — the origin of the LLM-maintained-markdown pattern OKF standardizes
• Janakiram MSV, Karpathy, Google and Garry Tan agree Markdown is the answer (The New Stack) — the convergence on markdown as the agent-memory substrate, and why the moat shifts to the files
• Nate, Karpathy's viral AI wiki has a flaw — the write-time-versus-query-time fork, and why a neglected wiki degrades
• XTrace, Every tool solving the AI memory problem is solving a different problem — the memory landscape (user memory, retrieval, work memory) and where at-rest markdown fits
• Micheal Lanham, From Goldfish to Elephant — why stateless models need bolted-on memory
• The Nine Layers of Agent Memory — architectural analysis of the nine concerns across three planes where formal knowledge and agent tooling meet
• Best Practices with binder: When to Reach for the CLI, Skills, or MCP — the hands-on companion for driving binder