Yesterday Google dropped an article describing an interesting idea - a portable format for knowledge sharing as markdown. This is not new or unique (llm wiki, obsidian values and even agents/claude.md are similar concepts). What stands out here is the openness of the proposed standard (also, just a v0.1 draft now) and actual ability of Google to make it a de-facto standard.
I've spent quite some time as GDE and AI integrator helping teams wire data into the LLM agents, and I keep hitting the same wall. The model is brilliant and the data is right there, but the knowledge about the data - what a table means, how a metric is defined or why a column was deprecated is, unfortunately, scattered across hundreds of different places. Something is available in company google docs or drive, the other things are available directly in readme and the extra missing piece is actually in that one engineer's head. Unfortunately, we can't write a connector for the last piece, but as Sam McVeety and Amir Hormati highlights in the blogpost we can at least help the agents (and developers) navigate through such knowledge better by introducing some shared and well known way of sharing the knowledge. And don't get me wrong, almost every team has probably already solved this in that or another proprietary way, rebuilding that same plumbing again and again from scratch.
OKF's wager against that mess is almost provocatively simple. If you can cat a file, you can read it. If you can git clone a repository, you can ship it. The spec only enforces one field to be explicitly provided - type , and that's exactly the trick: standardize only the smallest possible interoperability surface while leaving everything else to the people producing the data.
The reference repository indeed provides only the bare minimum - a pretty simple spec, example agent (which is BigQuery-oriented and pretty opinionated) and some sample bundles. And while this is a great starter pack, the idea of OKF how I see it is that knowledge lives everywhere. My SQLite file has knowledge. My Postgres instance has knowledge. My ~/notes folder and my Git history as well. If OKF is going to be a lingua franca, it needs producers for the messy real data the most of us actually work with, and it needs consumers that are not tied to any one vendor's agent.
So I built that: the OKF Skills, a vendor-neutral fleet of producers and consumers for OKF.
The idea is simple - any source in, any agent out.
What I built already is just a small baseline that I hope would be useful moving forward. That's six connectors - SQLite, MySQL, PostgreSQL, BigQuery, the local file system and Git. Each is a single portable Go binary with the same three commands: produce a bundle from the source, ingest a bundle to verify it (or --sync curated descriptions back to the source), and schema to describe itself. The SQL connectors can embed a per-column data profile and sample rows right in the concept docs.
Then three guidance skills with zero extra runtime. reader teaches an agent how to traverse any OKF bundle cheaply (index first, frontmatter only, grep before you read). The enricher teaches your harness to write good descriptions grounded in the schema, profile, and samples. And finally the producer-generator to bootstrap other connectors real fast.
I also decided to rebuild the visualizer Google team embedded into their agent. The viz renders any bundle into a single self-contained index.html near your OKF data. It produces a three-pane explorer with an interactive graph, navigator and content reader. Now there's no need to reach for Google-provided agent just to create a visualization if you just want that.
Finally, there's the mcp server that is capable of discovering every installed connector and exposes them as relevant tools. Point Claude Code or Antigravity at it and you're ready to rock. You can install all of them today with:
npx skills add xSAVIKx/okf-skills
Now you should be able to just ask your harness nicely to create, enrich and visualize the OKF bundle.
I hope this agentic tooling would allow the community to embrace the new format and truly make it a widely used standard. And also warmly welcome any new contributions to the existing connectors.
Useful links:
