Practical course

Ontology for AI Agents

Learn to turn a messy business domain into a precise model an AI agent can reason over, act within, and share with other systems. No philosophy history, no unnecessary formalism.

3 htarget duration

50/50fundamentals / AI use

8short modules

100final exam points

Learning outcome

What you should be able to do after this course

Model a domain

Identify entities, types, attributes, relations, roles, states, events, constraints and boundaries.

Design an agent world model

Separate facts, rules, tools, permissions and actions so an agent knows what exists and what it may do.

Spot weak models

Detect ambiguity, duplicated concepts, hidden assumptions and unstable identifiers before they become agent errors.

Build a first ontology

Produce a compact ontology for a real business process and test whether it is good enough to implement.

Working definition:An ontology is an explicit model of what kinds of things exist in a domain, how they are distinguished, and how they can relate to one another.

Part I · Module 1~19 min

Ontology in one sentence

An ontology answers three practical questions:What exists? What kind of thing is it? How can things relate?

Ontology is not the same as a taxonomy

Artifact	Main question	Example
Glossary	What do words mean?	“Customer” = legal or natural person buying from us.
Taxonomy	How do we classify things?	Product → Adhesive → Cyanoacrylate.
Database schema	How is data stored?	`customer_id`, `credit_limit`.
Ontology	What exists and how is it related?	A Customer owns Stores, places Orders, has Credit Terms, and may be under Delivery Stop.

Why agents care:A language model can read “Acme has a 50,000 limit,” but an agent needs to know whether 50,000 is a credit limit, order limit, annual budget, or account balance; which entity owns it; and what decisions may depend on it.

Minimal ontology pattern

TYPE: Customer
INSTANCE: Acme Retail Ltd.
ATTRIBUTE: credit_limit = 50,000
RELATION: Customer OWNS Store
STATE: Customer HAS delivery_status = STOPPED
EVENT: PaymentReceived
RULE: PaymentReceived MAY_CHANGE delivery_status

1. Which statement best describes an ontology?

A list of domain terminology. A hierarchy of categories. A model of domain entities, distinctions and relations. A database table design.

2. “Product → Adhesive → Cyanoacrylate” is primarily:

a state machine a taxonomy an agent tool a business rule

Ask the tutor

Ask for a simpler explanation, another example, or a practical application. The tutor knows this module.

Mark complete when the distinction is clear.

Part I · Module 2~19 min

Entities, types, instances and identity

Entity

A thing you need to reason about independently: Customer, Order, Invoice, Store.

Type

A class of things sharing rules or structure: Customer, Employee, Product.

Instance

One specific member: Order #A-1048.

Attributes vs entities

If something has its own identity, lifecycle, relations or history, it usually deserves to be an entity rather than a text field.

Weak:Customer has attributestore = "Paris 17".
Stronger:Store is an entity with address, opening date, manager, sales history and relationOWNED_BY Customer.

Identity is an operational decision

Every important entity needs an answer to:What makes this the same thing over time?

A customer changes name: same customer if legal identity/tax ID is unchanged.
A store moves: maybe same store if your business treats it as continuous; maybe new location entity if place matters independently.
An employee changes role: same Person, different RoleAssignment.

Common failure:using names as identity. Names change and are duplicated. Prefer stable identifiers and explicit identity rules.

3. A sales manager changes from Region North to Region West. Best model?

Create a new person. Change the person's name. Store the region inside the employee ID. Keep the Person; change the Role/Assignment relation.

4. Which is the strongest signal that something should be its own entity?

It has an independent identity/lifecycle and relations. Its name is long. It appears in a spreadsheet column. It is numeric.

Ask the tutor

Ask for a simpler explanation, another example, or a practical application. The tutor knows this module.

You should now distinguish type, instance, attribute and entity.

Part I · Module 3~19 min

Relations, roles, states, events and time

Relations carry meaning

Prefer explicit relation names that describe semantics, not vague links.

Weak

Customer — linked_to — Manager

Strong

Manager — RESPONSIBLE_FOR — CustomerAccount

Role ≠ identity

A role is contextual and can change. “Approver,” “Sales Manager,” “Buyer” and “Account Owner” usually belong in role assignments, not as permanent types of person.

State ≠ event

Concept	Meaning	Example
State	What is true during an interval	Delivery is STOPPED
Event	Something that happens	PaymentConfirmed
Process	Ordered activity over time	Credit Review

Temporal modeling:“Customer has credit limit 100,000” is incomplete if limits change. Better: a CreditLimitAssignment has amount, valid-from, valid-to, approver and reason.

5. “Payment received at 14:03” is best modeled as:

a role an event an entity type only a taxonomy branch

6. Why model time explicitly for changing business facts?

It makes diagrams prettier. LLMs require timestamps everywhere. Current and historical truth may differ, and decisions need the correct version. Databases cannot store changing values otherwise.

Ask the tutor

Ask for a simpler explanation, another example, or a practical application. The tutor knows this module.

You should now recognize state, event, role and temporal facts.

Part I · Module 4~18 min

Constraints, boundaries and model quality

Constraints turn a vocabulary into a usable model

Examples:

Every Order belongs to exactly one Customer.
A CreditLimit must have currency and effective date.
A DeliveryStop may be released only by an authorized role.
An Invoice can be overdue only after its due date.

Cardinality

Customer 1 — places — 0..N Orders
Order 1 — belongs_to — 1 Customer
Cardinality exposes missing assumptions that natural language hides.

Boundary discipline

Do not model the whole company. Model only what the agent needs to distinguish, reason about or act upon.

Test:If removing a concept cannot change any relevant agent decision, action, explanation or data retrieval, question whether it belongs in the ontology.

Five quality checks

Uniqueness:can entities be identified reliably?
Non-ambiguity:does each important term have one operational meaning?
Completeness:are required decision concepts represented?
Consistency:do constraints contradict each other?
Minimality:did you avoid modeling irrelevant complexity?

7. Best reason to add a concept to an agent ontology:

It can affect retrieval, reasoning, action or explanation. It exists somewhere in the ERP. It is mentioned by senior management. It appears in more than one spreadsheet.

8. “Each order must belong to exactly one customer” is:

an instance an event a synonym a constraint

Ask the tutor

Ask for a simpler explanation, another example, or a practical application. The tutor knows this module.

Part I complete: you now have the modeling vocabulary.

Part II · Module 5~19 min

Ontology as an agent’s world model

A prompt tells an agentwhat to do. An ontology tells itwhat the world contains and what its statements refer to.

Prompt

“Assess whether this customer’s credit limit should be increased.”

Ontology

Defines Customer, Account, CreditLimit, Turnover, Store, Order, ConditionChange, Evidence, Decision and their relations.

Agent reasoning loop

Observe data
→ map data to ontology concepts
→ construct current world state
→ detect missing facts
→ retrieve/call tools
→ apply rules/policies
→ choose allowed action
→ record outcome + explanation

Important:The ontology does not replace business rules. “An invoice has a due date” is ontology. “Stop delivery after 10 overdue days” is policy/rule.

Three layers to keep separate

Layer	Example
World model / ontology	Invoice, due date, payment, customer, delivery stop
Decision policy	If overdue_days > 10, stop delivery unless exception is approved
Agent procedure	Fetch invoices → calculate overdue days → check exceptions → recommend action

9. Which belongs primarily in the ontology?

“If overdue > 10 days, block delivery.” “An Invoice has a due date and may be linked to Payments.” “Call ERP API every morning.” “Summarize the result in three bullets.”

Ask the tutor

Ask for a simpler explanation, another example, or a practical application. The tutor knows this module.

You should now separate ontology, policy and procedure.

Part II · Module 6~19 min

Connect ontology to data, tools, rules and actions

Map ontology concepts to real systems

Ontology concept	Possible source/tool	Agent use
Customer	CRM / ERP	identity, hierarchy, account owner
Invoice	ERP	amount, due date, status
PaymentEvidence	bank feed / uploaded file	supports release decision
ApprovalAuthority	IAM / policy table	limits allowed actions

Tool contracts should use ontology terms

Weak tool: get_data(id)
Strong tool: get_open_invoices(customer_id)returning Invoice objects with IDs, due dates, currencies and payment status.

Actions need preconditions and consequences

ACTION: ReleaseDeliveryStop
PRECONDITIONS:
  - DeliveryStop exists and is ACTIVE
  - actor has ReleaseAuthority
  - evidence satisfies current policy
EFFECT:
  - DeliveryStop becomes RELEASED
  - Decision record is created
  - reason and evidence are linked

Design rule:Never let an LLM invent the meaning of tool parameters from prose if you can encode the meaning structurally.

10. What is the strongest tool design?

One generic tool that returns all ERP data. A tool described only in the system prompt. Narrow tools whose inputs/outputs map clearly to ontology concepts. Let the model construct SQL directly for every task.

Ask the tutor

Ask for a simpler explanation, another example, or a practical application. The tutor knows this module.

You should now connect a world model to operational systems.

Part II · Module 7~19 min

Memory, knowledge graphs and multi-agent systems

Memory should store facts about entities, not just text

Unstructured memory: “Acme had a discussion about delayed payment last month.”

Structured memory:PromiseToPay(customer=Acme, amount=25,000, promised_date=2026-08-25, source=email_184).

Knowledge graph = ontology + instances + relations

The ontology defines what the graphmay mean. The graph contains actual facts.

Acme → OWNS → Store_17
Invoice_881 → ISSUED_TO → Acme
Payment_402 → SETTLES → Invoice_881

Multi-agent systems need shared semantics

If one agent uses “customer” to mean legal entity and another uses it to mean delivery location, handoffs will fail even when both models are individually capable.

Shared ontology = interface contract for meaning.It is especially valuable when multiple agents exchange structured objects or decisions.

Provenance is part of trustworthy memory

Important facts should retain source, timestamp, confidence/status and—when relevant—who asserted or approved them.

11. Best persistent agent memory for an important business fact:

Structured entity/relation plus source and time. A paragraph summarizing the whole conversation. The model’s hidden reasoning. A random embedding without metadata.

Ask the tutor

Ask for a simpler explanation, another example, or a practical application. The tutor knows this module.

You should now see ontology as the semantic layer behind memory and handoffs.

Part II · Module 8~18 min

Build and test an ontology for an agent

The 9-step build method

Define the agent’s decision/action scope.
List the questions it must answer.
Extract nouns → candidate entities/types.
Extract verbs → candidate relations/actions.
Separate attributes from independent entities.
Define identity and time semantics.
Add states, events, constraints and permissions.
Map each important concept to a data source/tool.
Test against real and adversarial cases.

Competency questions

An ontology is only useful if it can answer the questions the agent needs. Write these questionsbeforeover-modeling.

Can the model answer:
• What is the customer’s current approved credit limit?
• When did it become effective?
• What evidence explains the recent increase in orders?
• Is the requested action within the manager’s authority?
• Which unpaid invoices are causally relevant to the stop?

Adversarial tests

Same name, different customer.
One customer with multiple legal entities.
Payment evidence exists but payment is not confirmed.
Historical credit limit differs from current limit.
Rule changed yesterday.
Agent receives contradictory data from two systems.

Stop criterion:The ontology is “good enough” when relevant cases can be represented without ambiguity and the agent can reliably retrieve facts, apply policy and explain decisions. Perfection is not required.

12. Best first step when building an ontology for an agent:

Import the entire ERP schema. Define what decisions/actions the agent must support. Choose RDF or OWL. Write a 20-page glossary.

Ask the tutor

Ask for a simpler explanation, another example, or a practical application. The tutor knows this module.

You now have a repeatable ontology design method.

Canvas

Practical workspace

Ontology Builder Canvas

Use this while taking the course. It saves automatically in your browser.

1. Agent scope / decisions 2. Competency questions 3. Core entities / types 4. Identity rules 5. Relations 6. States / events / time 7. Constraints / cardinality 8. Rules / policies 9. Data sources / tools 10. Actions / permissions 11. Provenance / confidence 12. Adversarial tests

Exam

Final assessment~30 min

Final exam — 100 points

Scenario:A company wants an AI agent to review requests to temporarily release a delivery stop for customers with overdue payments. A manager submits a request with a reason and evidence. Evidence may be a bank payment confirmation, a copy of a payment order, a written promise to pay, or an agreement to pay on delivery. The agent may recommend release, refusal or escalation, but only authorized humans can execute the release.

Q1 — Domain model20 points

Define the minimum useful entities/types and the key relations between them. Explain any concept you deliberately keep as an attribute rather than an entity.

Q2 — Identity, states and time20 points

Define identity for Customer, Invoice and PaymentEvidence. Then define the important states/events and which facts must be time-aware.

Q3 — Ontology vs policy vs procedure20 points

Give at least 3 examples of ontology facts, 3 policy/rule statements and 3 procedural/tool steps. Keep the three layers clearly separated.

Q4 — Agent action design20 points

Design the actionRecommendReleaseDeliveryStop: inputs, preconditions, outputs, evidence/provenance requirements and failure/escalation conditions.

Q5 — Testing20 points

Give 5 adversarial test cases that could cause a weak ontology or agent to make the wrong recommendation. For each, state what modeling feature prevents the failure.

LLM

Server integration

Local LLM connection

This course uses the same protected server-side LLM proxy as the Sales LLM Lab. No model endpoint, bearer token or API key is exposed in the browser.

Proxy: /sales/api/ask_agent2.php
The browser sends onlyinstructionsandinput. The existing PHP proxy forwards the request through your server-sidellm_config.php.

Connection not tested yet.

One-page reference

Agent Ontology Checklist

What decisions/actions is the agent responsible for?
What entities must exist for those decisions?
How is each entity identified?
Which distinctions are types, roles, attributes, states or events?
Which relations matter?
Which facts change over time?
What constraints/cardinalities must always hold?
Which statements are ontology vs business rules?
Where does each fact come from?
What tools expose those facts/actions?
Who is allowed to execute which actions?
What provenance must be retained?
Can every competency question be answered?
What adversarial cases break the model?