An ontology describes the rules. An engine makes them stick.

I was asked to talk about operational ontology.

Here's the honest version. I knew ontologies existed. I had read about them, nodded at the diagrams, and never really understood what made one operational. Most of what I found explained what an ontology is. Very little explained what it does once an agent is standing in front of it.

So this isn't a build walkthrough. It's the thing I wish someone had handed me first: what it is, what the parts are, and why the part that matters is not the part with the nice diagram. Everything here is a reference pattern, not a production result, and I'll say where it's weakest.

Two things hiding under one name

A few vendors sell an operational ontology as a product, and some will tell you that if you aren't buying theirs, you don't have one. I understand the pitch. I also think it mixes up a concept and an implementation.

The concept is a shared model of the business. It names the things (customers, orders, suppliers, limits, approvers), how they relate, which actions exist, and which rules govern them. That's the ontology.

The implementation is an engine that controls state through the whole operational process. It decides what can happen next, checks what has to be true first, records what changed, and lets you see why.

An ontology without an engine is a very good map that nobody is required to follow. An engine without an ontology is a rules service that doesn't know what any of its rules are about. The "operational" part is what you get when you wire them together.

Call it an OntologicalHarness

I needed a word for the wired-together version, because "ontology" kept pulling the conversation back to the map. The word I landed on is OntologicalHarness.

An OntologicalHarness is the governed scaffold an agent runs inside. It wraps the agent in a model of the business and a controlled path for acting on it, so the agent works from defined meaning and enforced rules instead of whatever it can infer from a prompt.

It enables the agent in four specific ways.

It gives the agent meaning: what the objects are, how they relate, and what each action applies to. It gives the agent constraints: the preconditions that must hold before an action fires, with BLOCK and WARN severities, and the versioned thresholds behind them. It gives the agent authority, no more and no less than its role, so what it can see and do is the same as any person in that role. And it gives the agent a path: dry run, checks, approval, execution, audit record, so every action is previewed, gated and recorded.

The word "harness" is deliberate. A harness doesn't make the agent smarter. It decides what the agent can reach, what it has to check, and what gets written down. Swap the model underneath and the harness stays put.

A quick test for whether you have one: if you changed a business rule today, would the agent behave differently tomorrow without anyone editing a prompt? If yes, the rule lives in the harness. If no, it lives in someone's memory.

Why agents need this now

Agents are arriving faster than the controls around them. Deloitte's 2026 State of AI in the Enterprise report (fielded in late 2025, covering 3,235 leaders in 24 countries) found only 21% have a mature governance model for agentic AI. Roughly 80% lack things like clear boundaries on which decisions an agent can make alone, real-time monitoring and audit trails.

Kiteworks' 2026 forecast report is sharper, with a caveat: it's a survey of 225 security and risk leaders from a vendor that sells governance, so read it as a signal and not a census. Of those surveyed, 51% already have agents in production, yet 63% can't enforce purpose limitations on what those agents are authorized to do, and 60% can't terminate one that misbehaves. They can watch. They can't stop.

And Gartner warned in May 2026 that applying one uniform set of governance to every agent leads to failure, especially when organizations blur an agent's ability to act with the scope of access it has been granted.

These numbers show the gap. They don't prove that what I'm describing closes it. But I don't read any of it as a model problem. I read it as nobody writing down what has to be true before something happens.

The parts, and what each one does for the agent

Think of it as layers, and ask of each one what it gives an agent that it didn't have before.

Governed data. The agent can only see what its role can see. Masking, tags and row-level policies apply from the first row, so grounding never starts from an ungoverned copy.

The ontology. Objects and relationships, so the agent can walk from an order to its customer, supplier, limit and approver, instead of guessing which join is right. It can live in relational tables, a graph store or a formal ontology format, and the choice matters less than people think. It answers "what is this thing, and what is it connected to?"

Rules as data. This is the layer people skip, and it's the one that makes the thing operational. Each action carries named preconditions with a severity. BLOCK stops it. WARN flags it for a human. Thresholds, like a regional exposure limit, are versioned facts with an owner, an effective date and a reason. They live in a table, not in a prompt.

The action engine. One path every change takes: dry run, precondition checks, approval where needed, execution, audit record. The same path gates people and agents. State moves one governed step at a time: observe, understand, decide, act, confirm, learn.

The semantic layer and the agent. Metrics defined once, documents the agent can search, and an agent that works under the same roles as everyone else.

I'll be fair about the evidence for grounding, because it's narrower than it sounds. One data platform vendor's engineering team compared a plain semantic-layer agent against ontology-aware variants on a deliberately simplified biomedical benchmark of 22 questions, each run five times. Accuracy went from 50.0% to 78.2%. But the best result came from combining GraphRAG with hand-curated term mappings, and the benchmark tested ontology-driven retrieval and hierarchy reasoning, not rules, approvals or state changes. The authors themselves call it directional evidence. It supports "structural context helps agents answer better." It does not support "an operational harness makes agents safer," and I'd be overreaching to claim it does.

How the grounding actually works

This is the OntologicalHarness doing its job. An ungrounded agent has a model and a prompt. It infers what a "limit" is, who counts as an "approver," and what it's allowed to do, from whatever text it was handed. It will do this confidently.

A grounded agent asks the platform instead. What is this object? How does it relate to the others? Which actions exist on it? What must be true first? Who has to sign off? Those answers come back from governed data stores, under the agent's own role, with a version attached.

That changes where the knowledge lives. It's no longer in a prompt someone has to remember to edit. It's in data that has an owner.

Picture a large order and a dry run of committing half of it. Every precondition passes. Then a steward lowers the exposure limit for that region because a supplier contract tightened capacity. The change is proposed, its impact is previewed, and a second person approves it, because the proposer can't approve their own change.

The same dry run now stops on the limit check. Nobody redeployed anything or edited a prompt. A governed fact changed, and people and the agent both behaved differently, with an audit trail showing who moved the limit, why, and which version was in force for each decision. One detail matters here: the checks have to run again at execution, not just at dry run, or a limit that changes between preview and commit gets missed.

And because the agent has a role, there's a kill switch that doesn't depend on the agent's cooperation. Revoke the role and it stops. Compare that with governing a warehouse, a graph database, a rules service, a BI tool, a vector store and an agent platform separately, then hoping the policies agree.

But surely a markdown file will do

Sure. Put the operational rules in an MD file. Call it AGENTS.md or RULES.md, add a stern paragraph about never approving anything over the limit, and trust the agent to read it, remember it and apply it the same way every single time. What could possibly go wrong with a rulebook written in prose, interpreted by a probabilistic model, edited by whoever last had the file open?

I'm being sarcastic, but I'm also serious. Rules in a text file are suggestions. They add ambiguity, because two readings of the same paragraph can produce two different actions. They add complexity, because now you have rules in a file, rules in a prompt, rules in someone's head and rules in the code, and nobody can say which one wins. And they can't be enforced. An agent that reads "do not exceed the regional limit" can still exceed it, because nothing structural stops it. The Agents of Chaos red-team study, as summarized by Kiteworks, found agents that refused a direct request but complied when asked to forward the thing containing the same data.

To be fair, I'm not saying delete your AGENTS.md. Instructions are fine for tone, preference and working style, and even that benchmark used a thin layer of hand-written mappings in the agent prompt to close the last accuracy gap. The line I'd draw is between guidance and controls. Anything that has to hold needs to be enforced by structure: a precondition that returns BLOCK, an approval that can't be skipped, a role that can't write to the table. That's what the ontology with its rules and actions gives you. The agent doesn't have to remember the rule or interpret it. The process won't let the wrong step happen.

The harness is the reusable part

Here's the idea that changed how I think about this. The engine at the center of the harness doesn't know anything about your business. It knows how to run a governed step: take an action, check its preconditions, route an approval, record the result. The business shows up as content you load into it.

Load in one ontology and you have one process. Swap the objects, actions and rules, and the same engine runs a different one.

Expense reports are a good first load because they're small and familiar. The objects are employee, report, line item, receipt, policy and approver. The actions are submit, request receipt, approve, reject and reimburse. The rules are things like a receipt required over a set amount (BLOCK), a meal over the daily cap (WARN), an approver who can't approve their own report (BLOCK), and a cost centre that must be active (BLOCK). The per diem cap becomes a versioned fact, so when finance changes it, that's a data change with a history, not a code release.

Point the same harness at purchase orders, access requests or claims, and you're changing the content, not rebuilding the machinery. I haven't run every one of those, so take that as the design intent and not a result.

The hard part isn't the technology

If I'm honest, the tables and the engine are the easy part. The hard part is people.

Every rule, threshold and action in the harness needs an owner. Not a team alias, a name. Someone who can say why the exposure limit is what it is, who is allowed to change it, and who signs off when they do. Those are your stewards, and most organizations have never had to write them down for an operational process, because the knowledge lived in a few people's heads and a lot of habit.

That's uncomfortable, and it should be. When you define the process structurally, you find out quickly which rules nobody owns, which two teams define the same thing differently, and which approval has been a formality for years. This is the same project management gap I keep seeing around AI generally: no named owner, no agreed outcome, no one accountable when it's wrong. The harness doesn't fix that for you. It forces the question.

The second hard part is learning. A governed process that never improves is just a slower way to be wrong. So build the learning strategy in from the start. Every dry run, block, warning, override and approval is a record. Review the blocks that people routinely override, because the rule may be wrong, or because a control is being quietly bypassed, and only a steward can tell which. Review the warnings nobody acts on, because they may be noise. Watch where the agent keeps proposing actions that get stopped, because that points to a gap in its context. Then let the stewards change the rule, as a versioned fact with a reason, through the same approval path as everything else. The agent can suggest a rule change. It should never be able to approve its own.

That's the last step of observe, understand, decide, act, confirm, learn. It's the one that's easiest to skip, and the one that decides whether the system gets better or just gets older.

What this doesn't do

I'd rather you hear the limits from me than discover them in production.

It only governs what goes through it. If the agent's role can also write directly to the tables, call another tool, or reach an external system, the rules are decoration. The engine has to be the only write path, which means least-privilege roles and actions that execute through controlled procedures. That's a design discipline, not a feature you switch on.

It stops forbidden actions, not wrong ones. A prompt-injected or confused agent can still propose something that passes every check and is still a bad idea. The harness limits the blast radius. It doesn't supply judgment. That's what approvals and WARN severities are for, and they only work if a human actually reads them.

It only knows the rules someone wrote down. The preconditions catch what was encoded. Everything nobody thought of sails through.

Side effects leave the boundary. When an action reimburses someone or updates an ERP, the engine controls the call, but the downstream system's governance is its own.

It overlaps with things you may already own. A skeptic will say this is a workflow engine, a policy engine and a data catalog stitched together, and they're partly right. What I'd argue is different is that the agent traverses a shared model of the business and acts against typed actions inside one governed platform. If you already run a mature BPM and policy stack, the honest question is whether you need a second one.

And that vendor pitch I mentioned at the top has a fair point buried in it. A product that ships this out of the box is genuinely different from a pattern you assemble yourself, and I'd be lying if I said assembling it was free.

For the team deciding where to start

Start with the actions, not the data. List the decisions your people make, then model what each one needs to know before it can happen. Name an owner for each one before you write a single rule. Write the preconditions down early, with severities. Treat thresholds as versioned facts with an owner and a reason. Make the dry run a first class feature so people and agents can preview before they commit.

And keep one role model. If the agent has its own identity and its own rules, you've built a second system you now have to audit.

Where you build it matters less than the properties you demand of whatever you choose. One place where enforcement runs. Roles that apply identically to people and agents. Rules and thresholds stored as versioned data with owners. A dry run before every commit. An audit trail you can query. A way to revoke an agent without touching the agent. If a platform can't give you those, no amount of ontology on top will save it.

I'll admit the part I'm least sure about is scale. A handful of rules per action is easy to reason about. A few thousand across a real enterprise is a governance problem of its own, and I don't have a tidy answer for it yet.

So what's the smallest process in your business where an agent could act, and what would have to be true first? I'd like to hear where you'd draw that line, especially if you think I've drawn mine in the wrong place.

Sources

Request early access