## Introduction

Imagine an AI that approves a second refund on the same order. Its reasoning is clear, and the tool call is correct. Yet, the refund remains wrong, and system knowledge isn't enough to stop it, since the rule "one order gets one refund" exists only in someone's mind.

That rule belongs in an ontology. By the end of this article, you'll understand what an ontology is, why developers have always needed one, and why agents and LLMs need a robust one more than ever.

Credit to Frank Coyle's talk [Agents Need Ontologies][coyle-talk] for insights. With 30+ years of teaching computer science and experience in the expert systems era, his perspective adds depth most agent talks lack. This article highlights key reasons and links them to daily work. Watch his 20-minute talk; it's worthwhile.

## What Is an Ontology?

Outside academic jargon, an ontology is a shared model of your domain. It identifies entities (customers, orders, refunds), their relationships (a customer places an order), their properties, and the rules for valid combinations.

Tom Gruber's definition remains valid: an ontology is a [formal specification of a shared conceptualization][gruber]. Essentially, it's documenting how your organization views its world in a way software can verify.

An ontology coexists with a [knowledge graph], which holds facts like 'Bob placed order 4021'. The ontology defines vocabulary and rules, e.g., an order has one customer and a status must be paid, shipped, or refunded. The concept predates computing; Aristotle categorized the world long before databases.

## Why Do Developers Need an Ontology?

Three reasons, and none of them require an AI in the room.

* **A shared vocabulary kills an entire class of bugs.** When services use different terms like "customer," "account," and "user," integration becomes guessing. An ontology standardizes naming early, similar to Domain-Driven Design's ubiquitous language, making ontology building a design activity. The process is detailed in [how to create a software ontology][create ontology].

* **Graphs bend where tables break.** Relational schemas are rigid; adding a new attribute requires altering tables and migrating data. A graph model lets you attach new entities, properties, or relationships without restructuring, making knowledge graphs ideal for ontologies.

* **Inference gives you facts for free.** Write that "teaches" links a teacher to a student, and every teacher is a person. The statement "Bob teaches Scooter" indicates Bob is a teacher and a person, and Scooter is a student. One fact reveals four truths. Small rules build real knowledge.

That developer case stood alone for decades until agents arrived and raised the stakes.

## Why Do Agents and LLMs Need One Even More?

A large language model is inherently probabilistic; it predicts the next likely token, which explains hallucinations—a trade-off for creativity. Coyle highlights that imagining non-existent things is an intended feature, even if it includes something like an order status.

An LLM can't act alone; it proposes tool calls, and your code executes them. Most guesses are good, but bad ones look like good ones.

The model loops, changing everything. Sequence, conditionals, and iteration make a system Turing-complete, meaning an agent loop can compute anything. It inherits classic failures: runaway, drift as agents communicate, and token or money burn.

A probabilistic engine performs real actions in an unbounded loop, guarded by the ontology, known as neurosymbolic AI. The neural part generates actions, while the symbolic part ensures they stay within domain boundaries.

## How an Ontology Keeps an Agent Honest

The mechanism is a validation step in the agent loop, where the model proposes, the tool runs, and a reasoner checks results against the ontology before finalizing or triggering effects.

```mermaid
graph TB
    A[Prompt plus context] --> B[LLM proposes a tool call]
    B --> C[Your code runs the tool]
    C --> D[Validator checks the result against the ontology]
    D -->|Valid| E[Accept the fact, continue the loop]
    D -->|Invalid| F[Reject, send back to the LLM or a human]
    F --> B

    style A fill:#e1f5fe
    style B fill:#f3e5f5
    style C fill:#e8f5e8
    style D fill:#fff3e0
    style E fill:#e8f5e8
    style F fill:#ffebee
```

Standards like [RDF Schema][rdfs] and the [Web Ontology Language][owl] (OWL) provide a few constraint types that catch very specific mistakes:

* **Functional properties** mean "exactly one." Declare that an order takes exactly one refund; duplicate refunds fail validation instead of clearing.
* **Disjoint classes** mean "never both." Declare that a customer and support rep are disjoint, and a payout to support instead of the buyer gets rejected as a category error.
* **Range constraints** mean "only these values." Declare that order statuses must be paid, shipped, or refunded; unsupported statuses like "probably shipped" are invalid.
* **Transitive properties** derive facts across hops. If Sue is an ancestor of Mary and Mary is an ancestor of Anne, the reasoner concludes Sue is an ancestor of Anne without explicit statement.

In OWL's Turtle syntax, the first three look like this:

```turtle
:refundFor a owl:FunctionalProperty .        # one refund per order

:Customer owl:disjointWith :SupportRep .     # a payout target is one or the other

:orderStatus rdfs:range :OrderStatus .       # paid, shipped, or refunded only
```

Every mistake described in English is easy, but nearly impossible to prevent with English. A prompt like "never issue two refunds for one order" is a suggestion to a probabilistic engine. Functional properties are rules enforced by a deterministic checker. Suggestions fail silently, while rules fail loudly and immediately before the money moves.

## Types Check the Shape, Ontologies Check the Meaning

If you're building agents in Python, you're probably using [Pydantic][pydantic] to validate tool parameters. Keep doing that. But understand what it buys you: Pydantic confirms the shape is right. The amount is a number, the order ID is a string, the required fields exist. It has no opinion on whether refunding that order twice makes sense.

Coyle succinctly states: Pydantic at the door, ontology at the ledger. Type checking guards the entrance; domain checking guards the books. Both are necessary, as a well-typed request can still be wrong.

Another habit from the talk: keep agents free of side effects until validated. An agent writing to the database mid-loop commits the mistake you want to catch. Propose first, validate second, commit last.

## Don't Build Yours From Scratch

Two paths lead to a working ontology and meet in the middle. Top-down, domain experts model entities, properties, and relationships. Bottom-up, you mine interactions (support tickets, orders, event streams) and promote recurring entities and relationships.

Either way, steal before you build. People have spent 20 years constructing shared vocabularies you can reuse:

* [schema.org][schemaorg] covers products, events, people, organizations, and most things a business touches.
* [FOAF][foaf] (Friend of a Friend) models people and social connections.
* [Dublin Core][dublincore] describes documents and creative works.
* [DBpedia][dbpedia] extracts Wikipedia into a queryable knowledge graph, proving this stuff runs at planetary scale.

Once the model exists, the work shifts to keeping it alive and in daily use; [how to use a software ontology][use ontology] covers that half of the job.

## Trade-offs and Limitations

An ontology has real costs; ignoring this leads to disappointment.

* **Modeling costs real effort up front.** Getting experts to agree on what a "customer" is takes longer than you'd think, and the argument is the point.
* **Symbolic AI alone already failed once.** The expert systems of the 1980s promised this exact dream, consumed millions of dollars, and collapsed into an AI winter because hand-built rules couldn't scale. The lesson: rules work as a check on a learning system and fail as a replacement.
* **An ontology drifts if you let it.** Your domain changes; a model nobody maintains becomes confidently wrong, which is worse than absent.
* **Validation is only as good as the facts you extract.** If no code translates the tool result into ontology terms, the reasoner has nothing to reason about.
* **Some errors live outside its reach.** An ontology checks structure and consistency. It can't tell you whether an apology email has the right tone.

## Common Misconceptions

* **"The next model will fix hallucination."** Wishing won't make a probabilistic system deterministic. Sampling from a distribution is the core design. Better models hallucinate less; none reach zero. Guardrails outperform patience.
* **"An ontology is just a database schema."** A schema limits storage; an ontology defines meaning, spans systems, and enables inference. Your database may store two refunds for one order, but your ontology recognizes the error.
* **"A careful prompt is enough."** Prompts influence probability but can't enforce outcomes, and an agent loop offers many chances for low-probability failures.
* **"Ontologies are academic."** schema.org markup shapes the search results you clicked, and DBpedia provides structured knowledge from Wikipedia. It's reliable, proven infrastructure—the best infrastructure can be.

## Conclusion

An LLM is a probabilistic engine: fluent, creative, and incapable of knowing when it's wrong. An ontology is a deterministic frame: a formal, shared model of your domain that a reasoner can check proposals against. Developers need the frame because shared vocabulary and inference prevent whole categories of bugs. Agents need it more, because a loop gives a probabilistic engine unlimited attempts to be confidently wrong, with your database and your budget on the line.

Give your agents what Gruber promised: your conceptualization of your world, in a form they can be held to.

## Next Steps

* Watch Frank Coyle's talk, [Agents Need Ontologies][coyle-talk], for the source of these ideas in his own words.
* Read [What Is a Knowledge Graph?][knowledge graph] for the data structure ontologies live on.
* Follow [How Do I Create a Software Ontology?][create ontology] to build one with Domain-Driven Design.
* Then see [How Do I Use a Software Ontology?][use ontology] to keep it alive in daily work.
* If agents are new territory, start with [What Are Coding Agents?][coding agents].

## References

* [Agents Need Ontologies][coyle-talk], Frank Coyle's talk on agents, ontologies, and neurosymbolic guardrails, and the primary source for this article.
* [Toward Principles for the Design of Ontologies][gruber], Tom Gruber's paper behind the "formal specification of a shared conceptualization" definition.
* [RDF Schema][rdfs], the W3C vocabulary for classes, properties, domains, and ranges.
* [Web Ontology Language (OWL)][owl], the W3C standard for functional, transitive, and disjointness constraints.
* [schema.org][schemaorg], the shared vocabulary used by search engines and millions of sites.
* [FOAF][foaf], an early ontology for modeling people and social networks.
* [Dublin Core][dublincore], metadata terms for describing documents and creative works.
* [DBpedia][dbpedia], the knowledge graph extracted from Wikipedia.
* [Pydantic][pydantic], runtime type validation for Python, the "at the door" half of the guardrail.

[coyle-talk]: https://youtu.be/Sir59K8ZDPU
[gruber]: https://tomgruber.org/writing/onto-design.pdf
[rdfs]: https://www.w3.org/TR/rdf12-schema/
[owl]: https://www.w3.org/OWL/
[schemaorg]: https://schema.org/
[foaf]: http://xmlns.com/foaf/spec/
[dublincore]: https://www.dublincore.org/specifications/dublin-core/dcmi-terms/
[dbpedia]: https://www.dbpedia.org/
[pydantic]: https://docs.pydantic.dev/
[knowledge graph]: https://jeffbailey.us/what-is-a-knowledge-graph/
[create ontology]: https://jeffbailey.us/how-do-i-create-a-software-ontology/
[use ontology]: https://jeffbailey.us/how-do-i-use-a-software-ontology/
[coding agents]: https://jeffbailey.us/what-are-coding-agents/