Defining Agentic Ontologies: Why Your Agent Needs a Model of the World, Not More Tools

September 8, 2026 AI Architecture 21 min read

#Agentic Ontology#Ontology#Knowledge Graph#AI Architecture#Agentic AI#MCP#Semantic Layer#Multi-Agent Systems#Knowledge Representation#UML#Enterprise AI#AI Governance

Somewhere in your stack there is a tool definition that looks like this: issue_refund(order_id, amount, reason), with a description that reads "Use this to refund a customer. Only refund orders inside the return window, and escalate anything large." That one English sentence is carrying an enormous amount of weight. It is a precondition, a policy, and a grant of authority, compressed into a hint and handed to a probabilistic system that has never seen your return policy and cannot query it. Most of the time it works. Then one Tuesday an agent refunds a ninety-four-day-old gift card purchase, and the retro concludes that the description needed to be clearer.

The reflex is to write a better sentence. The better answer is a layer the industry built, argued about, and then mostly abandoned twenty years ago, which agents have suddenly made indispensable again: an ontology. Not the 2005 kind — not a two-year modeling program that produces a beautiful OWL file nobody executes. I mean a small, opinionated, machine-checkable model of your domain that includes the verbs, and that your agent is structurally unable to bypass. That is what I mean by an agentic ontology, and this post defines it precisely, shows two worked examples with the UML, and makes the case that the economics finally flipped in its favor.

What an ontology actually is

Tom Gruber's 1993 definition is still the best one: an ontology is an explicit specification of a conceptualization. Unpacked, that means you write down — explicitly, in a form a machine can read — the things that exist in your domain, what they are called, how they relate, and what has to be true about them. The point is not documentation. The point is that two systems, two teams, or two agents can refer to the same thing and be provably talking about the same thing.

The word gets used loosely, so it helps to place it on a ladder — the staircase at the top of this post. Each rung buys you an answer the rung below could not give, and most organizations stop at rung three, then ask an agent to behave as though they had built rung five.

The gap that matters is between rows three and four. A schema is local: it describes how one system stores something. An ontology is shared: it describes what the thing is, independent of which of your six systems is holding a copy of it today. That distinction was academic when the consumer of the model was a report. It is operational when the consumer is an agent that will happily join two tables on a column that means different things on either side.

What makes an ontology agentic

Classical ontology languages are declarative about being. They are excellent at "a Refund is a kind of FinancialTransaction, it has exactly one Payment, and its amount is a positive decimal." They are silent on the question an agent actually has: may I issue one right now, and how will I know it worked? That silence is the entire gap.

An agentic ontology is a machine-readable model of a domain that specifies not only the entities and relations an agent can perceive, but the actions it can take, the conditions under which each action is legal, the authority required to take it, the effects it commits, and the evidence that counts as proof it happened.

Written as a structure, it is seven parts. The first two are the classical ontology. The last five are what make it agentic:

AgenticOntology := (
  C,   # concepts       -- the things that exist, with stable identity
  R,   # relations      -- how they connect, with cardinality
  A,   # actions        -- what can be done to them
  P,   # preconditions  -- P : A -> predicate over facts
  E,   # effects        -- E : A -> facts asserted afterwards
  U,   # authority      -- U : A x ActorKind -> allow | escalate | deny
  V    # evidence       -- V : A -> proof obligation
)

If that shape feels familiar, it should. Preconditions and effects are STRIPS, from 1971, and later PDDL — the planning community solved this vocabulary decades ago and we have been ignoring it because we were busy with retrieval. The authority and evidence terms are the genuinely new parts, and they exist because an autonomous actor is not a planner in a simulator. It is an actor in your production systems, spending your money, and the question of who said it could has to be answerable after the fact.

Four additions do the work, and each one replaces a sentence you are currently writing in a prompt:

• Affordances. Every concept carries the actions it can participate in, with typed input slots. Not a list of API endpoints — a list of things that can be done, expressed in the domain's own language. The agent asks "what can I do with an Order?" and gets a bounded, typed answer instead of scanning two hundred tool descriptions for keyword matches.
• Authority. Every action carries rules about which class of actor may invoke it, under what limits, and what happens at the boundary. The critical design choice is that escalate is a first-class outcome alongside allow and deny. Most real policies are not binary; they are "an agent up to this threshold, a human beyond it."
• Lifecycle. Concepts that have states carry an explicit state machine, and transitions — not just actions — carry authority. This is where "the agent can cancel, but only a human can un-cancel" lives.
• Evidence. Every action declares what would constitute proof it succeeded, and where that proof is read back from. A 200 response is not proof. A refund identifier fetched back from the processor is. This is the term almost everyone skips, and it is the one that turns an audit log into something you can actually defend.

A worked example: order operations

Abstractions are cheap, so here is a real slice. This is the fragment of an ontology that governs a single support workflow — refunding an order — modeled properly.

The concepts come first, and they look like any decent domain model, with one important addition — each concept names the systems that hold copies of it, because entity resolution is a first-class ontology concern rather than something the agent improvises:

concept: ops:Order
  aliases:          [purchase, sales order, "the order", SO]
  identifiedBy:     ops:orderNumber
  systemsOfRecord:  [erp.orders, storefront.orders]
  lifecycle:        ops:OrderLifecycle
  relations:
    placedBy   -> ops:Customer   [1]
    contains   -> ops:LineItem   [1..*]
    settledBy  -> ops:Payment    [0..1]

Then the verb. This is the part that has no equivalent in OWL, in your database schema, or in your OpenAPI spec, and it is the part that decides whether your agent is safe:

action: ops:Payment.refund
  label:    "Issue a refund against a captured payment"
  inputs:
    order:  ops:Order         required
    amount: xsd:decimal       required   unit: USD
    reason: ops:RefundReason  required
  preconditions:
    - order.state in (SHIPPED, DELIVERED)
    - now() - order.placedAt <= policy.windowDays
    - sum(order.payment.refunds.amount) + amount <= order.payment.captured
    - none(order.lineItems.category in policy.excludedCategories)
  authority:
    - actor: agent       when: amount <= 250 USD  -> allow
    - actor: agent       when: amount >  250 USD  -> escalate(supervisor)
    - actor: supervisor  when: always             -> allow
  effects:
    - assert ops:Refund(state=SETTLED, amount=amount, against=order.payment)
    - order.state -> PARTIALLY_REFUNDED or REFUNDED
  evidence:
    requires:      processorRefundId
    verifiedBy:    read-back from processor within 60s
  reversible:   false
  blastRadius:  money

Read those four preconditions again and notice where they live today. The first is in your ERP. The second is in a policy document. The third is arithmetic nobody wrote down. The fourth is in a merchandising spreadsheet. In a prompt-only architecture, all four are compressed into "be careful with refunds," and the agent's compliance is a matter of temperature. Modeled, they are executable, individually testable, and — when one fails — capable of telling the agent which one failed, which is the difference between a useful retry and a loop.

The tool definition the agent actually sees is then generated, not written:

{
  "name": "payment_refund",
  "description": "Issue a refund against a captured payment. Valid only for
    orders in SHIPPED or DELIVERED state, within 30 days of purchase, for a
    cumulative total not exceeding the captured amount, excluding gift cards.
    Amounts over 250 USD are escalated to a supervisor.",
  "input_schema": {
    "type": "object",
    "properties": {
      "order":  { "type": "string", "description": "ops:Order identifier" },
      "amount": { "type": "number", "description": "USD, at most the captured amount" },
      "reason": { "type": "string", "enum": ["DAMAGED", "LATE", "NOT_AS_DESCRIBED", "GOODWILL"] }
    },
    "required": ["order", "amount", "reason"]
  }
}

That description is a rendering of the preconditions, so it can never drift from them. When the refund window changes from 30 days to 45, one line changes in the ontology and every downstream artifact — tool description, guard, eval fixture, the sentence the agent reads — changes with it. Compare that to the current state of your repository, where the window is almost certainly written down in four places that disagree.

The lifecycle is part of the model, not an implementation detail

Most domains have concepts whose legal states are more interesting than their fields. A refund is not a row; it is a small machine with about nine states and a handful of transitions, several of which no agent should ever be allowed to make alone. Modeling that explicitly is what lets you say "autonomous" and "governed" in the same sentence.

Two things in that diagram are easy to miss and worth stealing. First, escalation is a modeled state, not an exception path: PendingHumanApproval is somewhere the machine legitimately lives, with the precondition results attached so the human is deciding rather than re-investigating. Second, Settled is not reachable from a successful API call. It is reachable from a satisfied evidence contract. If the processor returns 200 but the read-back does not produce a refund identifier, the machine sits in Executing and someone finds out. In a prompt-only agent, that same situation produces a cheerful "I've refunded that for you!" and a customer who calls back in nine days.

How the agent actually uses it at runtime

The most common objection I hear is that this sounds like a lot of ceremony to put in front of a model that could just call the API. It is worth walking the actual control flow, because the ontology is doing three specific jobs the language model is genuinely bad at.

Step 02, resolution. "The sunscreen order" becomes ops:Order and ops:Payment.refund with three required slots. The model is excellent at the fuzzy half of this — mapping human phrasing onto a candidate concept — and unreliable at the second half, which is knowing the complete, bounded set of things that could have been meant. The ontology supplies the candidate space; the model picks within it. That is the correct division of labor, and it is why "resolve against a closed vocabulary" beats "search two hundred tool descriptions" on both accuracy and tokens.

Step 06, preconditions. Four checks run as code against facts, and the failure is specific: slot "amount" is unbound. The agent asks one clarifying question instead of guessing, and the question it asks is derived from the model rather than invented. Vague failures produce flailing; typed failures produce one good question.

Step 10, authority. The policy guard is a separate component on purpose. If authorization is something the agent decides, then authorization is something a prompt injection can decide. Putting allow | escalate | deny behind an interface the agent calls but cannot implement is the difference between a policy and a suggestion.

A second example, where the entities are physical

Order operations is a friendly domain because everything is a record. The case for modeling gets stronger, not weaker, when the entities are physical and the constraints are spread across systems that were never designed to talk. I spend a lot of time in fleet and field operations, so here is that shape:

concept: fleet:Vessel
  lifecycle: AVAILABLE | RESERVED | OUT | MAINTENANCE | RETIRED
  relations:
    dockedAt      -> fleet:Slip              [0..1]
    certifiedFor  -> fleet:WaterClass        [1..*]
    heldBy        -> fleet:MaintenanceHold   [0..*]

action: fleet:Reservation.assignVessel
  preconditions:
    - vessel.state == AVAILABLE
    - no overlap(vessel.reservations, reservation.window)
    - vessel.capacity >= reservation.partySize
    - reservation.waterClass in vessel.certifiedFor
    - none(vessel.holds where blocking and window overlaps reservation.window)
    - vessel.nextInspectionDue > reservation.window.end
  authority:
    - actor: agent        when: value <= 1500 USD and not vessel.premium -> allow
    - actor: dockManager  when: always                                   -> allow
  evidence:
    requires: signedWaiver, walkaroundPhotos(>= 4), fuelReadingAtDeparture

Six preconditions, drawn from five systems: the fleet registry, the booking calendar, a maintenance system, a compliance certificate table, and an inspection schedule that lives in someone's spreadsheet. No single schema contains this action's legality. No prompt can reliably reconstruct it. And the failure mode is not an awkward chat response — it is a family standing on a dock next to a boat that is out of certification, which is exactly the class of outcome that makes an executive ban agents for a year.

The evidence contract is worth noting here too. "Done" for a vessel assignment is not a database write. It is a signed waiver, four walkaround photos, and a fuel reading. Modeling that means the agent's definition of complete matches the business's definition of complete, which is a surprisingly rare property in production AI systems.

One ontology, four compiled artifacts

The single most important architectural decision is what the ontology produces. If it is a document, it will rot within a quarter. If it is a compiler input, it cannot.

• Tool and MCP schemas. Names, input types, enums, and the description text, all derived from the action definitions. The agent literally cannot be offered an action the ontology does not define.
• Prompt vocabulary. The concept labels and aliases the model needs in order to speak your domain's language — generated, versioned, and much smaller than the schema dump most teams paste into a system prompt.
• Runtime guards. Preconditions and authority rules compiled into something executable — SHACL shapes over a graph, or plain predicate functions. This is the layer that runs whether or not the model cooperated.
• Eval fixtures. Every precondition is a test case, and its negation is a counterexample. An ontology hands you an adversarial eval suite for free: for each action, one case that should be allowed, one that should be escalated, and one that should be refused for each precondition. Most teams write six evals by hand and call it coverage.

Why now, more than ever

None of the ideas here are new. Gruber defined ontology for computer science in 1993, OWL became a W3C recommendation in 2004, and the semantic web spent a decade being right and unusable. What changed is not the theory. Six things changed at once on the consumption side, and together they moved this from "nice architecture" to "the thing your agent program is missing."

• Tool sprawl outran prose. A single agent now routinely holds one to three hundred tools across a dozen MCP servers, each with a description written by a different team on a different day. Descriptions do not compose. Two tools whose descriptions both say "look up the customer" give the model no principled way to choose, and no amount of prompt tuning fixes an ambiguity that is genuinely in the domain.
• Agent-to-agent handoffs need shared referents. When a scheduling agent hands work to a billing agent, they need to mean the same thing by "account." Similar wording is not the same as a shared identifier, and the failure is silent — nothing crashes, the numbers are just quietly wrong. Multi-agent systems make an ontology load-bearing in a way single-agent systems let you get away with skipping.
• Context is finite, and an ontology is compression. Six thousand columns across nine systems collapse into perhaps sixty concepts and forty actions. That is not a documentation exercise; it is the highest-leverage token reduction available, and unlike summarization it is lossless with respect to the things the agent is allowed to do.
• Audit pressure arrived. "Why did the agent do that?" is now a question with legal and contractual consequences, and emerging regimes around automated decision-making expect a documented answer. "The model judged it appropriate" is not one. "Action X was permitted because preconditions 1 through 4 held, under authority rule Y, evidenced by Z" is. You cannot produce that sentence retroactively if authority was never modeled.
• Evaluation needs an oracle. You cannot test an agent against a vibe. Preconditions and effects give you the ground truth that makes automated evaluation possible: an action either was legal or was not, and the model either respected that or did not. Teams that skip the ontology end up grading agents with another LLM, which is a way of converting an unmeasured problem into an unmeasurable one.
• The authoring cost collapsed. This is the one that actually changed the math. The historical objection to ontologies was labor: knowledge engineering was slow, expensive, and staffed by specialists. Today a capable model reads your schemas, your API specs, your runbooks, and your ticket history and drafts a candidate ontology in an afternoon. Your domain experts move from authoring to reviewing, which is a task they are far better at and far more willing to do. The thing that killed the semantic web was the cost of the first draft, and that cost is now close to zero.

There is one more reason, and it is the one I care most about running AI-first teams. An ontology is where a team's theory of its own system survives contact with agents. I wrote previously about cognitive debt — the way agentic development produces text without producing shared understanding. An ontology is the most durable form of understanding you can write down, because unlike a design document it is executed on every request. It is simultaneously a debt payment and a runtime artifact, which makes it the rare piece of documentation that cannot silently go stale.

How to build one without a two-year death march

The failure mode of this discipline is famous and deserved: a team disappears into modeling, emerges with an exquisite upper ontology, and ships nothing. Everything below is designed to prevent that. The target for a first useful ontology is two weeks, not two quarters.

Start from the verbs, not the nouns

List the ten to twenty actions your agent actually takes in production, ranked by frequency times blast radius. That list is your scope. Then model only the nouns those actions touch, and only the attributes those actions' preconditions read. Every classical modeling effort I have watched fail started with "let's model the customer domain." Every successful one started with "let's model the six things the agent does that can cost us money."

Write preconditions as executable expressions, never prose

If a precondition cannot be evaluated against facts, it is a comment. The test is simple: can you run it and get a boolean plus a reason? Prose like "only for eligible orders" fails that test; order.state in (SHIPPED, DELIVERED) passes it. This constraint also does useful violence to vague policies, because writing them down executably forces the business to decide what they actually mean — which is often the most valuable output of the whole exercise.

Give every action an authority rule and an evidence contract

Make both mandatory fields, so the model cannot be extended carelessly. Authority answers "who, up to what limit, and what happens at the boundary." Evidence answers "what artifact, from which system, read back within what window." A new action with an empty evidence contract should fail your build. This is the single highest-value rule in this post; it is also the one teams skip first because both answers are annoying to obtain.

Compile, do not document

Generate tool schemas, prompt vocabulary, guards, and eval fixtures from the model, and make hand-editing any of them a review failure. The ontology earns its place by being on the critical path. A model that is merely consulted is a wiki page with better formatting, and it will be wrong within a month.

Version it, review it, and test it like code

It lives in git next to the service it governs. Changes go through pull requests with domain experts as reviewers. Every change runs the generated eval suite. Model an ontology change the way you would a database migration — because in every sense that matters, it is one.

Let the model draft, and make humans review

Point an agent at your OpenAPI specs, your DDL, your runbooks and your last thousand support tickets, and ask for a candidate ontology: concepts with aliases, actions with proposed preconditions, and — importantly — a list of every place the sources contradict each other. That contradiction list is gold. It is the set of decisions your organization has been deferring, and it is far easier for an expert to adjudicate twenty specific disagreements than to author a model from a blank page.

Anti-patterns

• The noun museum. Four hundred beautifully specified classes, zero actions. It looks like an ontology and functions like a glossary. If your model has no verbs, an agent cannot use it for anything but naming.
• The advisory model. The ontology exists, is lovely, and is not enforced at runtime — the agent still calls the raw API. Anything the agent can bypass, it eventually will, usually at 2 a.m. Guards must sit between the agent and the system of record, not beside them.
• Authority in the system prompt. "You may refund up to $250" in a prompt is a suggestion to a system that can be talked out of things. Authority belongs in a component the agent calls and cannot reimplement.
• Modeling the whole enterprise first. The upper-ontology instinct is the reason this discipline has a bad reputation. Model one workflow end to end, ship it, then take the next one. Breadth is earned.
• Confusing a knowledge graph with an ontology. The graph holds instances; the ontology holds meaning, rules, and affordances. A large graph with a thin ontology gives an agent a great deal to look at and no basis for deciding anything.
• Success without proof. Treating a 200 response as completion. Without a read-back, your agent's confidence and your system's reality diverge silently, and you find out from the customer.

How to tell whether it is working

None of these are exotic, and all of them are cheap to instrument once actions are modeled:

• Action coverage. What fraction of agent write operations go through a modeled action rather than a raw tool call? This should climb toward 100% for anything touching money, identity, or physical assets. Anything below that is your actual risk surface, itemized.
• Precondition block rate. How often does a guard stop an action the model wanted to take? A healthy system shows a small, non-zero rate. Zero means your guards are not evaluating anything. A rising rate usually means the model is being asked to do something the domain does not support, which is a product signal, not a bug.
• Escalation precision. Of the actions escalated to humans, what fraction were approved unchanged? Very high approval means your thresholds are too conservative and you are burning human attention. Very low means the agent is proposing things it should not.
• Unresolved concept rate. How often does resolution fail to map an utterance onto a known concept? This is your ontology's gap list, generated by real usage, and it is the correct backlog for what to model next.
• Evidence completion rate. What fraction of completed actions satisfied their evidence contract on the first read-back? This is the honest measure of whether "done" means done.
• Drift incidents. How many times did someone hand-edit a generated artifact? Should be zero, and should break the build when it is not.

The bottom line

Agents did not create the problem of ambiguous enterprise semantics. They just removed our ability to route around it. For thirty years the compensating control for a fuzzy domain model was a human who knew better — someone who understood that this system's "customer" is that system's "account," that the refund window has an exception for subscriptions, and that you do not send a boat out with an expired certificate no matter what the calendar says. That knowledge was never written down because it never had to be. Now we are handing the keyboard to something that cannot absorb it by osmosis, and every piece of it we failed to make explicit shows up as a plausible, confident, wrong action.

An agentic ontology is the smallest artifact that fixes that: seven parts, scoped to the verbs that matter, compiled into the things your runtime already needs. Start with the ten actions that can cost you money, write their preconditions as code, give each one an authority rule and a proof obligation, and generate your tool schemas from the result. The first version will take two weeks and will be incomplete, and it will still catch the ninety-four-day-old gift card refund. Adding more tools has never once fixed a semantics problem. It is worth building the layer that does.

Further reading

• Thomas R. Gruber, A Translation Approach to Portable Ontology Specifications (Knowledge Acquisition, 1993) — the source of the canonical definition
• OWL 2 Web Ontology Language Overview (W3C) — the formal machinery for the classical layer
• Shapes Constraint Language (SHACL) (W3C, 2017) — a practical way to compile preconditions into runtime guards
• PROV-O: The PROV Ontology (W3C, 2013) — a ready-made vocabulary for the evidence and provenance layer
• Richard Fikes and Nils Nilsson, STRIPS: A New Approach to the Application of Theorem Proving to Problem Solving (1971) — where preconditions and effects come from
• Model Context Protocol — the transport your compiled action definitions will most likely target
• schema.org — proof that a small, pragmatic, widely adopted ontology beats a complete one
• Peter Naur, Programming as Theory Building (1985) — why the model in your head is the real system, and what happens when agents stop building it for you