Google OKF, Hermes and Gbrain: Folders as Knowledge Graphs
How Google's Open Knowledge Format differs from MCP and RAG, and how Hermes plus Gbrain turn plain Markdown folders into a knowledge graph agents can reuse.
This article is published in English.
Sources: **Google OKF + Hermes Agent + Gbrain:**Turn Any Folder Into a Knowledge Graph
Andrej Karpathy's "LLM-Wiki" idea, an LLM that reads and writes Markdown wikis to work on its own, has drawn a lot of curiosity. Individuals and small teams are starting to try it. When you hand work to an AI, the hard part is often not the model. It is how you give it the background it needs.
Ask it to summarize last month's order data and it cannot answer correctly unless it knows which tables hold the data, what the columns mean and how the tables join. The Open Knowledge Format (OKF) targets that kind of gap. Its main enemy is information silos, not scale.
Internal knowledge such as table schemas, metric definitions, incident guides and system join paths lives in metadata catalogs, wikis, code comments and the heads of experienced people. Every new agent project starts by collecting and relearning that context from scratch. Google Cloud's writing on OKF calls this the context-assembly problem.
What OKF is good for
Much of what an agent needs is company-specific: table definitions, how metrics are calculated, operational procedures, API specs. That material is scattered. OKF's bet is to compile it into Markdown files that Git can manage, so agents and people follow a bundle instead of re-searching from zero each time. An index.md and linked concept files become the navigable source.
By writing context down while you work with AI, you accumulate something you can reuse. That is different from stuffing a prompt every session.
How agents use it
Calling a model is rarely enough for practical accuracy. Agents need the business context, the right data definitions and past decisions. OKF gives them a curated place to look for that before they invent an answer.
OKF, MCP and RAG
Several technologies around agents get mixed up with OKF. Their jobs differ.
- OKF holds knowledge written ahead of time: definitions, contracts, runbooks.
- MCP connects agents to live tools and systems at runtime.
- RAG retrieves relevant passages from large unstructured stores at query time.
They are not rivals. The definition of weekly active users can live in OKF, while the actual BigQuery query runs through MCP. OKF bundles can also be search targets inside a RAG index. The practical question is which areas you already cover and where the gaps are.
Hermes, Wiki LLM and Gbrain
One path people take is to run an agent environment such as Hermes with Wiki LLM available by default, then add Gbrain as a memory layer. Gbrain, open-sourced by Garry Tan, stores information in a form agents can reuse later. It is closer to an external memory for LLMs than to a human-facing wiki, in the spirit of Karpathy's LLM-Wiki idea. Saved items are embedded so later retrieval can find semantically related past contexts: similar decisions, related business constraints and so on, not only exact keyword hits.
Once the environment is up, setup of Gbrain and related checks can be automated inside Hermes, including embedding configuration. Optional skill packs extend what the agent can do.
A typical deploy path puts the agent on a VPS behind a reverse proxy so it is reachable from anywhere, then confirms the first launch on the dashboard. From there the work is less about installing software and more about feeding the wiki and memory with real context.
What an OKF bundle looks like in practice
A bundle is a directory of Markdown files with YAML frontmatter. Each file is one concept: a table, a metric, an API, a runbook. Frontmatter carries the fields that need to be queryable, such as type, title, description, tags and timestamps. The body holds the prose, formulas and examples that both people and models actually read. Links between files turn the directory into a graph, not only a tree, so an agent can walk from a metric to its source table and from there to an incident guide.
Because the format is plain files, the same bundle can live in Git, ship as a tarball or sit on a static server. Pull requests become the review process for knowledge. Blame and history answer who changed the churn formula and when. No proprietary SDK stands between an engineer and the content; cat is enough to inspect a concept.
That simplicity is deliberate. Google's design notes stress a minimally opinionated contract: only a type field is required, and producers decide the rest. Humans can author bundles by hand. Export pipelines can generate them from existing catalogs. One agent can write a concept that another agent later consumes. The format is the contract; the tools at each end stay swappable.
Putting Hermes and Gbrain to work
Once Hermes is running, the day-to-day loop is closer to knowledge work than to infrastructure. You drop notes, decisions and definitions into the wiki layer. Gbrain embeds them and makes them searchable by meaning. When the agent later faces a similar question, it can pull those past contexts instead of starting from a blank prompt.
A few habits make that loop useful. Write definitions as if a stranger will read them in six months. Prefer one concept per file so retrieval stays sharp. Link related concepts instead of duplicating text. When a decision changes, update the concept rather than leaving a contradictory note elsewhere. Treat the wiki as a product, not a dump.
Optional skill packs around Gbrain extend what the agent can do without changing the core memory model. The important property is that memory and tools stay separate: memory holds what is known; tools reach out to live systems when action is needed. That separation mirrors the OKF versus MCP split described above.
Choosing a starting point
If your team already has a well-kept wiki of metrics and schemas, converting that into an OKF-shaped bundle is a natural first step. If the pain is mostly "the agent cannot see our databases," an MCP server in front of those systems may come first. If the pain is "answers bury us in Slack archaeology," a RAG index over chat and tickets may be the right wedge. Many teams eventually want all three, but starting with the loudest gap keeps the project honest.
Whatever you pick, measure whether agents stop asking the same clarifying questions. That is a better success signal than the number of files in the bundle.
Before knowledge is tidy
Looking at OKF makes one limit clear. OKF and RAG both help once knowledge is organized. Before that, useful context still hides in meeting notes, chat logs, doubts and unfinished discussions. Formats like OKF sit after knowledge has been curated. Hooks that point back to the original source sit before that. Rather than handing the model a finished answer, you give it a path back to the original context.
In the long run, not only models and prompts will matter. How information is stored and shown to AI will matter just as much.