Read the talk
Why Agentic Systems Need Ontologies

Frank Coyle explains how formal domain models, graph-based inference, and validation can constrain probabilistic agents before their proposed actions produce costly or incorrect outcomes.
From a talk by Frank Coyle
At a glance
Ideas worth remembering
Ontologies give agents an explicit domain model of entities, properties, and relationships instead of relying entirely on probabilistic language generation. 3:49
Top-down and bottom-up modeling are complementary approaches: experts can define core business concepts, while observed customer interactions can reveal additional entities and relationships. 5:23
RDFS and OWL add inference and constraints, enabling systems to derive classifications, follow transitive relationships, and reason about relationships that permit only one value. 9:18
Validate tool results inside the agent loop before accepting them; inconsistent outcomes can be returned to the model or escalated to a human. 14:39
Type checking and business-rule checking solve different problems: Pydantic validates parameter structure, while ontologies can identify duplicate refunds, misdirected payouts, and invalid status values. 17:43
Delay side effects and control iteration because agent loops can drift, run indefinitely, increase token costs, or commit incorrect changes before domain validation occurs. 13:13
Two traditions converge in agentic AI

Frank Coyle frames agentic systems as the convergence of two intellectual traditions: agents that perceive, decide, and act, and ontologies that describe the entities, relationships, and categories within a domain. His central argument is that useful autonomy requires more than a model that can generate plausible language; it also requires an explicit account of the world in which the agent operates. 1:30
An ontology provides a formal, shared conceptualization of that operating environment. Rather than leaving an organization’s assumptions implicit in prompts or scattered across application code, it identifies the concepts that matter and specifies how they relate. Coyle describes the combination of probabilistic language models with formal representations as neurosymbolic AI, joining neural-network capabilities with symbolic mechanisms such as rules and knowledge graphs. 3:49
The objective is not to eliminate the generative character of language models. Coyle treats their probabilistic, imaginative behavior as part of their value, while arguing that the same behavior makes them unreliable as the sole authority over domain-specific decisions. Symbolic structures can therefore serve as guardrails without replacing the model’s ability to interpret context and propose actions. 3:49
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Build a domain model that can evolve

At its simplest, an ontology represents entities, their properties, and the relationships connecting them. Coyle associates this approach with graph-based data structures, where additional properties or relationships can be attached as the domain evolves. He contrasts that flexibility with relational schemas, which he characterizes as more restrictive when new kinds of information require structural changes. 5:23
A top-down approach begins with domain experts defining the important concepts and relationships. In a business setting, that might include purchase orders, customers, and customer representatives, together with their respective properties and interactions. Coyle connects this method to earlier expert-system work while noting a historical limitation of those systems: they struggled to scale. 5:23
A bottom-up approach instead extends the ontology using information encountered in practice, such as customer interactions and the entities or relationships those interactions reveal. Existing vocabularies can also reduce the need to invent terminology from scratch; Coyle points to schema.org, Dublin Core, social-network modeling, and DBpedia as examples of prior work that can inform a domain model. 6:38
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Turn relationships into inference and constraints

A graph of named entities is useful, but Coyle emphasizes the additional value of technologies such as RDFS and OWL, which support inference and control over the graph. These mechanisms describe what relationships imply, allowing the system to derive information that was not explicitly entered as a separate fact. 9:18
For example, if a teaching relationship has the domain of teacher, a statement that Bob teaches scooter implies that Bob is a teacher. If all teachers are persons, the system can further infer that Bob is a person. If the same relationship has the range of student, scooter can also be classified as a student, expanding the system’s understanding through structured rules rather than additional model-generated guesses. 9:18
OWL-style properties extend this reasoning. A transitive property allows an ancestor relationship to carry across multiple generations: if Sue is an ancestor of Mary and Mary is an ancestor of Anne, Sue can be inferred to be an ancestor of Anne. A functional property permits only one value for a relationship; in Coyle’s example, two different names supplied for one person’s father imply that those names refer to the same individual. 10:29
Coyle presents these derivations and constraints as an auxiliary reasoning layer alongside the graph itself. That separation matters for agentic systems because the graph supplies domain facts, while the accompanying rules determine which conclusions or proposed relationships are consistent with the domain model. 9:18
Asserted teaching relationship
Domain, subclass, and range rules derive additional facts from one relationship.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Place ontology checks inside the agent loop

Agent loops give a system the ability to revisit a task, request tools, and continue iterating. Coyle links this pattern to established programming concepts—sequence, conditionals, and iteration—but stresses that loops introduce operational risks: they can become infinite, drift as agents interact, or accumulate significant token costs. Greater capability therefore also increases the need for explicit controls. 11:53
In his Claude agent example, the language model receives a prompt and information about an available tool. The model does not execute the tool itself; it proposes the call and its input parameters, after which application code inspects the model’s stop reason and executes the tool when the response indicates tool use. This distinction places responsibility for real-world execution in the surrounding system rather than in the model alone. 13:13
The critical intervention comes after the tool runs and before its result is accepted. Coyle proposes translating the returned information into a representation that a domain-aware validator can evaluate against the ontology. If the result is reasonable, the loop can continue; if it is inconsistent, the application can send the problem back to the model or involve a human. 16:15
This pattern treats ontology validation as part of the agent’s control flow, not merely as background documentation. The model contributes contextual interpretation and candidate actions, tools supply operational results, and the ontology provides a structured basis for deciding whether those results fit the organization’s established concepts and rules. 3:49
Tool call and input parameters
Application code executes proposed tool calls and checks returned information against domain rules.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Separate type safety from business correctness

Coyle distinguishes structural validation from semantic validation. He recommends Pydantic for checking that incoming parameters have the expected types, then using the ontology to evaluate whether the resulting action or data makes sense within the domain. Correctly shaped inputs are necessary, but they do not establish that an operation respects business relationships or domain constraints. 17:43
He also recommends keeping agents free of consequential side effects until their proposed behavior has passed validation. In practical terms, an agent should not immediately alter a database or otherwise commit a change simply because a model proposed it. Running the proposal through ontology-based checks first makes it possible to reject or escalate a problematic action before it becomes durable. 16:15
The examples are concrete: a second refund on the same order, a payout routed to a support representative instead of the buyer, or an invented order status outside an allowed set such as paid, shipped, and refunded. Coyle argues that functional properties, disjoint categories, and constrained values make these failures more explicit than relying on natural-language instructions alone. 18:59
The proposed architecture is ultimately a layered one: probabilistic models interpret and propose, typed interfaces constrain inputs, tools perform execution, and ontology-backed reasoning checks domain consistency before important outcomes are accepted. Coyle presents this as a practical guardrail for agent behavior, while acknowledging that loops still require careful management because drift, runaway iteration, and token costs remain possible. 13:13
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.