OKF i Claude Opus 5: com construir una wiki fiable per a agents d’IA

On July 24th, two releases landed the same day. Neither team mentioned the other. Anthropic shipped Claude Opus 5. Google Cloud shipped OKF version 0.2. Together, they answer a question that has been open since April. Where does an agent keep what your company knows? The pattern already had a name. Carpet Dee called it an LLM wiki in a gist posted on April 4th. OKF is the format that wiki lives in. Opus 5 is the thing that reads and writes it. One format, one reader. That pairing is the architecture and most of it is just markdown in a folder. Building it the obvious way hits three walls. I want to walk you into all three. Wall one, a million token window is not a place to dump your wiki. Wall two, there is a study saying agent written context files make agents worse. Wall three, your agent reports a revenue number. Prove it ran finances query and not its own. Version 0.2 answers two of those in front matter. Opus 5 answers the first.

Start with the reader because its spec sheet changed the design. Opus 5 ships a 1 million token context window and here is the detail that matters. 1 million is both the default and the maximum. There is no smaller variant to fall back to. $5 per million tokens in, 25 out, the same price as the model it replaces. Anthropic reports 96% on SWE bench verified and long context bills flat. So a 900,000 token request costs the same per token as a 9,000 token one. Thinking is on by default now. Instead of a switch, there is an effort dial with five stops. Low, medium, high, X high, max and high is where you start. Depth is something you buy per request in tokens.

The efficiency numbers are the interesting part. A trading firm measured Opus 5 setting their best score using roughly a seventh of the reasoning tokens of the previous Opus at under half the latency. A legal team reported the same quality with 26% fewer tokens at max reasoning. Box measured 8% better overall and 17% on due diligence work. Anthropic's favorite example is a task that handed the model an engineering drawing and no way to look at it. So, it wrote a computer vision pipeline, pulled the geometry out of the raw pixels, and rebuilt the part. It also scored 2.3 on their misalignment audit, the lowest of any recent Claude, with the lowest measured rate of deceptive behavior. But, the line that reframed this architecture for me came from Datadog. Their monitoring agents now manage parts of their own memory in production. One flagged a possible anomaly, rechecked its own assumption against production, found the signal was benign, wrote the correction into its memory, and retired its own queries. They described the agent treating its context as a living document. That is a wiki maintained by the thing that reads it, which is the whole idea, and in a minute, the whole problem. The memory tool makes it literal. Claude gets a /memories directory it can view, create, edit, and delete, and the API injects a standing instruction, "Assume interruption, your context window might be reset at any moment." So, a million tokens and an agent that writes. The obvious move is to load the entire company wiki on every call. That is the first wall. Chroma published a study in July 2025 called context rot. 18 frontier models, tasks kept deliberately simple, one variable moving, how long the input was. Every model degraded as the input grew. Not a cliff at the edge of the window, a steady slide the whole way up. Stanford and Berkeley had already found a sharper version. Put the fact the model needs in the middle of a long context, and accuracy falls by more than 30%. So, the window is a budget, not a bucket. Chroma's conclusion was that what matters is not whether the information is in there, it is how it is presented. There is a bill attached to. A million input tokens on Opus 5 is $5, not per day, per call. Run 100 agent calls a day and that is $500 a day, about 15,000 a month, mostly to reread the same wiki you already read yesterday. Read an index plus five concepts instead. Call it 12,000 tokens and the same call costs 6 cents. Same knowledge, roughly 80 times cheaper. Caching narrows it but does not close it. A cache hit bills at a tenth of the input price so that everything in context version still runs 50 cents a call against 6 cents, which is what a format is for.

OKF is not a service, a database, or a runtime. A knowledge bundle is a directory of markdown files and one file is one concept, a table, a metric, a runbook, an API endpoint. The file path is the concept's identity. Tables/orders.md is the concept table/orders. Your folder structure is the namespace. Each file is YAML front matter over a markdown body. Exactly one field is required and it is type, a short string like BigQuery table or metric. That is the entire mandatory surface of the spec. No schema registry, no SDK, no central authority. The spec puts it in one line. If you can cat a file, you can read OKF and if you can get clone a repo, you can ship it. We have tried the rich version of this before. AWL and RDF carry typed relations and formal reasoning and they also need schema registries and ontology engineers, which is why adoption stayed inside the companies that could afford one. OKF bets the other direction. A format weak enough for anyone to adopt beats a format strong enough to be provably correct. Links are ordinary markdown links and they are untyped on purpose. The sentence around the link carries the meaning. A table links to the metric built on it and the prose says how. Your directory becomes a graph without anyone standing up a graph database. Two file names are reserved anywhere in the tree. log.md is a dated change log, newest first, that travels next to the knowledge instead of living in a ticket system. And the conformance rules are close to aggressively forgiving. A consumer must not reject a bundle for unknown types, unknown keys, broken links, or a missing index. Half-built implementations are legal by design. It sits on GitHub under Apache 2.0 at about 7,700 stars with sample bundles built from real public data sets you can read this afternoon.

That leaves a second reserved file and it is the hinge of the whole architecture. index.md lists what is in a directory and the spec gives it one job, progressive disclosure. Let an agent see what exists before it opens anything, which is where this gets interesting because Anthropic shipped the same idea in agent skills and published the token budget for every level. Level one is front matter, a name and a description, about 100 tokens always loaded. Level two is the body, under 5,000 tokens and only once the skill is triggered. Level three is everything else and it costs nothing until something reads it. Now, hold that against the Google post which says most interactions with a concept never reach the body of the file at all. Front matter exists so the decision can be made cheaply.

Two companies that compete on nearly everything shipped the same design six weeks apart. Cheap metadata to decide with, expensive prose only on demand. When rivals converge like that, the idea is usually right. So, the architecture is not point a big model at a big folder. It is four steps. Read the index, read the front matter, decide what is relevant, then open three files, which brings me to wall two and this is the one I did not see coming.

In March, a group at ETH Zurich asked whether these context files help at all. 60,000 public repositories carry one and the question had not been tested properly. Machine-written context files made the agents worse. Task success fell about 3% against having no file at all and the extra steps pushed inference cost up by more than 20%. Human-written files helped, but only marginally. So, the document meant to make your agent smarter can end up taxing it instead. Sit with what that study could not see, though. Reading a folder of markdown, there is no field that tells you who wrote this file or whether a human ever checked it.

That is the gap version 0.2 closes with two fields kept deliberately apart. Generated records who produced the content and when. Verified records who confirmed it against the source, because the writer need not be the checker. From those two, you derive a trust tier. No verified key at all is unverified, machines only is machine confirmed, and a human actor makes it human reviewed, which turns the policy you actually want into a front matter query. Only surface human-reviewed metrics on the executive dashboard. One filter, no rewrite, no separate governance product. Two more fields carry the rest. Status walks a concept from draft to stable to deprecated. Stale after is an absolute date rather than a time to live. So, freshness is a date comparison any script can run. And provenance record signals, not a score, who authored a source, how often it gets used, when it last changed. A score would be somebody's opinion frozen at write time. Signals let the consumer judge.

Wall three has money on it. Your agent reports a revenue figure. Did it run the query finance blessed or improvise its own SQL and land on a plausible number? Version 0.2 adds a concept type for exactly this, attested computation. The document carries the sanctioned query, and the agent may fill only the declared parameters. It may not author the computation. You run it through an executor, which hands back a receipt, the job ID, the SQL that actually executed, and the result it produced. Then an attester checks it. Ordinary deterministic code, no model involved, which canonicalizes both queries and compares them. A swap table, an added filter, a drop join, and the verdict comes back false, and the consumer refuses to show the number.

Notice those are two different checks. Verified says the definition still matches policy, and it lives in the bundle. Attestation says this one run did what it claimed, and it is stored nowhere. And none of this competes with MCP. MCP is how an agent reaches your tools. OKF is what the agent knows before it reaches for one. An MCP server can serve a bundle. So, here's the whole thing concretely. A Git repository, an index at the root, concepts grouped into directories, front matter carrying type, generated, verified, status, and stale after. Your agent reads the index, filters on trust here, opens three files, does the work, then writes back what it learned with its own name in the generated field. A human verifies the ones that matter, where it is thin.

This is version 0.2, 6 weeks old. The receipt and verdict formats are explicitly to a later revision, so the attestation half is a contract, not yet a protocol. Adoption is early and mostly Google so far. And it assumes your team lives in Git and markdown, which marketing and HR do not. So, somebody ends up maintaining a bridge from Notion or Confluence. Even so, the shape is right. And this is the first version of the LLM wiki idea that ships with a trust layer instead of a promise.

If you have been keeping a claw.md and wondering what the grown-up version of it looks like, this is that. The spec is one page. Go read it before it turns into version 1.0. Cloud codes, more architecture teardowns every week.