By the end of this talk

You will know how to find whether the model or its knowledge limits your AI feature.

And you will have a rule for when to write that knowledge down as a contract, and when not to bother.

THREAD 01: THE FAILURE

Every morning, you are the integration layer

The forecast is in a weather app.

Your schedule is in a calendar.

What you actually own is in a closet.

15 shirts and 10 pairs of pants make 150 outfits.

You can put on a lot of stuff. That does not mean you are putting that sh*t on.

What PTSO knew about my closet

PTSO knew the forecast, and it knew the fabric. Nothing connected the two.

Six recommendation fields: type, category, brand, color, fabric, style.

Enough to filter a list. Not enough to justify a choice.

The suede loafers matched on color, on style, and on temperature. Every check the system had, passed.

Not one of them knows what rain does to suede.

What PTSO knew about my closet

Better agents did not give me better answers

I tuned the orchestration. I improved the prompts. I moved to newer models.

The same knowledge gap remained.

Model upgrades did not give PTSO the missing rule.

What PTSO knew about my closet

What if hallucination is a feature, not a bug?

Generative models need freedom to propose new combinations.

That freedom can also produce unsupported claims.

Model improvements alone cannot enforce every domain rule.

Put the invariant outside the model.

Frank Coyle, UC Berkeley — Why Agentic Systems Need Ontologies

What PTSO knew about my closet

PTSO was missing a stronger substrate

The model had data.

It did not have enough rules about what that data meant.

The ontology made those rules explicit and checkable.

THREAD 02: THE RULEBOOK

What is an ontology?

"An explicit specification of a conceptualization."

Thomas Gruber, 1993. This is the definition the field actually uses.

Defining the term

Dude, what?

Defining the term

In plain English: an ontology is a rulebook for your data

The names for each thing.

What each name means.

The allowed combinations.

Written down in one place, outside the model, where anything can check it.

Defining the term

Your closet is already an ontology

This rulebook is your taste. You already follow every line of it. Software cannot read any written copy.

THREAD 03: THE CONTRACT

PTSO's contract knows facts that nobody typed

A human typed wool blend. A human typed navy marl twill.

Nobody typed layers over the merino crewneck.

PTSO worked that one out, and it names the rule that did it.

What I learned

Every version of PTSO gave the model less to decide

V1 — one orchestrator and three specialist model calls. Three A2A delegations.

V2 — the product endpoint bypassed the orchestrator and called outfit_agent directly.

V3 — rules validate every agent proposal. One repair is allowed before fallback.

Every version gave the model fewer decisions that software could make reliably.

What I learned

So should you build an ontology? Maybe.

Build it when two systems must agree on a word, a wrong combination costs money, or the rule outlives the prompt.

Skip it when one codebase reads the data, a retry is cheap, or you cannot write the rule in a sentence.

Illustrative patterns

What this looks like outside a closet

Clinical. A clinical system could check known interaction rules.

Access control. An access system could limit the rows before model access.

Manufacturing. A manufacturing system could reject incompatible parts.

The pattern stays the same. The agent proposes. The contract decides what survives.

What I learned

Models propose. Contracts dispose.

If an answer sounds right but violates a rule, write the rule where software can check it.

Let the model propose. Let the contract decide what survives.