The Sisterhood of the Travelling Ontology: Governing Agents Across Every Runtime, On Infrastructure You Never See

This continues an argument we started in The Model Is Not the Product. The short version of that piece: capability comes from the model, correctness comes from the layer around it, and we measured the difference. This piece is about what that fact lets you do next.

Where we left off

The last time I wrote about this, the result was bigger than the argument wrapped around it. On a multi-stage supply-chain compliance workflow, putting the process into an ontology and enforcing it at run time took a raw agent pipeline from about 30% reliable to 97%, and the silent failures a controls team can never accept went away entirely. That alone would be worth the piece.

But the second finding is the one that should stop you. Under that same enforcement, a cheap, open-weight model, rated well below the frontier and costing a fraction as much to run, matched a frontier model on the same work. Not approached it. Matched it. The capability gap between those two models, the gap the entire industry is priced on, the gap that justifies every dollar spent reaching for the biggest model, closed to nothing once the layer carried the correctness.

Sit with that, because it breaks the assumption underneath most AI budgets: that reliability is something you buy with capability. It isn’t. Reliability and raw capability are different things, and they come apart cleanly the moment your correctness lives in a layer you own instead of in the model you rent. Which means the model underneath becomes swappable, chosen on cost, control, and availability, not on whether it happens to top a leaderboard this quarter.

I want to follow that thread further than we did, because the model is only the first thing the layer frees. It frees three more, and they matter more.

The realization the field is having

Agent governance became a category this year. A wave of tools now sit in front of an agent’s tool calls and check them before they run. This is real progress, and it is not what we are talking about.

Almost all of it governs syntax. Can this agent call this tool, with arguments shaped like this, against this allowlist. That is a useful seatbelt, and it is also the same object the industry has built many times before under different names. The idea gaining currency, correctly, is that a capability gate is not an authorization. Knowing an agent can call transfer_funds tells you nothing about whether a particular transfer is legitimate. Legitimacy is a question about the business: which accounts, in which state, under whose approval, against what the organization has actually declared to be true. You cannot answer it from an allowlist. You can only answer it against a description of the business.

That description is the ontology. It is the same artifact that made the workflow above reliable. So for us, governance is not a new product bolted onto the side. It is what the ontology was always for. The thing that holds an agent to your process is the thing that decides whether an action is allowed, because they are the same thing: your rules, made precise, enforced at run time.

Once you see governance as a property of the ontology rather than a feature of the runtime, three things come loose that were previously nailed down.

One: the runtime becomes swappable, exactly like the model

The model is not the only commodity in the stack. The agent framework is becoming one too. A team picks OpenClaw; another picks LangGraph; a third is handed Google’s agent stack because that is where their data already lives; a fourth is running something that did not exist six months ago. Each framework ships its own governance story, and none of them travels. Govern your agents in one and you have governed nothing in the others.

If your rules live in the ontology and are enforced through a small, uniform contract that each runtime satisfies, one description governs all of them. The semantics, what the rules mean and how they are decided, live in a single engine. The runtime only has to provide a place to intercept a tool call and a place to record what happened. That is a thin adapter, a few hundred lines, not a re-implementation of your policy. Write the description once; run it under whatever framework the work lands in.

I will be precise about how strong that guarantee is, because the honest version is more useful than the loud one. For the runtimes we build and control end to end, ungoverned execution is not something the system can express, the enforcement point is the only way to act. For the runtimes we do not own, like the general frameworks, we cannot make that structural claim, so we do the next best thing and we do it seriously: we characterize the framework completely, we know every path a tool call can travel, we verify at start-up that our enforcement is actually attached to each of those paths, and we keep checking while the agent runs. If enforcement is not where it should be, the session does not start, or it stops. That is a weaker promise than owning the runtime, and we say so on the label. It is a much stronger promise than hoping a hook stays where a vendor put it.

Two: the data boundary moves to the customer

Here is the part that changes which customers you can serve at all.

To decide whether an action is allowed, the engine needs the shape of the proposed action against your ontology, the entity types, the state it claims to move through, the policy that applies. It does not need the contents. It does not need the record. The ontology is a description of types and rules, not a copy of your data.

So the enforcement can run where your data already is, on your own hardware, inside your own network, in an environment with no path to the outside at all. What leaves that boundary is not data. It is a signed statement that an action was checked and allowed, or refused, referencing types and identifiers rather than payloads. Proof, not data.

This is the difference between an AI strategy your security team can approve and one they cannot. Defense, pharmaceuticals, critical infrastructure, regulated finance, sovereign operators, none of them have a data-egress problem you can negotiate around. Their data does not leave, ever. Any platform whose intelligence depends on shipping that data to someone else’s cloud is, for these operators, a non-starter no matter how good the demo is. Because what carries the correctness here is a description and not a data pipeline, the whole governed runtime goes inside your walls, and the only thing that ever crosses the boundary is proof.

Three: the enforcement can prove itself

If every action is checked against a specific, versioned description of your rules, and each decision is recorded and signed against the exact version of the rules it was checked with, then your audit trail stops being a log and becomes evidence.

“Every action this agent took was authorized against version 47 of our rules, here is the signed chain that proves it, and here is the version.” That is a sentence an auditor or a regulator can actually work with. It is the discipline the software world spent the last few years building for supply-chain provenance, the signed, verifiable record of what produced an artifact, turned toward a new question: not what built this binary, but what did this agent do and was it allowed. Nobody in agent governance ships that yet. It falls out naturally once your rules are a versioned artifact and your enforcement signs its decisions.

One honest note, stated plainly: on hardware you fully control, the everyday guarantee is that this record is tamper-evident and that faking it works against your own interest, because a forged audit trail defeats the very compliance case you built it for. For operators who need the proof rooted in hardware rather than in incentive, that option exists and is a deliberate next step. We would rather tell you exactly what the proof rests on than imply more than it does.

An early number, and more coming

There is a public benchmark, harness-bench, built to measure exactly the failure this piece is about: whether an agent can be pulled off its task by a malicious instruction buried in its own inputs. We put a governed agent through one of its prompt-injection tasks, where the inputs quietly tell the agent to do something destructive. Graded by the benchmark’s own scorer, an ungoverned agent obeyed the injection and failed; the governed run refused it and did the real job cleanly, scoring a perfect 1.0 against the oracle where the ungoverned agent scored 0.43. It did not need a stronger model to get that right. The ontology did not permit the action.

Treat that as a teaser. It is one task, some of the scoring was done by hand, and the full run across the suite is still going, so we are not going to wave it around as a finished result. But we are running the whole benchmark, and we will publish the complete harness-bench numbers the way we published the last set: with the methodology and the receipts attached. The direction is already unmistakable, and it is the direction of everything above. Reliability, and safety, come from the layer, not the model.

The part that sounds too hard, and isn’t

There is a fair objection to all of this, and it is the right instinct to have: writing down how your business actually works, precisely enough that a machine can enforce it, sounds like a project with no end. Most of that reality is undocumented, some of it is contradictory, and a lot of it lives only in the heads of the people who do the work. What a “shipment” means here versus the textbook, which statuses are real and which are aspirational, whose sign-off actually gates what, the exceptions that turn out to be the business.

That elicitation is the work, and it is the work we do with you. You are not handed a blank schema and a manual. We start from your actual workflows and a library of patterns we have already built for operations like yours, draft the description, and then check it, hard, before anything runs, entities, actions, states, transitions, all validated against each other so a rule cannot silently contradict another. What you get out is not a plausible sketch. It is a faithful, versioned model of how your business runs, and it gets sharper every time you touch it.

The best answer we have to the skepticism is not an argument. It is a workflow. Pick one of yours, one where a mistake is expensive and the rules are real, and let us stand a governed agent up on it and watch it hold. That is the whole pitch: not a demo that impresses once, but a description of your operation that you can point at any model, run under any framework, keep behind your own walls, and prove after the fact.

What this adds up to

The earlier piece proved something that should have been front-page news and mostly wasn’t: reliability and capability come apart. A model rated well below the frontier did frontier-grade work, on real compliance operations, once the ontology and the harness carried the correctness. The most expensive assumption in enterprise AI, that you get dependable automation by buying the biggest model, is simply false where it matters most. The model is not the product. The ontology is.

This piece is the consequence. Because the ontology is the product, it is the thing that travels. It travels across models, which we showed. It travels across runtimes, so the framework becomes a choice and not a lock-in. It travels across the data boundary, so it can run where the data is not allowed to leave. And it carries its own proof, so what the agents did is a matter of record rather than trust.

You can rent reliability by the token from whichever model is strongest this quarter, on whatever framework a vendor prefers, in whatever cloud they require, and take their word for what happened. Or you can own a precise, enforceable, portable, provable description of how your business runs, and treat the model, the runtime, and the compute as things you choose. We think the second one is the whole game.