For three years, the industry’s answer to “how does the AI know things about our company” has been the same: build a RAG pipeline. Chunk the docs, embed them, drop them in a vector database, and let cosine similarity find the right fragment at query time.
It works, in the sense that it usually returns something related to what you asked. Whether it returns the correct thing — the current pricing tier, the exact refund window, the schema your billing table actually uses — is a different question, and the honest answer has always been “probably, but check.”
On June 12, 2026, Google Cloud published something that quietly admits this was never going to be good enough for the facts that actually matter to a business: the Open Knowledge Format, or OKF. It’s not a database. It’s not a model. It’s a folder of markdown files with a one-line rule about how they’re allowed to be organized.
That sounds too plain to matter. It might be the point.
The problem RAG was never built to solve
Vector search is good at one thing: finding text that’s semantically similar to a query. That’s exactly what you want when someone asks a fuzzy question against a mountain of unstructured material — old support tickets, meeting transcripts, a decade of Slack. Somewhere in there is something relevant, and you don’t know exactly where, and you don’t need the single correct answer, you need a useful answer.
But a lot of what an AI agent needs from a company isn’t fuzzy. It’s exact. What’s our current SLA for a Tier 1 outage? Which column in the orders table is the source of truth for shipping status? What’s the actual formula behind “active seller,” the one finance uses, not the one an engineer half-remembers from a 2024 design doc?
Chunking destroys the thing that makes these answers reliable: structure. A table gets split mid-row. A defined term gets separated from its definition. A rule with three exceptions gets truncated after the second one, because that’s where the chunk boundary happened to fall. Then the embedding for that mangled chunk goes into the index next to five other slightly-wrong versions of the same concept, written by five people in five years, and at retrieval time the model has no way to know which one is current.
Google’s own announcement is blunt about the failure mode this format is meant to fix: production agents keep pulling knowledge that’s stale, duplicated, or simply wrong, because it was never stored as a single canonical fact to begin with — it was stored as prose, and prose has to be re-interpreted every single time it’s read.
What OKF actually is
Strip away the branding and OKF is close to boring, and Google says as much — its own post calls this “a starting point, not a finished standard.” An OKF bundle is a directory tree. Every file in it describes exactly one thing — Google calls it a “concept” — and the file’s path in the directory is its identity. There’s no ID field to keep in sync with a database row. The path is the primary key.
Each concept file has two parts: a small YAML frontmatter block up top, and a plain markdown body underneath. The spec requires precisely one frontmatter field — type — and recommends a handful of optional ones: title, description, resource, tags, timestamp. Anything else a team wants to add is allowed, and any consumer of the bundle is required to tolerate fields it doesn't recognize. That's the entire mandatory surface area of the format. You could learn to write a compliant file in about five minutes, which appears to be intentional — several early write-ups on the spec point out that the whole appeal is that there's nothing to install to author one.
Here’s what a concept file might look like inside a support-operations bundle — not the metrics example you’ll see in most write-ups, but the same idea applied to an incident-response rule:
---
type: policy
title: Tier 1 Incident Response SLA
owner: support-ops@company.com
timestamp: 2026-06-20
---
# Tier 1 Incident Response SLA
A Tier 1 incident is any outage that blocks checkout for more than 5%
of active sessions in a single region.
## Response Clock
- Acknowledgement: 10 minutes from first alert
- Customer-facing status update: 30 minutes
- Engineering lead paged: automatic, no manual step
## Explicit Exceptions
Scheduled maintenance windows do not trigger this SLA, even if
checkout is affected, provided the window was published at least
48 hours in advance in [[ops/calendars/maintenance_calendar]].
## Related Concepts
- Escalation path: [[ops/policies/escalation_matrix]]
- Underlying uptime definition: [[ops/metrics/checkout_availability]]Two things matter more than the format itself. First, the file is a complete, self-contained answer — an agent that reads it doesn’t need to guess whether it’s looking at the whole rule or a fragment of one. Second, those double-bracket links aren’t decoration. [[ops/policies/escalation_matrix]] is a real, resolvable path inside the same bundle. An agent that needs to know who gets paged next doesn't run another search — it walks the link, the same way you'd click through a wiki page, except deterministically and without ambiguity about which version it lands on.
Three things doing the actual work
It lives in git, not in a service. A bundle is just files in a repository. That means every change to your company’s canonical definition of “active user” or “Tier 1 incident” goes through the same pull request review as a code change — you can see who changed it, when, and why, in a diff. Compare that to a vector index, where updating a fact means re-chunking, re-embedding, and hoping the old, wrong vector actually gets evicted rather than lingering as a plausible-looking match.
Maintenance is meant to be agentic, not human. Google’s framing leans hard on an idea Andrej Karpathy wrote about earlier in 2026, sometimes called the “LLM wiki”: humans are bad at long-term documentation upkeep because it’s tedious and thankless, but an LLM doesn’t get bored fixing forty broken cross-links after a schema rename. The intended workflow is that when a developer changes a database column or a policy changes, an agent — not a person — is the one that goes and updates the relevant OKF files and repairs the links between them. Whether that actually happens reliably in practice, at scale, across a real organization, is genuinely unproven; OKF is a few weeks old. That’s a fair thing to be skeptical about, not a settled win.
Retrieval is a graph walk, not a similarity guess. This is the real architectural break from RAG. There’s no probability involved in following [[ops/policies/escalation_matrix]] — you either find that file at that path or you get a clean error. No "closest match," no ranked list of five documents that might be relevant, no chance that the agent silently picks the third-best result because it scored 0.02 higher than the second-best. It's the difference between asking a search engine and looking something up in an index.
Where this actually beats RAG, with a real example
Picture an AI ops agent that gets asked: “Did last night’s checkout outage in the EU region breach SLA?”
Under RAG, the agent embeds the question and searches a vector store containing old incident postmortems, a stale wiki page from 2024 with an outdated SLA threshold, and a Slack thread where two engineers were arguing about what counts as “checkout blocked.” It gets back three plausible-looking chunks. None of them is labeled as current. The model has to synthesize an answer from documents that might directly contradict each other, and it has no principled way to know which one is right. It picks one, sounds confident, and there’s a real chance it’s using last year’s threshold.
Under OKF, the agent reads the bundle’s index.md, walks to ops/policies/incident_response_sla.md, gets the exact 5%-of-sessions threshold and the exact exception clause about published maintenance windows, checks the timestamp to confirm it's current, follows the link to ops/calendars/maintenance_calendar to check whether last night's outage falls inside a published window, and answers with a citation to a specific file, owned by a specific team, last updated on a specific date. If the answer is wrong, there's exactly one file to fix, and the fix shows up as a one-line diff instead of a re-embedding job.
That second version isn’t smarter reasoning. It’s the same reasoning ability, pointed at ground truth instead of at a pile of maybe-relevant fragments.
Side by side
RAG OKF What it stores Chunked, embedded fragments of source documents Whole markdown files, one concept each How it finds an answer Nearest-neighbor similarity search Direct path lookup, then explicit link traversal Confidence in the result Probabilistic — “closest match,” not “correct match” Deterministic — the file exists at that path or it doesn’t Updating a fact Re-chunk and re-embed; old vectors can linger Edit one file, commit, done Auditability Weak — hard to say why a chunk was retrieved Strong — git history, ownership, timestamps Best suited to Large, messy, unstructured archives — tickets, transcripts, old decks Small number of facts that must be exactly right — policies, schemas, definitions
RAG isn’t going away — it’s getting demoted
The honest reading of this isn’t “OKF replaces vector databases.” It’s that RAG was being asked to do two very different jobs, and it was always mediocre at one of them. Searching a decade of unstructured support tickets for “has a customer complained about this before” is a genuinely fuzzy problem, and vector search is a reasonable tool for it. Answering “what is our current Tier 1 SLA” is not fuzzy at all — it’s a lookup, and treating it as a probabilistic search was always a mismatch between the tool and the question.
The architecture several teams are already converging on puts a router in front of both systems: a canonical OKF bundle for the small set of facts an organization needs to get exactly right, and a RAG pipeline still doing the heavy lifting on everything sprawling and historical that doesn’t fit into tidy, single-owner concept files.
incoming agent query
|
v
+----------------+
| query router |
+--------+-------+
|
+------------+------------+
| |
"is this a canonical "is this a fuzzy,
fact — SLA, schema, exploratory search
definition, policy?" across history?"
| |
v v
+---------------+ +------------------+
| OKF bundle | | RAG / vector DB |
| exact, git- | | tickets, decks, |
| versioned, | | transcripts, |
| linked facts | | unstructured logs |
+---------------+ +------------------+That’s not a retirement notice for vector databases. It’s a demotion from “the default answer to every context problem” to “the right tool for the specific, sprawling, unstructured part of the problem.” Which, honestly, is closer to what it should have been from the start.
The catch worth naming
OKF is three weeks old as of this writing. Google itself calls v0.1 a starting point rather than a finished standard, and it’s explicit that the spec covers structural interoperability — how files are shaped and where they live — without yet solving semantic interoperability: two teams can both write perfectly valid OKF files describing “active user” and land on incompatible definitions, and the format has no opinion about that. It also assumes someone disciplined enough to keep a bundle from rotting into the same mess it’s meant to replace — the “agents maintain it automatically” story is the plan, not yet a track record.
None of that makes it a gimmick. It makes it what it actually is: an early, deliberately minimal spec for a real and specific problem — the fact that agents keep getting the exact things wrong that they most need to get right. Whether it becomes the default is a question the next year of adoption will answer, not this article.