A field report on the two best objections to the first piece, and why the answer runs all the way down to code. Highly recommend to read first piece, “it’s the ontology, stupid !” from march 26.
AI use : 25% —all concepts from author, heavy review, AI for content generation and redaction.
This spring I argued that the thing deciding whether AI works in operations is not the model, the prompt, or the agent framework. It is the ontology. The data structure of the underlying knowledge graph, plus the layer almost nobody exposes: the rules that decide what a good decision looks like.
The response was more than I expected. Ten good conversations came out of it. I also had to turn down a few calls, and if you were one of them, sorry. It was a good problem to have.
The systems kept running in production, and we put more of them live. That part was gratifying and, honestly, a little boring to report. It works. Fine.
The interesting part was the pushback.
The consultants are coming
While the post was going around, every major lab was announcing armies of forward-deployed engineers headed into the enterprise. That is a good sign for the thesis, not a threat to it. The whole industry is arriving at the same conclusion: the last mile into operations is not a model problem, it is a context problem, and it takes people on the ground to solve it.
But the serious operators who read the piece did not send compliments. They sent objections. Two of them were good enough that we took them back into production and came out with a sharper answer, and better systems. Here they are.
Objection one: not everything needs an ontology
The first one: “Plenty of people are pointing agents at simple tasks and getting real value without ontologizing anything. You are overcomplicating it.”
True. And worth taking seriously.
Ask an agent to draft a reply, summarize a thread, or clean a list, and it works. Nobody needs a knowledge graph for that. So when does ontology start to matter?
Two variables decide it: tolerance for error, and depth of context.
Draft an email and get it 90% right, and you fix the last 10% in five seconds. The error is cheap. The context is shallow: almost everything the agent needs is already in front of it.
Now issue a production order for the wrong quantity, on the wrong machine, against the wrong maintenance window. The error is expensive, sometimes physical, sometimes irreversible. And the right answer depends on state the agent cannot see from the prompt: what else is running, which order matters more this week, which of the 300 pages of design rules apply to this part.
Low tolerance and high context. That is the quadrant where ontology stops being optional. It is also, not by accident, the quadrant where the money in operations lives. Nobody pays a premium to summarize an email. They pay when a wrong decision costs a shift of output.
So the objection is right, and it draws the boundary instead of erasing it. Ontology is not for everything. It is for the expensive, context-heavy decisions, which is exactly the terrain we work on.
Objection two: code was already solved, and nobody ontologized it
The second objection was better: “Code is basically solved. Agents write software all day, and that happened with no ontology. So your framing is wrong.”
We chewed on this one for weeks. It sent us deep, and it is where we learned the most.
Two things turned out to be true.
First, a code repository is not just code. It is code and context, sitting together. The recent enthusiasm for LLM-readable wikis in repos, the spread of a goals.md or an AGENTS.md at the root of projects, the conventions people now add so an agent can find its way around a codebase, these are all the same move. A version, sometimes crude, sometimes elaborate, of ontology and context engineering. Types are ontology. A good test suite is ontology. The folder structure and the README are ontology. Code looked ontology-free because the ontology was baked into the medium itself. Nobody had to build it as a separate artifact, so nobody noticed it was there.
Second, and this is the finding that changed how we think: look at how the frontier models are actually built to solve a problem.
There is no public spec, and the people who know are not talking. But the shape is visible in how the labs describe their work, and it is consistent enough to bet on. The pattern is: define the test first, then generate code until it passes. Write down what a correct answer looks like as something a machine can run, and let the model search the space of solutions until it satisfies the check. Reinforcement on verifiable rewards is the public name for one piece of it.
Sit with that for a second.
The reason code is “solved” is not only that models got good at writing it. It is that in code you can cheaply write down what good means, as something a machine can execute, and then let the machine chase it. The test is not a nice-to-have wrapped around the model. The test is the specification of good.
Which brings the whole thing into focus.
Ontology is about good and bad, not true and false
Ontology, in the ordinary sense, is names and relationships. What things are and how they connect. That is what everyone pictures when they hear the word.
The part that creates the value is different. It is the encoding of what is good and what is bad. Not what is true and what is false. Good and bad.
The distinction is not academic. A model can hand you a statement that is perfectly true and a terrible decision. “This machine can run at maximum speed” can be entirely correct and, given this order mix and this maintenance window, exactly the wrong thing to do. Truth is checkable against the facts. Goodness is a judgment about the right trade-off, in this context, under these constraints. It is the harder thing to write down, and it is where the value and the danger both sit.
Philosophers spent a couple of centuries on the gap between what is and what ought to be. Operations lives in that gap every day.
Readers of the first piece will recognize this. It is the kinetic layer: the rules that govern which trade-offs are acceptable and what counts as a good outcome, the ones living in tribal knowledge and in the 40MB Excel file that quietly overrides the ERP every Sunday. What we understand now is that this layer is not one of three. It is the whole game. Everything else is scaffolding for it.
And code is simply the one domain where humanity already did this work. Every passing test is a small, executable statement of what good looks like, written by someone who had to decide. Operations has the exact same judgments. They are just trapped in PDFs and spreadsheets and people’s heads, never made executable. The job is to get them out and make them runnable, the way a test is runnable.
This is not the harness
Worth being precise here, because it is easy to collapse this into a word already in the air: harness.
The harness is the scaffolding around a model. Tool access, the environment, the eval suite, the retries, the ability to run code and read the result. It is about what the model can do and how well it does it. It is horizontal, it is model-side, and the labs are commoditizing it fast.
What we are describing is not that. A goodness test does not measure what the model can do. It states what a good outcome is in one specific domain, where there is usually no single correct answer, only better and worse ones. You can bolt the most capable model in the world onto your factory, with the best harness money can buy, and it will still produce confident garbage, because nobody told it what good means here.
The harness is about the model. The ontology of good is about the domain. That difference is the entire reason a vertical, operations-specific company has a moat while the horizontal layer gets cheaper every quarter.
What happened when we shipped it
We took this back into production and reframed the work. Stop trying to describe the world to the agent. Start writing down, executably, what a good decision looks like, and let the agent generate against it. The quality gate I wrote about in the first piece stops being a document and becomes a test the system runs against itself.
For several of the companies we build with, this was the unlock. The systems got more reliable. And the more important part: the humans got something they could inspect and argue with. An explicit statement of good, sitting in the open, that they could correct. That is the only safe way to run any of this. A goodness function you cannot see is not a system, it is a liability.
The bet
One number to close on.
Something north of half of all tokens flowing through the big routers today are code. On the counts I trust, around 54%. Programming went from a rounding error to the single largest use of these models in about two years. The median request to a frontier model is no longer a question. It is a loop: reasoning over state, calling tools, running and checking its own work.
So here is the bet. Does that share go up, or down?
My money is on up. If the winning architecture everywhere is “write down what good looks like, then generate until you hit it,” then every domain that learns to express its own standard of good turns into a code problem. Not software in the narrow sense. Executable specification of good, and a machine searching for solutions that satisfy it. Planning, quality, procurement, maintenance, the lot. It is code all the way down.
I think most of the value created in operations over the next decade gets captured by whoever makes their domain’s definition of good executable first. That is the ontology. That is the whole post, twice now.
Want to bet ?
If this resonates
If you are an operator trying to get past pilots, or a founder building the vertical version of this, come find us. We are wrong about plenty, and we would rather be corrected fast. The two best objections to the last piece did more for the thinking than the compliments did.
Let’s build.
Thanks to the operators who sent the objections. The ontology structure, as before, owes a debt to the Morgan Stanley piece on ontology for the muggles; the production reality to the OSS portfolio companies living it.