What is an ontology for AI agents?
An ontology defines what exists in a business, what it means, how things relate and what can be done, so AI agents can act on it. With a sales example.
An ontology, in enterprise AI, is a written definition of what exists in a business, what each kind of thing means, how the kinds relate and what can be done with them, so that AI agents can act on the same picture people carry in their heads.
Every company already has that picture. A rep knows a hospital is not the same kind of thing as the integrator that sells into it, and that a regulation applies to some facilities and not others. It lives in people’s heads, which worked while people did all the work. An agent cannot read anyone’s head, so the picture has to be written down.
An ontology names the kinds of things, not the things themselves
Take the sales territory we built for a deep-tech company that sells into hospitals through integrators. The ontology for that territory has five kinds of thing: Company, Person, Facility, Regulation, Event. Each kind has attributes. A Company has a domain and a size. A Facility has an address. A Regulation has a date it took effect.
Between the kinds run relationships, each named and each with a direction. A Person works at a Company. A Company supplies a Facility. A Facility is regulated by a Regulation. An Event happened to a Company. And for each kind, the ontology says what can be done with it: a Person can be added to the CRM, a Company can be ranked, an Event can start a task.
None of that names a single hospital. The particular hospitals live in the graph. The ontology is the schema; the populated graph holds the particular companies and people. Tom Gruber’s 1993 definition, “an explicit specification of a conceptualization”, is the academic version of the same split. Together the schema and the graph are what we call a world model for knowledge work.
How it differs from a knowledge graph, a world model and a context graph
The four terms describe layers of the same stack. The ontology is the one that holds no particular companies or people at all.
| Term | What it holds | The question it answers |
|---|---|---|
| Ontology | The kinds of things in a business, what each means, how they may relate and what can be done with them | What can exist here, and what can we do with it? |
| Knowledge graph | The particular companies, people, places and events, connected according to the ontology | What exists, and how is it connected? |
| World model for knowledge work | The graph, plus the data that keeps it current, the knowledge attached to each thing, time and a source on every fact | What is true about our business and its world right now, and how do we know? |
| Context graph | The slice one task needs: the things involved, their current state and the decisions already made about them | What does this piece of work need, and what was decided before? |
A knowledge graph is the ontology filled in with instances. A world model for knowledge work adds the data that keeps that graph current, time and sources on every fact, and knowledge attached to each thing. A context graph is the slice of all that one task needs. The ontology is the legend for every one of them, and if it is wrong, all of them are wrong in the same way.
An example from sales: your tools hold the pieces
If the company already has a CRM, why does it need this? The CRM has accounts and opportunities. Slack has the decision from Tuesday’s thread. The call recording has the promise the rep made. Each tool holds its own kind of thing well and knows nothing about the others. The company runs because people stitch those pieces together in their heads. A good rep knows an account is stalled because the champion left, and that the champion now works two rows down the list. The CRM does not know that. It has two contacts with two account IDs. The ontology is that stitching made explicit, so software can use it.
Take the territory above. Whether a hospital was worth calling depended on which integrator already supplied it. That is a relationship between two companies, one of which is not a customer and may never be. The CRM had no field for it. The partner list was a spreadsheet of about 2,700 rows and the supply relationships lived in the rep’s memory. We built the territory as a graph from government sources, hospital lists and integrator registries, normalised it and linked it to their CRM, with “supplies” as a named relationship. The list collapsed to 64 ranked accounts. The ranking came out of the relationship, and the relationship needed somewhere to exist first.
Why it matters for AI agents
An agent acts on whatever picture of the company it is given. With an ontology, that picture says what each thing is and what the agent may do with it. Without one, the agent has every piece of the company and no idea how they fit.
It is not the whole agent system. Agents still need evaluations, permissions and tools. When our meeting-prep agent runs at 9am, the ontology tells it that today’s meeting is with a Person who works at a Company that has a deal history and similar companies nearby in the graph. The CRM tool pulls the previous calls and emails. The permissions say which systems it may write to. The evaluations decide whether the brief met the standard the team agreed. Take the ontology away and each of those has to rediscover the company from scattered context on every run.
Palantir built this for governments. Smaller companies now need it too
Palantir made the idea operational. Foundry’s Ontology puts objects, properties, links, actions and security into one model, and people and AI act on the same business objects through it. It was built for governments and the largest enterprises, with budgets and engineering teams to match.
The problem does not scale with headcount. A company with one sales team acts on facts from sources that do not know about each other, the same problem a government agency has. What changed is the cost of building the model: language models can read a registry, match a company across sources and propose the link, and one person can check the result.
Questions people ask
Is an ontology the same as a database schema?
Close, but wider. A database schema describes tables and columns for one system. An ontology describes the things in the business across all systems, gives relationships a meaning and a direction, and says which actions are allowed on each kind of thing.
Is an ontology the same as a knowledge graph?
No. The ontology says a Person can work at a Company. The knowledge graph holds the particular people and companies and who works where. One is the legend, the other is the map drawn with it.
Isn’t this what a wiki is for?
A wiki attaches knowledge to the page where someone wrote it. An ontology attaches knowledge to the thing: a note about a regulation goes on the Regulation, and every Facility it covers sees it without anyone linking pages. A dashboard does not do it either. It shows people what is happening, but it does not tell an agent what a row means or what it may do about it.
How big does an ontology need to be?
Small to start. The territory above began with five kinds of thing. You model what one piece of work needs, and the ontology grows as more work moves onto it. At Ortelian we build it with the team during a deployment, as part of the engagement. For the steps, see how to build an ontology for AI agents.
