> Site index: [llms.txt](https://ortelian.com/llms.txt) with all pages and descriptions.

# How to build an ontology for AI agents

Source: https://ortelian.com/notes/how-to-build-an-ontology-for-ai-agents/
Markdown: https://ortelian.com/notes/how-to-build-an-ontology-for-ai-agents.md
Author: Laurens Nys
Published: 2026-10-11

How to build an ontology for AI agents in seven steps: start from one piece of work, name the kinds of things, their sources, relationships and allowed actions.

To build an ontology for AI agents, start from one piece of work and the questions it has to answer, not from a model of the whole company. Name the kinds of things that work touches, their attributes and sources, the relationships between them and the actions an agent may take on each, then test it on real questions and let it grow as more work moves onto it.

This is the practical companion to [what is an ontology for AI agents?](https://ortelian.com/notes/what-is-an-ontology/). The steps follow the classic method in Noy and McGuinness’s [Ontology Development 101](https://protege.stanford.edu/publications/ontology_development/ontology101-noy-mcguinness.html), adapted for a company where agents act on the result. The example throughout is the sales territory we built for a deep-tech company that sells into hospitals through integrators.

## 1. Pick one piece of work and write down its questions

Scope comes first. Choose a piece of work that matters, such as building the account list or preparing a planning round, and write down the questions an agent doing it must be able to answer. Ontology engineers call these competency questions, a term Noy and McGuinness take from Grüninger and Fox. They become the test the ontology has to pass.

For the territory, the questions were close to these: which hospitals does this integrator already supply, which facilities does a regulation that changed last month apply to, and who at this company did we last speak to and what was promised.

## 2. List the kinds of things, and keep them few

From the questions, pick out the nouns that exist on their own: companies, people, facilities, regulations, events. Those become the kinds of thing, also called classes or object types. The territory started with five: Company, Person, Facility, Regulation, Event.

Use one name per concept. Noy and McGuinness’s rule is that synonyms for the same concept are not different classes, so an account in the CRM and a company in a government registry are one kind of thing with two sources, not two kinds. Reuse what already exists where it fits: [schema.org](https://schema.org/docs/schemas.html) defines Organization, Person and Place, and your CRM already has accounts and contacts.

## 3. Give each kind its attributes and a source for each

For each kind, list the attributes the questions need and nothing more: a Company has a domain and a size, a Facility has an address, a Regulation has a date it took effect. Then write down where each attribute comes from and which source wins when two disagree.

That last part is what agents need and most schemas leave out. An agent that knows the size in the CRM was typed in years ago and the registry was updated last month can use the right one, and say which it used. This is the difference between a knowledge graph and a [world model for knowledge work](https://ortelian.com/notes/is-a-world-model-for-knowledge-work-a-knowledge-graph/): time and a source on every fact.

## 4. Name the relationships and give each a direction

Relationships carry most of the meaning. Name each one and give it 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.

In the example, whether a hospital was worth calling depended on which integrator already supplied it. The CRM had no field for that, and the supply relationships lived in one rep’s memory. Once “supplies” existed as a named relationship, a partner list of about 2,700 rows collapsed to 64 ranked accounts. [One week at one company](https://ortelian.com/notes/one-week-at-one-company/) tells that story.

## 5. Say what can be done with each kind

This step makes it an ontology for agents rather than a data model. For each kind, list the actions allowed on it: a Person can be added to the CRM, a Company can be ranked, an Event can start a task. Palantir’s [Foundry Ontology](https://www.palantir.com/docs/foundry/ontology/overview/) treats actions this way, as part of the ontology next to objects, properties and links.

Then mark which actions need a person’s approval. Anything that leaves the company, such as an email to a customer, should wait for one. Those marks become the agent’s permissions, which is where [AI agent governance](https://ortelian.com/ai-agent-governance/) starts.

## 6. Fill it from real sources and test it on the questions

Populate the ontology with the particular companies, people and facilities from your systems and outside sources. For the territory that meant government sources, hospital lists and integrator registries, normalised and linked to the CRM. Then ask the questions from step 1.

If a question cannot be answered, a kind, an attribute or a relationship is missing, or the data is. Noy and McGuinness put it plainly: you can only judge an ontology by using it in the applications it was built for.

## 7. Keep it small, owned and changed with care

Model only what the work needs. Noy and McGuinness warn against adding every property and relationship you can imagine, because irrelevant detail gets in the way. Give the ontology an owner, review changes before they go live and keep a record of what changed and when, because every agent that works from it changes behaviour when it changes.

## Common mistakes

| Mistake | Do this instead |
| --- | --- |
| Modelling the whole company before any work runs on it | Start from one piece of work and its questions |
| One kind per source system: CRM account, ERP customer, registry company | One kind with several sources and a rule for which wins |
| Relationships kept as free text in notes | Named relationships with a direction |
| Kinds and attributes only, no actions | Say what an agent may do with each kind, and what needs approval |
| Built once and left alone | An owner, reviewed changes and a record of each version |

## Questions people ask

### Do we need special software to build an ontology?

Not to start. A table of kinds, attributes, sources, relationships and actions is enough to agree on with the team. Standards such as the W3C’s [OWL](https://www.w3.org/OWL/) and editors such as Stanford’s [Protégé](https://protege.stanford.edu/) help when the ontology has to be shared or reasoned over formally.

### Can a language model build the ontology for us?

It can draft one. Language models are good at proposing kinds and relationships from documents and at matching a company across sources. Someone who knows the work still has to accept each kind and each relationship, because the ontology decides what the agents believe exists.

### How is this different from building a context graph?

The ontology defines the kinds of things and how they may relate. A [context graph](https://ortelian.com/notes/what-is-a-context-graph/) is the slice of the populated model one task needs, with the decisions already made about it. You need the first to build the second.

### Who should own the ontology?

The people who do the work, with someone who can model it. They know which distinctions matter. At Ortelian we build it with the team during a deployment, and it stays theirs: customers own their world model and can export it.