Ontology in AI and Agentic Systems

The word ontology sounds like something that belongs in a philosophy lecture.

And originally, it does.

In philosophy, ontology is concerned with questions like:

• What exists?
• What kinds of things exist?
• How are those things related?
• What does it mean for something to belong to a certain category?

Now in technology, we are borrowing the same idea and making it much more practical.

An ontology is essentially a structured description of a world.

It tells a computer what kinds of things exist inside a particular domain, what those things mean, and how they can relate to one another.

Instead of simply storing data, we are giving the system a model of what that data represents.

A Database Can Store Things Without Understanding Them

Imagine we are building software for a university.

We might have database tables like:

students

id name department_id

courses

id name lecturer_id

This is useful.

The database knows where student names are stored, where courses are stored, and how certain records reference one another.

But this is primarily a storage structure.

It doesn't necessarily express the larger meaning behind those records.

For example:

Student → is a Person

Lecturer → is a Person

Student → ENROLLS_IN → Course

Lecturer → TEACHES → Course

Course → BELONGS_TO → Department

Department → PART_OF → University

Now we are describing something different.

We're describing the world of a university.

A student is not simply a row inside a "students" table. A student is a type of person.

A lecturer is also a person.

A course belongs to a department.

A lecturer teaches a course.

A student enrolls in a course.

That structure starts looking less like storage and more like knowledge.

This is where ontology comes in.

Ontology Defines the World

A simple way to think about ontology is:

«An ontology defines what things exist in a domain, what they mean, and what relationships are possible between them.»

Suppose we are building a system for a software company.

Our ontology might define entities such as:

Person Team Project Service Database Repository Customer Issue

Then it could define relationships:

Person → MEMBER_OF → Team

Person → WORKS_ON → Project

Team → OWNS → Project

Project → USES → Service

Service → USES → Database

Project → STORED_IN → Repository

Customer → REPORTS → Issue

Issue → AFFECTS → Project

Notice that we still haven't added any actual company information.

We have only defined what kinds of things are allowed to exist and how they may relate.

Then real data can populate that structure.

Alice → MEMBER_OF → Platform Team

Alice → WORKS_ON → Analytics API

Platform Team → OWNS → Analytics API

Analytics API → USES → PostgreSQL

Customer A → REPORTS → Login Failure

Login Failure → AFFECTS → Analytics API

The ontology defines the structure.

The actual entities and relationships become knowledge.

Ontology vs Schema

This is where things can become confusing because an ontology can look similar to a database schema.

But they answer different questions.

A schema mostly asks:

«How should this data be stored?»

For example:

CREATE TABLE projects ( id UUID, name TEXT, owner_id UUID );

An ontology asks something closer to:

«What is a project?»

and:

«What kinds of things can be related to a project?»

For example:

Project → OWNED_BY → Team Project → USES → Service Project → HAS_REPOSITORY → Repository Project → HAS_ISSUE → Issue

A database schema is primarily concerned with data structure.

An ontology is concerned with meaning and relationships.

The two can absolutely exist together.

In fact, many useful systems use both.

Ontology vs Taxonomy

Another closely related term is taxonomy.

A taxonomy is mostly about classification.

Think of something like:

Food ├── Fruit │ ├── Citrus │ └── Berry └── Vegetable ├── Leafy └── Root

This tells us how concepts belong inside categories.

An ontology can include this kind of hierarchy, but it can go much further.

For example:

Orange → IS_A → Citrus Fruit

Orange → CONTAINS → Vitamin C

Orange → GROWN_IN → Orchard

Farmer → GROWS → Orange

Orchard → LOCATED_IN → Region

Taxonomy tells us:

«An orange is a citrus fruit.»

Ontology can also tell us:

«Who grows oranges, where they are grown, what they contain, and what other entities they interact with.»

Ontology and Knowledge Graphs

This also brings us to knowledge graphs.

The two are closely connected, but they are not exactly the same thing.

An ontology might define:

Person Company Project

Person → WORKS_FOR → Company

Person → WORKS_ON → Project

Company → OWNS → Project

Those are the rules of the world.

A knowledge graph might then contain:

Sarah → WORKS_FOR → Acme

Sarah → WORKS_ON → Phoenix

Acme → OWNS → Phoenix

The ontology defines what relationships are possible and what they mean.

The knowledge graph stores the actual entities and relationships we currently know about.

A useful way to remember the difference is:

«The ontology defines the map. The knowledge graph contains the places on the map.»

Why Relationships Matter

Suppose a company has thousands of documents containing information about teams, projects, databases, customers, meetings, and incidents.

Now imagine asking:

«Which projects might be affected if our authentication service goes offline?»

There might not be a document containing the exact sentence:

These five projects will break if Auth Service goes down.

Instead, the information may exist across multiple places.

One document might say:

Project Alpha uses User API.

Another:

User API depends on Auth Service.

Another:

Project Beta uses User API.

Once those relationships are represented structurally, the system can traverse them:

Auth Service ↑ DEPENDS_ON User API ↑ USED_BY Project Alpha

and:

Auth Service ↑ DEPENDS_ON User API ↑ USED_BY Project Beta

The system can now infer that both projects may be affected.

This ability to move through relationships is one of the most useful properties of ontology-driven systems.

This Becomes Particularly Interesting With AI

A lot of modern AI systems work with unstructured information.

Documents.

Slack messages.

Emails.

Meeting transcripts.

Code.

Support conversations.

Product documentation.

The typical approach is to split this information into chunks and generate embeddings.

A simplified Retrieval-Augmented Generation system might look like:

Documents ↓ Chunking ↓ Embeddings ↓ Vector Database ↓ Similarity Search ↓ LLM

Embeddings are extremely useful because they allow us to search by semantic similarity rather than exact words.

If a document says:

The customer cannot access their account.

and you search:

login problem

the embedding representations can still place those two concepts relatively close to each other.

The words are different.

The meaning is similar.

That is incredibly useful.

But similarity is not the same thing as structure.

Embeddings Know Similarity

Imagine an embedding as coordinates in a very high-dimensional space.

Concepts with similar meanings tend to be located near one another.

Something like:

"dog" "puppy" "canine"

may occupy nearby regions.

Similarly:

"database outage" "PostgreSQL failure" "database unavailable"

could have similar vector representations.

This makes embeddings excellent for questions like:

«Which documents are most relevant to what I am asking?»

But embeddings don't inherently represent relationships like:

Project A → USES → Database B

Database B → RUNS_ON → Server C

Server C → OWNED_BY → Infrastructure Team

There may be semantic clues inside the text, but the relationship itself is not explicitly represented simply because the text has an embedding.

Ontology Knows Structure

Ontology solves a different problem.

It tells the system:

Project A ↓ USES Database B ↓ RUNS_ON Server C ↓ OWNED_BY Infrastructure Team

Now the system can reason across those relationships.

Suppose you ask:

«Which team should investigate Project A's database outage?»

An embedding search may retrieve documents mentioning:

Project A Database B Infrastructure Team

That can work.

But the ontology gives us an explicit path:

Project A → USES Database B → RUNS_ON Server C → OWNED_BY Infrastructure Team

The distinction is subtle but important.

Embeddings answer:

«What information looks semantically related to this?»

Ontology answers:

«How are these things actually connected?»

Embeddings and Ontology Should Not Be Competitors

It is easy to frame this as:

Ontology vs Embeddings

But the more interesting architecture is:

Ontology + Embeddings

Because they solve different problems.

Embeddings are excellent for finding relevant information inside large amounts of messy, unstructured data.

Ontology is excellent for representing entities, meaning, relationships, and constraints.

A system could therefore work like this:

Documents | ┌─────────┴─────────┐ ↓ ↓ Embeddings Entity Extraction ↓ ↓ Vector Database Knowledge Graph ↓ Ontology └─────────┬─────────┘ ↓ Agent

The vector database can answer:

«Which pieces of text are relevant?»

The ontology and knowledge graph can answer:

«Which entities are involved and how are they connected?»

The LLM can then use both.

Consider a Company AI Assistant

Imagine asking:

«Why did the checkout service fail yesterday, and which customers were affected?»

The system might first use embeddings to retrieve:

• incident reports,
• Slack discussions,
• deployment notes,
• customer support tickets.

Then the ontology might already understand:

Checkout Service → DEPENDS_ON → Payments API

Payments API → USES → Payment Database

Incident 194 → AFFECTED → Payments API

Customer X → USES → Checkout Service

Customer Y → USES → Checkout Service

The AI now has two forms of context.

It has textual context from vector retrieval.

And it has structural context from the knowledge graph.

This is significantly richer than relying on either one alone.

It Also Helps AI Memory

This becomes even more interesting when building long-term memory for AI agents.

Suppose an agent continuously receives information like:

Alice mentioned that Project Phoenix will launch next month.

The Platform team owns Phoenix.

Phoenix depends on Auth API.

John leads the Platform team.

A traditional memory system might simply embed these statements and store them.

Later, similarity search could retrieve them.

But an ontology-aware memory system could convert them into:

Alice → MENTIONED → Project Phoenix

Project Phoenix → OWNED_BY → Platform Team

Project Phoenix → DEPENDS_ON → Auth API

John → LEADS → Platform Team

Now imagine asking:

«Who should I talk to about an authentication problem affecting Phoenix?»

The answer might require multiple hops:

Phoenix → DEPENDS_ON Auth API

Phoenix → OWNED_BY Platform Team → LED_BY John

The AI is no longer just remembering sentences.

It is building a model of the world it operates in.

And that is where ontology becomes especially powerful.

The Bigger Picture

For years, a lot of software has been built around storing information.

Tables.

Documents.

Files.

APIs.

Search indexes.

Then embeddings gave us a better way to retrieve information based on meaning.

But intelligent systems increasingly need something more.

They need to understand that:

people belong to teams,

teams own projects,

projects depend on services,

services use databases,

customers use products,

incidents affect services,

and decisions made in one place can affect something several relationships away.

That is fundamentally a relationship problem.

And relationships are exactly what ontologies are designed to describe.

So if embeddings help machines answer:

«"What information is similar to this?"»

Ontology helps them answer:

«"What exactly is this thing, and how does it fit into everything else I know?"»

Modern AI systems will increasingly need both.

Because useful intelligence isn't only about retrieving the right information.

It's also about understanding what that information represents and how the pieces fit together.