The Firm as Context

Every few weeks another model lands and it is better than the last one. Fable, Opus 5, Kimi 3.5. Each is a real step, each earns its headlines, each makes some category of work cheaper. I’m not going to argue with any of that.

But if you run engineering somewhere, the model isn’t what’s holding you back.

Building an application got easy. Building a firm’s systems did not.

Standing up a single, good-looking application is close to a solved problem now. UI work in particular has moved more than tenfold: a competent engineer with a good agent produces in an afternoon what used to take several sprints.

Now hold that against the actual job. A distributed system across front, middle and back office. A common data layer that survives contact with three vendor feeds and a settlement engine older than half the team. Events that mean the same thing on both sides of a boundary. Processes that encode why this firm books a trade the way it does rather than the textbook way. Access controls a regulator will ask about.

That work hasn’t got ten times easier. It has barely got easier at all, because almost none of it is typing. It’s knowing: the estate, the idiosyncrasies, which of the three ways to do something is the one the firm already committed to. That knowledge lives in senior engineers, and it moves at the speed of senior engineers being available.

We solve this badly, and we have for thirty years

The tooling for sharing that knowledge is the same tooling it has always been. A Word document nobody has opened since the author left. A deck that was accurate on the day it was presented. A Confluence space with four pages called “Architecture Overview”, three of them stale, none of them dated. A recurring meeting that exists because the document doesn’t.

That works well enough when the only reader is a human who asks a follow-up question when something doesn’t add up. Your readers now include a dozen coding agents, and they don’t ask. They invent something plausible and ship it. At that point the format itself is the problem.

What OKF is

The Open Knowledge Format is Google Cloud’s attempt to standardise this, published in June 2026. It takes the LLM-wiki pattern Andrej Karpathy popularised in April, a folder of markdown files that an agent reads, writes and keeps current, and makes it portable enough that a bundle written by one team’s tooling can be read by another team’s agent without translation.

The whole specification fits in your head:

• A bundle is a directory of markdown files with YAML frontmatter.
• Exactly one field is required: type, a short string saying what kind of thing the document describes.
• A handful are recommended: title, description, resource, tags. Then optional trust and lifecycle fields (generated, verified, status, stale_after) which matter more than they sound like they do.
• Two reserved filenames: index.md for progressive disclosure, log.md for chronological history.
• Documents link to each other with ordinary markdown links, and that link graph is the only structure there is. No separate schema declaring relationships.
• Consumers must tolerate missing fields, unknown types and broken links.

No SDK, no account, no database, no vendor. If you can read a text file you can consume it. The value of a format comes from how many things speak it rather than from who owns it, and that constraint is what protects it.

Here is a simplified version of what ours looks like:

How big is it, and what goes in it

We run one bundle, split at the top into technology and business. That split is a hunch rather than a finding. I have no evidence it’s the correct cut and I wouldn’t be surprised to be talked out of it. It has held up for one reason: the two halves rot at different speeds, for different reasons.

The technology half describes things that exist in a system somewhere. A design document can be checked against deployed infrastructure. An application audit can be checked against merged pull requests. All of it is verifiable, so an agent with the right read access can keep it honest without a human in the loop.

The business half can’t be checked against anything. No cloud account knows why the middle office runs an exception queue the way it does. That half needs people, on a calendar, saying out loud what changed.

Same format, same repository, same link graph. Just don’t pretend you can automate both the same way.

Three readers, one corpus

Because it’s markdown in directories, the same corpus supports very different access patterns without any of them being a compromise. An agent can walk it as a tree, follow it as a graph, or grep it like it’s 1995. A human can read it. And since it’s markdown, we point MkDocs at it and publish it as a proper internal site: searchable, linkable, decent to look at, and running off the same files the agents read rather than a copy or an export.

That last bit is what makes it viable across an organisation. Every previous attempt I’ve seen at “documentation for the AI” ended up as a second, worse copy of the real documentation, and it died the moment the two diverged. Here there’s nothing to diverge from.

Documentation that maintains itself

The other thing a strong model buys you is easy to underrate: it can cross-reference while it updates.

When a human edits an architecture document, they edit that document. When a good model edits it, you can ask it to check everything that links to it, flag whatever now contradicts, and say so in the pull request. That kills a whole class of documentation rot, the kind where two pages have been disagreeing for eight months and nobody noticed.

Pair that with CLIs and it stops being documentation and starts being a report. Give the agent gh for repositories and releases, az for deployed infrastructure and role assignments, Azure DevOps for what work actually landed, and a small purpose-built data SDK so it can query real records rather than reason about a schema diagram. “Is this still true?” becomes a question it can answer by going and looking.

We run this on a schedule, as recurring meetings per topic where a section gets rehydrated:

The quarterly pass is also where we check ourselves against SFC expectations. Do our cybersecurity and business continuity arrangements still match what’s expected of us, and if the regulator asked tomorrow, could we produce the records, or would that be a three-week scramble? The agent can assemble the pack and flag the gaps. A named person still makes the judgement, because that’s what the obligation requires.

All of it could be fully automated. It comes down to whether you trust a managed identity with standing read access across your estate, which is itself a decision that belongs written down in the bundle, in the access control section, where the next person can find it.

Every agent starts with the firm’s context

The last piece is small and does most of the work. We baked a skill into every developer’s coding agent that pulls from the bundle. Start work on any project and the agent has already read the principles, the relevant system design, the glossary and the cookbook entry for whatever you’re about to do.

The effect isn’t that agents write better code. It’s that they write our code. They use our word for the thing. They reach for the canonical model instead of inventing a local one. They produce the shape of service we already agreed on, because that shape is written down in a file they can read.

What it actually buys you

Front-to-back with one architecture instead of six. Teams that stop solving the same problem in parallel, because the cookbook entry already exists. Fewer translation layers, because everyone works from the same canonical model rather than each system’s local dialect. On the legacy side, a real migration plan, because you can’t move off a system nobody has described, and now every one of them is described.

None of that is an AI outcome. It’s what good architecture practice has always promised. What changed is the cost of keeping the documentation true, which is the reason those practices usually failed.

The quiet news

Some firms are noticing. LangChain’s OpenWiki now emits OKF bundles from a codebase directly, and a small ecosystem of viewers and linters is forming around the spec.

Mostly, though, the attention is elsewhere. There’s a new benchmark, a new model, a new demo. Meanwhile a specification that amounts to “markdown files, one required field” is what makes an organisation’s real knowledge readable by every system it owns.

That one changes more about how my week goes.

Sources: Google Cloud on the Open Knowledge Format · OKF specification and reference implementations · Karpathy’s LLM wiki gist · LangChain OpenWiki