Two lineages: agents and ontologies

The talk brings together two ideas that developed along different historical paths:

1. Agents: systems that perceive their situation, decide what to do, and act.
2. Ontologies: formal models that describe the important concepts in a domain and how those concepts relate.

The historical background matters because it explains why these ideas fit together. An agent provides behavior: it can respond to information and choose actions. An ontology provides a structured account of the world in which those actions occur.

Lineage 1: the agent as a perceive–decide–act loop

The speaker traces the agent idea back to early artificial-intelligence work. In its useful engineering form, an agent follows a compact loop:

perceive the situation → decide what to do → act
                 ↑                         │
                 └──── observe the result ┘

• Perceive means receiving information about the environment or the current task.
• Decide means selecting an interpretation, next step, or action.
• Act means changing or querying something outside the agent.

This definition is about behavior, not about producing text. A system that only generates an answer has not necessarily acted. An agent can use a generated answer to choose a tool call or another step, and then use the result to continue the loop.

Example. Imagine a support agent. It receives a customer's request, decides whether it needs account information, and calls a suitable service. The returned information becomes part of what the agent perceives next. The loop can then continue.

This is the first half of the talk's later architecture: a model can help interpret a problem and plan a next action, while a surrounding program carries out the action.

Lineage 2: from categories of being to formal domain models

The speaker traces ontology to Aristotle's philosophy of being and categories. In that philosophical setting, categories are ways of organizing what exists or what can be said about things. Modern software uses a related motivation: make the important kinds of things and their connections explicit so that people and systems can use them consistently.

The talk then moves from this philosophical lineage to a modern definition attributed to Tom Gruber in 1993:

An ontology is a formal specification of a shared conceptualization.

Each part of this definition carries useful meaning:

• A conceptualization is a model of a domain: the concepts, relationships, and assumptions used to describe it.
• Shared means that the model is intended for common use by multiple people or systems. It is not merely one person's private list of words.
• Formal means that the concepts and relationships are represented precisely enough for a computer system to interpret, compare, or reason over them.
• A specification is an explicit description of that model.

In this lesson, a domain might contain concepts such as a customer, an order, or a representative. It might also describe relationships such as “customer places order” and properties such as an order's status. The exact vocabulary depends on the domain. The important point is that the vocabulary and its connections are made explicit and shared.

Why graphs are a natural bridge

The speaker connects ontologies to graph databases and knowledge representation. A graph represents things as entities and connects them with relationships. This makes a domain model easier to inspect as a network of meaningful facts:

flowchart LR
    Customer -->|places| Order
    Representative -->|supports| Customer
    Order -->|has status| Status

This diagram is a teaching illustration of the structure being discussed. It is not a diagram reproduced from the source. Its purpose is to show the difference between the parts:

• Entities or concepts are the things being described, such as Customer and Order.
• Relationships connect those things, such as places.
• Properties describe an entity or relationship, such as an order's status.

A graph representation does not automatically make a model an ontology. A graph is a way to represent connected information. An ontology adds a formal, shared account of what the kinds of entities and relationships mean. Likewise, a philosophical category is not identical to a database class. The historical connection supplies the motivation for organizing knowledge; the software model supplies the precise representation used by later tools.

The bridge to agentic systems

The speaker's engineering question is whether an agent should operate without an explicit model of its domain. His proposal is that an agent can be given a conceptualization of the relevant universe instead.

That gives the two lineages complementary roles:

Part	Main role
Agent	Perceives information, chooses steps, and acts through tools or other operations
Ontology	Describes the domain's concepts, relationships, and allowed assumptions in a shared formal model

The ontology does not replace the agent. It gives the agent's surrounding system a structured reference frame. Later in the talk, that reference frame will support checking and inference: the system can ask whether a proposed result fits the domain model instead of treating every generated proposal as valid merely because it is readable.

So the central connection is simple:

An agent supplies action and flexibility; an ontology supplies an explicit model of what those actions mean.

The remaining chapters make this connection concrete by showing how formal graph rules can infer types, express constraints, and validate information returned by an agent's tools.