What an ontology is for

Ontology used to be a branch of philosophy and a niche in database design. This year it is in every enterprise AI request for proposal, usually with no definition attached, and the vendors answering each mean something different by it. That is worth fixing, because the thing the word points at is real, most companies already have most of it scattered across their systems, and agents cannot be trusted with real work without it.

This piece defines the term plainly, separates it from the things it is confused with, explains why agents turned it from a data-modeling nicety into an operating requirement, and lays out how building one becomes the foundation of an enterprise AI implementation rather than a two-year prerequisite for it.

A plain definition

An ontology is an explicit model of the things a business cares about, shared by the people and the software that work on them. It has four parts.

Object types. The nouns. Customer, order, shipment, invoice, claim, employee, incident, contract. Each is a definition, not a table: a name, a set of typed properties, a key that identifies one instance, and one or more source systems that supply the instances.

Properties. What is true of each object. An order has an amount, a status, a currency, a date. A property that appears on many object types, an owner or a region, is defined once and shared, so "region" means the same thing on a customer and on a shipment.

Link types. How objects relate. A customer places orders. An order ships as one or more shipments. A shipment may have a claim. A link type is the definition; a link is one instance of it, between two specific objects.

Action types. The verbs. What may be done to objects, with the inputs it needs, the objects it changes, the side effects it causes, and the conditions under which it is allowed. File a claim. Approve an invoice. Change a customer's tier. This is the part most enterprise data models leave out entirely, and it is the part that matters for agents.

Put together: an ontology says what exists, what is true of it, how it is connected, and what may be done to it. The last clause is the one to remember.

What it is not

Four things get called an ontology that are not one, and each is useful for something else.

It is called	What it actually is	What it lacks
A schema	One system's private idea of its own tables	Shared meaning across systems; the same customer is three different rows
A data warehouse	Facts, copied and joined for analysis	Meaning and actions; it can count orders, not file a claim
A knowledge graph	Instances and their relationships	The definitions and the verbs; it knows this order links to this shipment, not what an order is or what may be done to it
A semantic layer	Agreed definitions of metrics for reporting	Objects and actions; it defines revenue, not the customer or the refund

The distinction that matters most is between a knowledge graph and an ontology. The graph is the data: these entities, these links, right now. The ontology is the structure the data conforms to and the actions that are legal on it. You need both, and a graph without an ontology is a pile of connections nobody can reason about safely.

Why agents made it urgent

For a decade this was a modeling debate that only data architects cared about, because the consumers of enterprise data were people and dashboards, and people resolve ambiguity without noticing. A human reading "the Acme account" knows whether that means the CRM record, the billing entity, or the support tenant. Software that takes action does not.

The numbers this year show what happens without it. Gartner's first-quarter survey found that 80 percent of enterprises now have at least one production application with an agent embedded in it. A survey reported by VentureBeat this month found that 68 percent of enterprises had traced a confident but wrong agent answer to missing or inconsistent business context in the previous six months. And Gartner has predicted that 60 percent of agentic analytics projects that rely on a tool protocol alone, with no consistent semantic model beneath it, will fail. Connecting an agent to systems is now easy. Giving it a shared, governed model of what those systems contain is the part most programs skipped.

Three things change the moment an agent is allowed to act.

Nouns need referents. When an agent is asked to "credit the customer," it has to bind that noun to exactly one object with one key in one system of record, and it has to know that the same customer in the ticketing system and the billing system are the same customer. Without an ontology that resolves identity across systems, the agent guesses, and a guess with write access is an incident.

Verbs need contracts. "Issue a refund" has inputs, preconditions, a system it lands in, side effects, and a threshold above which a person must approve. An agent that has the verb only as a sentence in a prompt has none of that. An action type is the contract, and it is where the approval attaches.

Permissions need a place to live. Access rules in the source systems are attached to objects: this record, this account, this ledger. An ontology that inherits those rules per object, and carries them into every link and action, is how an agent sees exactly what the person operating it could see and no more. An ontology that does not is how an agent sees everything.

This is the structural half of what we described last week as the decision model. The ontology is the objects, links, and actions. The decision model is the owners, thresholds, precedents, and boundaries that live on them. One without the other is either a map with no rules or rules with nothing to apply them to.

What becomes possible on top of it

The reason to build an ontology is not the ontology. It is what can be built on it, and this is where the concept earns its place in an AI transformation rather than a data project.

Once the objects, links, and actions of a workflow are modeled once, every application and agent that touches that workflow shares them. A claims agent, a dashboard for the operations director, a mobile approval flow for the field, and a monthly report to finance are four surfaces on one model, not four integrations with four private ideas of what a claim is. Adding the fifth is a matter of days. Change the threshold for approval in one place and all five respect it.

That is the difference between bespoke software that compounds and bespoke software that accumulates. Custom applications built directly on raw systems each re-solve identity, permissions, and the meaning of every field, and each becomes a maintenance burden the day it ships. Custom applications built on an ontology inherit all of that, and each one makes the next one cheaper. An enterprise that has modeled its ten most consequential workflows can put an agent or an app on any of them in the time it used to take to write the requirements document.

How to build one without the two-year project

The reason ontology has a bad reputation in enterprises is the way it has been sold: a modeling exercise, run by consultants, that has to be complete before anything useful runs. Companies that start there spend a quarter in workshops arguing about what a customer is and ship nothing. There is a faster path, and it starts from the observation that you already have most of the ontology, distributed across the systems you run.

Start from the systems, not the whiteboard. Every system of record has a schema, and each schema is a partial ontology: the CRM knows what an account is, the ERP knows what an invoice is, the ticketing system knows what an incident is. Bring those definitions in with their permissions attached. The first draft of the ontology is the union of what the systems already say, and it takes days, not months.

Resolve identity where systems disagree. The one place declaration is unavoidable is where the same real-world thing has different keys in different systems. A customer in the CRM, the billing system, and the support desk has to become one object with three source references. This is a bounded piece of work per object type, and it is the highest-value hour in the whole exercise, because every downstream action depends on it.

Let links come from activity. Which project a document belongs to, which account a thread was about, who owns which system, is mostly visible in the activity around the objects: who edited what, what was linked from where, what happened after what. Watching activity fills in links that nobody would have thought to model.

Declare actions one workflow at a time. Do not try to enumerate every verb in the business. Take one workflow an agent will run, name the three or four actions it needs with their inputs, preconditions, side effects, and approval thresholds, and attach them to the objects they change. The next workflow adds its actions. After ten workflows you have an action layer that reflects what the company actually does, and none of it was speculative.

Version it, and ship on it. An ontology changes when the business changes: object types gain properties, actions gain preconditions after an incident, links get renamed. Treat the definitions as code, versioned and reviewed, and put the first agent on the first workflow's slice before the second workflow is modeled. The model earns its keep by having something running on it, not by being complete.

Where this sits in an AI transformation

This is how Fig runs it. An enterprise implementation with our transformation team moves through audit, architecture, deployment, monitoring, and optimization, and the ontology is the spine of the architecture step. The forward-deployed pod works inside the company's systems, starts from the workflows the audit found worth building, and models the objects, links, and actions those workflows need, from the systems of record and with the teams who own the work in the room. Then it builds on that model: the agents, the integrations, the internal tools, and the customer-facing surfaces the workflow calls for, taken live in production and measured against the baseline.

Two things about that sequence matter. The ontology is built one workflow at a time, so the first agent runs in weeks and the model grows with each engagement rather than gating it. And the model stays with the company. When the pod steps back, the definitions, the identity resolution, the action contracts, and every application built on them are the company's, versioned in its own library and readable by its own engineers. The next workflow can be built by the pod or by the company's team, on the same foundation.

Four ways it goes wrong

The ontology as a project. Complete before useful. The fix is the sequence above: systems first, identity second, actions per workflow.

The ontology without verbs. A beautiful graph of everything, and an agent that can describe the company and change nothing. If there are no action types, it is a knowledge graph, and it will not carry an agent past answering questions.

The ontology without state. Objects and actions but no record of where each piece of work currently is. The agent re-proposes what is already done and misses what is stuck. State is a property like any other, and it has to be live.

The ontology owned by the vendor. The one that matters most. If the definitions, the identity resolution, and the action contracts exist only inside a platform and cannot leave it in a usable form, the company has not built an ontology. It has built a dependency. The test is the one our research team applies to every context asset in the sovereign AI playbook: move one workflow's slice of the ontology to a second environment, restore its objects, links, actions, and permissions, and run the same cases. If it makes the trip, it is yours.

Key takeaways

• The actions are the ontology. Objects, properties, and links describe a business; action types with preconditions, side effects, and approvals are what let software work in it.
• The failures showing up in agent programs this year are context failures, and an ontology is the fix that scales past one workflow.
• Systems first, identity second, actions per workflow. A complete model is a symptom of a stalled program.
• What you build on top compounds only if the model underneath is shared, versioned, and yours to move.

The word is new to most RFPs. The thing it names is how a company has always described itself to itself. The only change is that software can now act on it.