OKF Ecosystem Tools

An honest inventory of what exists today (Jun 2026) around the Open Knowledge Format. For each tool: what it does, how mature it actually is, and whether you should bother.

1. Reference Enrichment Agent (BigQuery → OKF Bundles)

What it is: An agent that pulls metadata from a pluggable source (currently only BigQuery) and emits a complete OKF bundle — a directory of markdowns with YAML frontmatter ready for humans, LLMs, and catalog tools.

How it works:

• BQ pass: Generates one OKF doc per concept using BigQuery metadata alone (schemas, descriptions, tables).

• Web pass: The LLM (Gemini via ADK) acts as its own crawler. It receives a list of seed URLs (via --web-seed or --web-seed-file), fetches them via a fetch_url tool, and follows outbound links that look like authoritative documentation for existing concepts. For each fetched page, the agent makes one of three decisions:

  • (a) Enrich — add citations, schemas, or join paths to one or more existing concept docs
  • (b) Mint — create a standalone references/<slug> doc for the page
  • (c) Skip — the page isn’t relevant enough

  A hard --web-max-pages cap and a same-domain allowed-hosts filter (--web-allowed-host) prevent the agent from overrunning. Use --no-web to skip the web pass entirely.

Stack: Python 3.13, Google Agent Development Kit (ADK), Gemini as the model backend.

Running it:

# Install
python3.13 -m venv .venv
.venv/bin/pip install -e .[dev]

# Credentials
gcloud auth application-default login
export GEMINI_API_KEY=<your-key>  # or Vertex AI

# Run (minimal)
.venv/bin/python -m enrichment_agent enrich \
    --source bq \
    --dataset <project>.<dataset> \
    --web-seed-file seeds.txt \
    --out ./bundles/<name>

# BigQuery only (no web crawl)
.venv/bin/python -m enrichment_agent enrich \
    --source bq \
    --dataset bigquery-public-data.ga4_obfuscated_sample_ecommerce \
    --no-web \
    --out ./bundles/ga4

Included sample bundles:

• bundles/ga4/ — GA4 e-commerce
• bundles/stackoverflow/ — Stack Overflow public dataset
• bundles/crypto_bitcoin/ — Bitcoin blocks/transactions

Link: github.com/GoogleCloudPlatform/knowledge-catalog/tree/main/okf

Limitations:

• BigQuery is the only implemented source (the Source interface exists but nothing else plugs in)
• Requires Gemini API key or Vertex AI configured
• Web pass can burn through tokens fast if you feed it too many seeds
• No incremental updates — runs from scratch every time

🟡 Maturity: Functional proof of concept. The bundles it produces are legit and useful. But the agent itself is a demo of what’s possible, not a product. It genuinely works for BigQuery public datasets. For production use, you’ll want to customize prompts and seeds — and probably add caching.

2. Static HTML Visualizer (viz.html)

What it is: A visualize subcommand that takes any OKF bundle and spits out a self-contained HTML file — interactive concept graph, detail panel, search, type filters, backlinks. No backend, no installation on the viewer side.

What you get:

• Force-directed graph (Cytoscape.js) with nodes colored by type
• Side panel with rendered frontmatter + markdown body
• Navigable internal links within the viewer
• “Cited by” section (computed backlinks)
• Search by title, ID, tags
• Alternative layouts (cose, concentric, breadthfirst, circle, grid)

Generating it:

.venv/bin/python -m enrichment_agent visualize --bundle ./bundles/ga4
# Produces bundles/ga4/viz.html

# Customize
.venv/bin/python -m enrichment_agent visualize \
    --bundle ./bundles/crypto_bitcoin \
    --out /tmp/btc.html \
    --name "Bitcoin OKF"

Using it: Open viz.html in any modern browser. Host on a static file server, email it to someone, commit it to the repo. It just works.

Link: Same repo — okf/README.md#visualize

Limitations:

• Large bundles produce heavy HTML files (everything is inlined as JSON)
• The viewer is a minimal SPA — no pagination, no lazy loading
• Depends on CDN for Cytoscape.js and marked.js (not truly offline without tweaks)

🟢 Maturity: This one actually works. It’s simple, does what it promises, and the viz.html files committed to the repo are great for demos. For bundles with 10–50 concepts, it’s perfect. At 500+, you’ll probably hit performance walls.

3. kcmd CLI + MCP Server (Metadata as Code)

What it is: A bidirectional sync tool between local metadata (YAML/markdown on your filesystem) and Google Cloud Knowledge Catalog (formerly Dataplex). Think “git for metadata” — you edit locally and push/pull to the cloud catalog.

Format: YAML for entries, sidecar .md files for rich content (overviews, descriptions). Hierarchical layout mirroring the resource structure.

Distribution: TypeScript library (npm install kcmd), standalone CLI (kcmd), and an MCP server.

CLI usage:

# Initialize a snapshot from a BigQuery dataset
kcmd init --bigquery-dataset <projectId>.<datasetId>

# Pull metadata from catalog
kcmd pull

# Check local changes
kcmd status

# Push changes to catalog (with dry-run)
kcmd push --dry-run
kcmd push

MCP Server config:

{
  "mcpServers": {
    "kc-mac": {
      "command": "kcmd",
      "args": ["mcp", "--path", "/path/to/root"]
    }
  }
}

Available MCP tools: pull, push, list-entries, lookup-entry, modify-entry.

Where you can plug it in:

• Gemini CLI / Google AI Studio
• Claude Desktop (via MCP config)
• Cursor / VS Code (any editor with MCP support)
• Custom agents (LangChain, ADK, etc.)

Link: github.com/GoogleCloudPlatform/knowledge-catalog/tree/main/toolbox/mdcode

Limitations:

• Requires a GCP project with Knowledge Catalog enabled
• Auth via gcloud only (no direct service account support)
• The YAML/sidecar format differs from pure OKF (it’s oriented toward the Dataplex catalog)
• Documentation is still sparse

🟡 Maturity: Early product, but well-structured. The CLI works, the MCP server is real, and the push/pull workflow makes intuitive sense. The fact that it ships as library + CLI + MCP shows intent to serve varied environments. Still no versioned npm releases though — so pin your expectations accordingly.

4. Google Cloud Knowledge Catalog (The Backend)

What it is: The GCP product (formerly Dataplex) that acts as an AI-powered metadata catalog. It’s the “official backend” that the tools above sync with.

Relevant features for OKF:

• 🆕 Native OKF ingestion — Knowledge Catalog now ingests OKF bundles directly. See the demo and code.
• Automatic harvesting from BigQuery, AlloyDB, Spanner, Cloud SQL, Firestore, Looker
• Third-party integrations: Ab Initio, Anomalo, Atlan, Collibra, Datahub
• Native Gemini enrichment — generates descriptions, glossaries, maps entities
• Sub-second semantic search for agents
• Context APIs + MCP tools for agents to discover assets
• Data products — asset packaging with SLAs and governance

Pricing (summary):

• Free tier: 100 DCU-hour/month + 1 MiB storage + 1M API calls/month
• Standard: $0.06/DCU-hour
• Premium (lineage, quality, profiling): $0.089/DCU-hour
• Storage: $2/GiB/month (above 1 MiB)

Link: cloud.google.com/products/knowledge-catalog

Limitations:

• GCP vendor lock-in (that’s literally why kcmd exists — portability bridge)
• Pricing can scale fast with heavy DCU-hour usage
• The “native format” is NOT OKF — OKF is the portable interop layer

🟢 Maturity: GA Google Cloud product. It’s real, runs in production, has SLA, has enterprise support. The Knowledge Catalog itself is mature — what’s new is the open-source tooling around it.

5. Possible Integrations

5.1 Obsidian

Status: No official plugin. But OKF was deliberately designed to work with Obsidian out of the box.

Why it just works:

• OKF bundles are directories of .md files with YAML frontmatter — exactly what Obsidian expects
• Internal links work as relative paths
• Frontmatter tags show up natively
• The index.md works as an index note

How to use today:

1. Generate a bundle with the enrichment agent
2. Open the bundle directory as a vault in Obsidian
3. Navigate, edit, use the native graph view

What a proper plugin would add:

• Inline validation (OKF conformance linting)
• Templates for new concepts
• Sync with Knowledge Catalog via kcmd

🟢 Natural compatibility. No plugin needed — works by design. A plugin would be nice for validation, but it’s not blocking anything.

5.2 GitHub Actions

Status: No official Action published. But every command is scriptable.

Possible workflows:

# .github/workflows/okf-validate.yml
name: Validate OKF Bundle
on: [push, pull_request]
jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: '3.13'
      - run: pip install okf-validator  # when it exists
      - run: okf validate ./bundles/

# .github/workflows/okf-enrich.yml (advanced)
name: Enrich on Schedule
on:
  schedule:
    - cron: '0 6 * * 1'  # Every Monday
jobs:
  enrich:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: pip install -e ./okf[dev]
      - run: |
          python -m enrichment_agent enrich \
            --source bq --dataset ${{ secrets.BQ_DATASET }} \
            --no-web --out ./bundles/weekly
      - uses: peter-evans/create-pull-request@v6
        with:
          title: "chore: weekly OKF enrichment"

🟡 High potential, zero official implementation. The “enrich → commit → PR” workflow is natural for OKF. Someone should publish a reusable Action — it’s low-hanging fruit.

5.3 Coding Agents (Claude, Codex, Cursor, Gemini)

Status: No official skill published. This is the most obvious gap.

What exists today:

• The OKF README works as documentation for an agent to understand the format
• The SPEC.md is readable enough for an LLM to generate conformant bundles
• The toolbox/enrichment uses tools/skills/ as an agent skill directory

What’s missing:

• A standalone .md skill that teaches any agent to produce OKF
• Generation-time validation (the agent checks conformance before saving)
• Reusable templates for common scenarios (SaaS metrics, analytics, APIs)

Skill pattern already used by the toolbox:

---
name: fileset-source
description: >
  Use the fileset source to find relevant markdown documents...
---

[tool usage instructions]

🟡 Clear opportunity. The OKF format was made to be agent-friendly, but nobody has packaged it as a distributable skill yet.

Maturity Map

For a visual overview of where every tool sits (maturity × ease of use), see the dedicated Ecosystem Map.

6. Community Tools

The OKF spec went live June 12, 2026. Within weeks, independent implementations appeared across every category.

Generators & Producers

Tools that create OKF bundles from existing content.

AgentFitech

A startup that built OKF support (producer + consumer) within 24 hours of the spec’s release. Documented their process on Medium: “Google just standardized ‘How AI Agents read the web’. Here’s how we shipped it in a day.”

Takeaway: The format is simple enough that a small team can go from zero to conformant in one sprint.

Link: medium.com/@AgentFitech

kb.duyet.net

A developer (Duyet) converted their existing knowledge base into a strict-conformant OKF bundle — nested topics, ISO-8601 timestamps, reserved index files.

Takeaway: If you already have markdown-based documentation, converting to OKF is trivial. Add type to frontmatter. Done.

Link: kb.duyet.net

Standards & Profiles

Formal extensions and profiles built on top of OKF.

W3C Holon CG (DataBook)

The W3C Holon Community Group (30+ participants at inaugural meeting, June 19, 2026) is proposing DataBook as a formal OKF profile for semantic web use cases.

What DataBook adds on top of OKF:

• IRI-based identity (id: field)
• Version tracking and author provenance
• Typed fenced blocks carrying RDF (Turtle, JSON-LD), SPARQL, SHACL
• Push to SPARQL triplestore via Graph Store Protocol
• SHACL validation gating deployment

Status: Proposal stage. Filing issue on OKF GitHub repo.

Implication: The semantic web community sees OKF as a valid base layer worth extending — not a competitor to displace.

Link: The Ontologist — “The Format Convergence”

🟡 Maturity: Proposal. Validates OKF’s extensibility design. If it lands, OKF gets formal ontological typing for free via profiles.

Publishing & Visualization

Tools that turn bundles into sites or visual graphs.

Suganthan Web Converter

Paste a URL or sitemap, and it crawls up to 100 pages, strips the chrome, converts each page into an OKF concept with cross-links, and hands you the bundle as a zip. The visual graph alone — dots for pages, lines for links — is worth running even if you never touch the bundle. You’ll spot orphan pages in seconds.

Link: suganthan.com/free-seo-tools/okf-generator/

🟡 Maturity: Functional. Works at page level (one file per page). True concept extraction — pulling distinct ideas out of prose — is the harder next step nobody’s cracked yet.

Suganthan WordPress Plugin

This is probably the fastest path to a live OKF bundle for most sites on the web. Install a plugin, activate it, and your content is already serving at /okf/. No export step, no cron job, no markdown files to maintain by hand.

The plugin watches publish and edit events. Every time you hit “Update” on a post, the bundle rebuilds. The dashboard shows a graph of your internal links — same engine as the web tool above, wired straight into WordPress.

The practical bits:

• Posts and pages become OKF concept files (frontmatter + clean markdown body)
• Served at yoursite.com/okf/ with pretty permalinks, or yoursite.com/?okf=index.md without
• Settings page lets you include/exclude by post type
• GPL, free, open source — read-only (never touches your content, removing it leaves zero traces)

Needs: WordPress 6.0+, PHP 7.4+, pretty permalinks on (Settings → Permalinks — anything except “Plain”).

Install:

1. Grab the zip: uploads.suganthan.com
2. Plugins → Add New → Upload Plugin → pick the zip → Install → Activate
3. Done. Check the OKF menu for the graph. Already live at /okf/.

Also submitted to the WordPress Plugin Directory — pending review.

Link: suganthan.com/blog/open-knowledge-format/

🟢 Maturity: Ready. WordPress powers roughly 40% of the web. For that slice, this is install-and-forget — the bundle stays current without you thinking about it.

superops-team/okf CLI

A Go CLI that scans a Git repository and generates an OKF bundle from the source code — think okf init and you get a .okf/knowledge/ directory with one concept per meaningful file. Comes with incremental updates via git hooks, a built-in linter (13 rules), and a query engine for searching by type, tags, or full-text.

What makes it interesting:

• okf init → scans your repo, generates the bundle
• okf hook -type post-commit → installs a git hook that keeps the bundle fresh on every commit
• okf lint → validates against OKF spec (errors for missing type/title, warnings for style)
• okf search -q "database" → filter by type, tags, or free text
• Incremental updates — only regenerates concepts for files changed since last commit

Install: one-liner (curl | bash), go install, or pre-built binaries (Linux, macOS, Windows — amd64/arm64).

# One-liner
curl -fsSL https://raw.githubusercontent.com/superops-team/okf/main/scripts/install.sh | bash

# Or via Go
go install github.com/superops-team/okf/cmd/okf@latest

Stack: Go, Apache 2.0 license. v1.2.0 released Jun 16, 2026.

Link: github.com/superops-team/okf

🟢 Maturity: Functional, released. Clean architecture (separate packages for parsing, linting, querying, git). The git hook approach fills a real gap — most other tools are one-shot generators, this one keeps the bundle in sync as code evolves. Small community (10 stars), but shipped with stress tests and cross-platform binaries.

Validators & Linters

Tools that check OKF conformance.

okflint (Linter)

Remember the gap on this page that said “a plugin would be nice for validation, but it’s not blocking anything”? okflint fills it — not as a plugin, but as a CLI. A deterministic linter (zero LLM) that validates OKF bundles against the spec and against rules you declared in your own manifest.

The honest analogy: Ruff for documentation. Runs, reports, exits with a code. That’s it.

Two commands, different philosophies:

• okflint audit — X-ray of your base. Broken links, split candidates, stats. Always exit 0 — observation, not a gate.
• okflint validate — CI gate. Pass? exit 0. Fail? exit 1. Period. Built for pre-commit hooks and pipelines.

The clever bit is the three-tier system:

The middle layer is where it gets interesting. OKF is deliberately minimal (basically just requires type in frontmatter). But in practice every team wants more: “every ADR needs a created field”, “status can only be draft/prod/obsolete.” okflint lets you declare that in a YAML manifest (okf-base.yaml) and then enforces it. No vocabulary comes hardcoded — the engine is fully generic.

One detail that matters if you use Obsidian: it resolves [[wikilinks]] against the entire vault, not just the bundle. A link to a note outside the bundle won’t trigger a false positive.

Install:

# Via uv (recommended)
uv tool install okflint

# Or pip
pip install okflint

# Validate a bundle
okflint validate --manifest okf-base.yaml ./my-bundle/

In CI it looks like this:

- name: Validate OKF conformance
  run: |
    pip install okflint
    okflint validate --manifest docs/okf-base.yaml docs/

18 documented rules (with error examples and fix instructions for each), JSON output for pipeline parsing.

Stack: Python 3.12+, MIT. v0.1.0 released Jun 27, 2026.

Links: github.com/mattdav/okflint · PyPI · API docs

Author: mattdav

How it fits with superops-team/okf: complementary, not competing. The Go CLI generates bundles from source code and keeps them in sync via git hooks. okflint doesn’t generate anything — it only validates. One produces, one gates. Makes sense to use both.

🟢 Maturity: Released. Tight scope — does one thing well. The real differentiator is the profile system: you declare your rules, it enforces them. No magic, no AI, no baked-in opinions.

Kiso (Publishing)

Kiso takes an OKF bundle and turns it into a static website that serves both humans and AI agents. It’s a Java CLI (Apache-2.0) with a dead-simple surface: check validates your markdown structure, build generates the site. The output automatically includes llms.txt and sitemap.xml — no extra config needed.

What makes it worth a look: it ships a GitHub Action so you can wire it into CI in minutes, supports DaisyUI themes for styling without touching CSS, and uses publishing profiles (.kiso/<profile>/configuration.yaml) so you can maintain multiple output configs from one bundle. The check command runs validation before building, which means broken structure fails fast instead of producing a broken site.

Quick start:

# Validate your bundle
./kiso-cli check --source=my-bundle

# Build the static site
./kiso-cli build --source=my-bundle --destination=public

GitHub Action:

- name: Build with Kiso
  uses: oak-invest/kiso/applications/kiso-cli-action@v0.1.3
  with:
    command: build
    source: my-bundle
    destination: public

Configuration (.kiso/configuration.yaml):

site:
  baseUrl: https://knowledge.example.com/
  language: en
  title: My Knowledge Base
  description: Documentation for humans and AI agents

theme:
  name: corporate

content:
  ignorePatterns:
    - drafts/**
    - internal/**

Stack: Java · Apache-2.0 · v0.1.5 (Jul 2026)

Link: github.com/oak-invest/kiso · Website

🟢 Maturity: Released. It works, it ships tagged releases, and the GitHub Action means you can actually use it in production pipelines today. Still a young project (12 stars, five-month history), so expect rough edges and breaking changes between minors — but the core loop of validate-then-build is solid and the output is correct.

OpenWiki 0.2 (LangChain)

Reads your codebase, generates a structured wiki in OKF format, and wires it into agent instruction files (CLAUDE.md, .cursorrules, AGENTS.md). Coding agents then read the wiki instead of re-discovering project context from scratch every session. Harrison Chase announced OKF support with “there needs to be an OPEN standard for memory. OKF is one such standard.”

The practical value: you stop repeating yourself to agents. OpenWiki maintains a living knowledge base that stays in sync with your code. It handles the tedious parts (architecture summaries, module relationships, key decisions) and outputs them in a format any LLM can parse without custom tooling.

Quick start:

pip install openwiki

# Generate wiki from your codebase
openwiki init --path .

# Update after changes
openwiki sync

# Wire into agent instruction files
openwiki wire --target claude,cursor

Stack: Python · MIT · v0.2 (Jul 2026)

Link: github.com/langchain-ai/openwiki · Blog post

🟢 Maturity: Production-ready. Backed by LangChain (the org, not just the framework). The wire command that injects context into agent files solves a real daily pain point. OKF adoption here signals that the format has crossed from “spec Google published” to “thing other companies build on.”

Trust & Provenance

Verification, signatures, and on-chain proof for bundles.

signed-okf (Trust Layer)

OKF metadata includes a last_updated timestamp. That’s it. No way to verify who wrote it, whether it was tampered with, or if the claimed authorship is real. signed-okf adds the missing trust layer: cryptographic signatures on individual concept files and entire bundles, with optional on-chain anchoring via OriginTrail’s Decentralized Knowledge Graph.

The problem this solves becomes obvious when OKF bundles start flowing between organizations. If an agent ingests a bundle claiming to be “Goldman Sachs investment criteria,” how does it know? signed-okf gives you verify as a one-liner. Google acknowledged this gap in the v0.1 spec discussion.

Quick start:

pip install signed-okf

# Sign a bundle
signed-okf sign ./my-bundle/ --key ~/.keys/okf-signing.pem

# Verify a bundle
signed-okf verify ./their-bundle/

# Anchor to OriginTrail DKG (optional)
signed-okf anchor ./my-bundle/ --network mainnet

Stack: Python · Apache 2.0 · v0.2.1 (Jul 2026)

Link: github.com/dynamicfeed/signed-okf · dynamicfeed.ai

🟡 Maturity: Early but solving a real gap. The signing and verification work. The OriginTrail integration is functional but adds complexity most teams don’t need yet. Small star count, young project. Worth watching because provenance becomes critical once OKF bundles are consumed across trust boundaries.

Agent Memory & Skills

OKF as runtime memory or instruction set for AI agents.

hermes-okf (Agent Memory)

A filesystem-based memory system that stores everything an agent decides, observes, and plans as OKF concept files. Every session builds on the last. The knowledge graph is human-readable markdown you can inspect, edit, or version-control with git.

What separates this from “just dump JSON to disk”: the memory is structured by OKF types (decisions, observations, context, plans), cross-linked with internal references, and queryable through the HermesAgent tool registry. The agent doesn’t just remember; it navigates its own history as a knowledge base.

Quick start:

pip install hermes-okf

# Initialize memory for a project
hermes-okf init --project my-app

# Use with HermesAgent
from hermes_okf import HermesAgent, MemoryStore

store = MemoryStore("./memory/")
agent = HermesAgent(memory=store)

Stack: Python · MIT · v0.4.4 (Jul 2026)

Link: github.com/EliaszDev/hermes-okf · PyPI

🟡 Maturity: Functional, niche audience. Works as advertised. The tight coupling to HermesAgent limits adoption to that ecosystem. If you use Hermes, this is the obvious memory backend. If you don’t, the architecture is still interesting as a reference for how OKF can serve as agent memory. ~30 stars, active development.

Inkeep Open Knowledge

A documentation editor built for the LLM era. Ships an okf starter pack that generates a conformant OKF knowledge base from your first commit. The editor itself renders markdown with live frontmatter validation, internal link resolution, and a concept graph sidebar.

The pitch: teams already writing docs in markdown get OKF conformance without changing their workflow. The starter pack wires up the directory structure, adds the manifest, and validates on save. Think of it as “OKF by default” rather than “convert to OKF later.”

Quick start:

npx create-open-knowledge my-kb --template okf

cd my-kb
npm run dev
# Editor live at localhost:3000 with OKF validation active

Stack: TypeScript/React · MIT · v0.9 (Jul 2026)

Link: github.com/inkeep/open-knowledge · Docs preview

🟡 Maturity: Promising, pre-1.0. The editor works and the OKF template is conformant. Still missing: collaborative editing, hosted version, plugin system. Inkeep has funding and an existing product (AI search widget), so this isn’t a weekend project that’ll be abandoned. Worth trying if you’re starting a new knowledge base from scratch.

knowledge-template (Science)

A conformant, empty OKF bundle designed specifically for scientific knowledge management. One fully annotated example per concept type (hypothesis, method, dataset, finding, review). Every file includes inline comments explaining why each frontmatter field exists and what goes there.

Conformance target: OKF v0.1 core plus the Open Science Pillars requirements from SPECIFICATION.md §5 (reproducibility metadata, citation chains, data provenance links). Fork it, delete the examples, start filling in your own research. That’s the entire workflow.

Quick start:

# Clone the template
gh repo create my-research-kb --template open-science-pillars/knowledge-template

# Or just grab the structure
git clone https://github.com/open-science-pillars/knowledge-template.git
cd knowledge-template
# Read SPECIFICATION.md §5 for the profile requirements
# Delete example files, keep the structure

Stack: Markdown (no runtime) · CC-BY-4.0 · v1.0 (Jul 3, 2026)

Link: github.com/open-science-pillars/knowledge-template

🟢 Maturity: Ready to use. It’s a template. There’s nothing to break. The annotated examples are genuinely helpful for understanding how OKF maps to scientific concepts. If you’re in academia or research and want to organize knowledge in a format agents can consume, start here. Published two weeks ago, already referenced by three university labs.

OriginTrail DKG + OKF

Connects OKF bundles to the OriginTrail Decentralized Knowledge Graph. Each bundle gets an owner, a cryptographic proof of origin, and immutability recorded on-chain. Built on top of signed-okf. The real value: AI agents can query the DKG, verify who published a bundle, and decide whether to trust it based on on-chain attestation rather than blind faith. This is the first integration that treats OKF bundles as verifiable assets rather than static files.

Quick start:

# See the integration guide in the blog post below.
# Requires a DKG node or access to the OriginTrail testnet.

Stack: TypeScript · MIT · v0.1 (Jul 2026)

Link: Google’s OKF comes to the OriginTrail DKG: A memory AI agents can trust

🟡 Maturity: Concept proven, not production-hardened. Published Jul 4, 2026 as a blog post with working code. No standalone package yet. Requires familiarity with OriginTrail’s DKG node setup. Interesting direction, but early.

openknowledgeformat.com

A community site where you paste YAML frontmatter and get instant validation against the OKF spec. No install, no CLI, no dependencies. Also includes starter templates and interactive examples showing valid bundle structures. Useful for quick checks when you’re hand-authoring bundles or debugging why a tool’s output isn’t conformant.

Quick start:

# No install needed. Open the site, paste your frontmatter, validate.

Stack: Web · N/A · Live (Jun 13, 2026)

Link: openknowledgeformat.com

🟢 Maturity: Ready to use today. Works in the browser, zero setup. Validates against the current spec. Good first stop for anyone new to OKF who wants to see what a valid bundle looks like before committing to a CLI tool.

okf-skill (Agent Skill)

A single markdown file that acts as an Agent Skill for Claude Code, Cursor, Hermes, or any agent supporting the skills format. Drop it into your .agents/skills/ directory and the agent learns how to produce and consume OKF-conformant bundles. References the full spec inline. Fills a specific gap: instead of building tooling around OKF, this makes the agent itself the tool.

Quick start:

# Clone into your skills directory
git clone https://github.com/rakibtg/okf-skill .agents/skills/okf-skill

# Or just copy the SKILL.md file into your agent's skill folder

Stack: Markdown (Agent Skill) · MIT · v1.0 (2026)

Link: rakibtg/okf-skill

🟡 Maturity: Works, but scope is narrow. It’s a single file with instructions. Effectiveness depends on your agent’s ability to follow skill files consistently. No validation logic built in. Pairs well with openknowledgeformat.com for verification after generation.

leadcraft

Analyzes a repository and generates OKF v0.1 conformant Knowledge Bundles. Output is YAML frontmatter plus a markdown directory tree. Readable by humans and AI agents. Version-controllable with git. Point it at a repo, get a bundle that describes the codebase structure in OKF format.

Quick start:

# Clone and run against your repo
git clone https://github.com/dskst/leadcraft
cd leadcraft
# See README for usage

Stack: Unknown · Unknown · v0.1 (2026)

Link: dskst/leadcraft

🟡 Maturity: Early stage, limited documentation. The core idea works: repo in, OKF bundle out. But docs are sparse and the project is new. Expect to read source code to understand configuration options. Worth watching if you want automated bundle generation from codebases.

pi-openwiki (IBM PI)

LangChain’s OpenWiki agent ported to the PI (IBM) harness. Automatically generates and maintains comprehensive codebase documentation using Pi’s AI capabilities. Produces the same OKF output format as the original OpenWiki project. If you’re already in IBM’s PI ecosystem, this gives you OKF bundle generation without switching toolchains.

Quick start:

git clone https://github.com/barvhaim/pi-openwiki
cd pi-openwiki
# Requires PI harness setup - see README

Stack: Python · Unknown · v0.1 (Jul 2026)

Link: barvhaim/pi-openwiki

🟡 Maturity: Fresh port, narrow audience. Published Jul 2026. Requires the PI harness, which limits who can run it. If you’re outside IBM’s ecosystem, the original OpenWiki is more accessible. But it validates that OKF output is portable across agent frameworks.

7. Emerging Patterns (Not Yet Tools)

These aren’t tools yet, but patterns that multiple teams are converging on:

OKF + llms.txt Discovery

Several analysts (Marie Haynes, StartupHub) speculate that llms.txt will point agents to OKF bundles. No official mechanism exists yet. The pattern would be:

# llms.txt
...
## Knowledge Bundle
- /knowledge/index.md: OKF bundle root — organizational knowledge for agents

Status: Speculation. Makes logical sense but not confirmed by Google.

OKF Marketplace / Bundle Commerce

Marie Haynes argues OKF bundles will become sellable products — lawyers, accountants, SEOs packaging their expertise as purchasable bundles that integrate into your own OKF.

Status: Pure speculation. Interesting but no infrastructure exists.

OKF + Obsidian as IDE

Karpathy’s framing: “Obsidian is the IDE. The LLM is the programmer. The wiki is the codebase.” Several teams now use Obsidian to author OKF bundles while agents maintain cross-references.

Status: Working pattern. No dedicated plugin but zero friction.

The Two Layers

The OKF ecosystem splits cleanly into two:

1. Portable layer (pure OKF): Format spec + enrichment agent + visualizer. Works standalone, no GCP required. This is where community opportunities live.

2. Enterprise layer (Knowledge Catalog): kcmd + catalog enrichment + GCP product. Works in production but demands Google Cloud infrastructure.

If you’re building for the portable layer, you can start today with zero cloud dependencies. If you need the enterprise layer, budget for GCP setup and expect a steeper ramp.

Ecosystem Timeline & Opportunities

Moved to the dedicated Ecosystem Map.