# Why Agentic Systems Need Ontologies — Frank Coyle, UC Berkeley AI Engineer · 2026-07-23 Frank Coyle argues that most agent failures, from brittle tools to fragile handoffs, stem from missing formal ontologies as logical guardrails. He proposes neurosymbolic AI: probabilistic reasoning inside, logic outside. An ontology is typed entities, relationships, and constraints expressed with RDFS and OWL, letting you specify a payment status must be one of three values, that a customer and support rep are different, or that an order can only be refunded once. Wrapping a Claude tool use loop with a validator—Pydantic at the door for types, ontology at the ledger for results—catches errors like a second refund on the same order, a payout sent to the support desk instead of the buyer, or an order status of 'probably shipped' that English instructions cannot reliably prevent. ## Questions this episode answers ### Why do agentic AI systems need formal ontologies? Frank Coyle argues that probabilistic agents make mistakes like issuing double refunds or sending payouts to wrong parties because LLMs reason over domains they only half-understand. A formal ontology provides typed entities, relationships, and constraints (like “an order can only be refunded once”) that act as logical guardrails outside the model, catching errors that English instructions cannot reliably prevent. [18:59](https://aiengineer.podhood.com/09734458-bc08-4a82-9d0f-6cc7a36550fc?t=1139000) ### What is neurosymbolic AI and how does it combine LLMs with symbolic systems? Frank Coyle describes neurosymbolic AI as the convergence of probabilistic neural networks (like LLMs) with formal symbolic representations, such as ontologies and knowledge graphs. It uses logical guardrails from RDFS and OWL to constrain LLM outputs—for instance, enforcing that a payment status must be one of three values—thereby keeping the probabilistic model on track while leveraging its generative strengths. [4:23](https://aiengineer.podhood.com/09734458-bc08-4a82-9d0f-6cc7a36550fc?t=263000) ### How does Frank Coyle implement an agent loop with an ontology validator? Frank Coyle demonstrates a Python loop with Claude where the LLM proposes a tool call. Before executing, the tool’s parameters are type-checked with Pydantic, and its results are validated against the ontology. If the response passes the ontology check, it proceeds; if not, the loop sends feedback back to the LLM. This keeps the agent from taking invalid actions and prevents drift, infinite loops, or costly mistakes. [14:22](https://aiengineer.podhood.com/09734458-bc08-4a82-9d0f-6cc7a36550fc?t=862000) ## Key moments - **[0:00] Teaching Philosophy** - [1:10] Frank Coyle quotes Sister Corita Kent: "Nothing is a mistake. There is no win, there's no fail, there's only make." - **[2:17] Two Lineages** - [3:49] Tom Gruber's 1993 definition: ontology as "a formal specification of a shared conceptualization" - **[4:23] Neurosymbolic AI** - [4:59] LLM hallucinations are a feature, not a bug, because probabilistic models are meant to imagine possibilities, says Frank Coyle - **[5:24] Ontology Basics** - **[6:24] Building Ontologies** - [6:55] The expert systems boom of the 1980s collapsed because symbolic AI could not scale, leading to an AI winter, recounts Frank Coyle - **[8:04] Reuse Taxonomies** - **[9:19] RDFS & OWL** - [10:08] Using RDFS domain and range, the statement 'Bob teaches scooter' allows inference that Bob is a teacher and scooter is a student - **[12:09] Agents & Loops** - [13:09] Agentic AI loops achieve Turing completeness, meaning agents can compute anything computable, explains Frank Coyle - **[14:23] Claude Loop** - [15:21] LLMs are incapable of acting; they only generate tool call parameters, relying on external code to execute actions, notes Frank Coyle - **[17:43] Pydantic Guard** - [18:24] Frank Coyle's rule: "Pydantic at the door, ontology at the ledger" for validating agent inputs and results - **[18:59] OWL Errors** - [18:59] Ontologies catch errors like duplicate refunds, wrong payouts, and made-up statuses that probabilistic agents miss in English prompts - **[20:29] Conclusion** ## Speakers - **Frank Coyle** (guest) ## Topics Agent Skill Design ## Mentioned Claude (product), Pydantic (product) ## Transcript ### Teaching Philosophy **Frank Coyle** [0:13] Okay, we're going to launch here. So, my name is Frank Coyle. I'm an educator, I'm teaching at Berkeley now. I've been doing this computer science stuff for, oh, 30, 35 years. And I'm inter— andright now it's kind of a critical time for poor computer science students. It used to be the— used to be the only game in town. Degree was a guaranteed job, and now, thanks to AI, it's not. But then again, 5,000 people are here. So AI and agents are— seem to be the way to go. So the question is, how do we leverage this new universe that we are moving quickly into? And so I want to talk about how agents and ontologies, big word, fit together. But before you— before I do that, I wanted to— I wanted to give you my educational philosophy. And this comes from someone called Sister Corita Kent, and it was made popular by John Cage, who is an avant-garde musician. And you've got to think about this a little bit: nothing is a mistake. There is no win, there's no fail, there's only make. And more and more today, that's what's important. Get down and make stuff, and that's how you're going to learn, not by necessarily reading. I'm also a big fan of writing. My early career was in neuroscience. I'm kind of coming back into it now that agentic AI is bringing kind of cognitive science back. But engage your senses. Get a notebook, get a pen, a pencil, draw pictures, write stuff down. Just don't type. Because when you type— when you're typing, your brain is thinking about the letters on the keyboard. When you're writing in a book, your whole brain, your whole— all your sensory systems are engaged, and you're going to learn faster that way. Okay, on to our talk: agents and ontology. So there are two lineages here, and I want to talk about both. Give you a little philosophical background. Agents: when did we start talking about agents? It goes back to the early, initial days of AI. ### Two Lineages **Frank Coyle** [2:36] People like John McCarthy, Selfridge, Marvin Minsky, Society of Mind— people started thinking about the fact that this new computing technology was going to lead us into some kind of artificial intelligence, which is a term that came in 1956, when all these characters got together and tried to figure out where the future was going. Okay? And the concept of an agent finally evolved. Things that perceive and decide and then act. And that's what we're seeing now. Now, what about ontologies? Well, it turns out ontologies are not that new. Okay? It was actually Aristotle who first came up with the concept of we need a philosophy of being. Like, whoo, kind of heavy. But came up with categories of being. And this kind of relates to what people are doing now with graph databases and knowledge representation. And there were a couple of other people who kind of formalized it. Von Koyne was a philosopher, and then this guy, Gruber, 1993. And I think this captures what knowledge and graph technology really represents. It is a formal specification of a shared conceptualization. And that's what we want to give to our agents. We want to give them our conceptualization of the universe, our universe, our domains. Okay? And now what's happening is you're getting the convergence of something that is probabilistic, the agents, the LLMs, with the more formal representations that you have with ontologies. And so this term is now being used. You're hearing this a lot: neurosymbolic AI. Sounds pretty fancy, but it's really neural networks tied into ### Neurosymbolic AI **Frank Coyle** [4:36] symbolic AI, which rule-based systems come under that category, as do the knowledge graphs that we're assembling. And so what I like to argue is that neurosymbolic AI sort of represents a way to keep the LLM on its guardrails. Because LLMs are, by nature, probabilistic. People worry about hallucinations, but that's the feature. That's actually a feature of large language models. It's who we are. We hallucinate in a way. We imagine things that may not exist, and then we turn them into reality. And that's what large language models do in a way. Okay? So let's just quickly overview what ontologies are. It's not— they're not complicated. They're basically our representation of entities and their relationships to other entities. And these entities have properties. And this whole concept of graph databases arose when people began to realize that relational databases, sticking data into tables, was too restrictive. ### Ontology Basics **Frank Coyle** [5:54] You wanted to add something new to a relational database, so you had to add a new column. Man, and then you have to redo the whole structure. With a graph database, you can just attach another item. You can just attach a property. You can attach a relationship. Okay? So the question often arises: okay, I get it. I need to have an ontology to represent, in a formal way, what my organization is doing. How do I do it? Okay? There are a couple of ways you can approach it. You can have a top-down approach or a bottom-up approach. Top-down approach is you get the experts together, and they sit down and analyze the domain, come up with the entities. What do we have? We have purchase orders. We have customers. ### Building Ontologies **Frank Coyle** [6:38] We have customer representatives. And we're going to structure them. They have properties. These are the relationships. Okay, that's one way. And this models what we were doing back in the '80s when I was involved in expert systems. Everybody thought expert systems was the way to do AI. Symbolic AI was the way to go. Companies rose. Millions of dollars were spent. The Japanese created this Future World Project in the late '80s. People in America were— my son was taking Japanese in school because of these expert systems. And but they couldn't scale. They couldn't scale. And then we went into a kind of AI winter. Where did neural networks come from? Neural networks were put out there in the '60s, but they couldn't scale because we didn't happen to have NVIDIA, who was off making GPUs to make reality of the video games fantastic. And then someone said, "Let's turn these things over to the neural networks." And of course, that's kind of why we're here now. So the other way you can— that people are adding to or creating ontologies is from the bottom up. For example, customer reactions. What are the things the customers are involved in? Hey, these entities, these relationships, let's add this to our ontology. Let's add this information to the graph. Now, as a help, it's helpful to be aware that there are existing taxonomies that people have been working on for the last 15 to 20 years. ### Reuse Taxonomies **Frank Coyle** [8:23] Things like schema.org, which has a whole set of terms and relationships. So you don't have to reinvent the wheel. In fact, it's to your advantage to use some of these ontologies. FOF, a friend of a friend, for modeling social networks. The Dublin Core, which was an early attempt to come up with terms for describing research papers and books and so forth. So there's a whole series of things. In fact, Wikipedia is based on an ontology called DBpedia. So when you do a search on Wikipedia, it's looking things up in its giant graph database. So this stuff has been out there, underlying a lot of what we already do. So take advantage of these things that already exist. Okay, now, what do you do when you build your ontology? Okay, so what? I know what these entities are. I know what their relationships are. They have properties. How can I do anything with them? Well, there are other augmenting technologies, auxiliary technologies. Things that we call things like RDFS, which is a technology, and OWL, which I'll talk more about. ### RDFS & OWL **Frank Coyle** [9:35] So these have— these kind of sit over to the side of your graph. So I'm not going to talk about— I mean, ontology is a big word, and it's often confusing and used in many ways. But think you have a graph data structure. Okay? And you have the entities and relationships, but you want to apply some control over them. Or you want to be able to make inference over them. So, for example, there are some terms in this technology called RDFS: domain and range. So if I say, "Teaches has a domain of teacher," that means if I say, "Bob teaches scooter," in my text, I can infer that Bob is a teacher. And if I say, "All teachers are persons," then this statement lets me know if I say, "Bob teaches scooter," now I know Bob is a person. Bob is a teacher. What about scooter? If I say, "Teaches has a range of student," that means theright side of the verb, then scooter is a student. And now I have this extra information into my system. OWL also has a series of properties that allow you to make some inferences. So a transitive property. Transitive property says, "If Sue is an ancestor," like ancestor is a transitive property. "If Sue is an ancestor of Mary, and Mary is an ancestor of Anne, then Sue is an ancestor of Anne." Okay? This was not initially into my graph system, but with applying these functional properties, I can then add and augment the system with this extra data. So that's very useful. Then there are some properties called functional properties, which means only one. So "has father" is a functional property. You can only have one father. You can only have one mother. That is a functional property. Okay? So that can serve as a constraint. So when— if you say, "Bob is Jim's father, BB is Jim's father," well, the inference here is that Bob and BB are two ways of representing the same individual. Because that is a functional property. You can only have one. So these derivations and constraints don't sit in the graph. They sit sort of on the side. ### Agents & Loops **Frank Coyle** [12:09] And they can help, as we're going to see, I'm going to propose, when we deal with agents, how they can help us out. So what about agents? Everybody's talking about agents now, and everybody's talking about loops. Loops, loops, loops everywhere. Loops have been around for a long time. Back in the '60s, people were debating, "Who has the best programming language? Fortran or COBOL?" "No, mine is better." "No, mine is better." "Oh, you don't know anything. You don't know what you're talking about." Beam and Jacopini, in 1966, came out and said, "Okay, there is no real difference in programming languages if they have three aspects." Sequence. I can put statement A, statement B, statement C. Fine. I have conditionals. I can have if, then. And the last piece, I have a loop. If I have a loop, if I have iteration, if I take these three things, the language is what's called Turing complete. Can do any— can compute anything that can be computed by computational devices, from the work of Alan Turing. Okay? And now we're seeing this in agentic AI. Agents now have loops. Loops give us the last piece in the equation of giving us a technology that is capable of doing anything that computational devices can do. The danger, though, of loops is that they can break. If you're a programmer, you know you're going to infinite loop. Not good. Loops can drift. As agents start talking to each other, things go off the rails. And loops can cost you money. Token counts crank up as the loops continue. So you need to be careful. Okay? But in a way, we are revisiting some of the early stuff with symbolic AI. I would argue we're going back to the world of expert systems, which is the symbolic part of the whole thing. So I want to show you an example using Claude agent. So a little code here. Don't get scared. But I know nobody does Python anymore, but you got to look at what the agent's giving you, and you got to move in and manipulate it. ### Claude Loop **Frank Coyle** [14:39] So here's a loop while true, classic Python loop. Okay? And so we have a client. So we're actually— so the first little chunk here that you see, RESP, the response. This is just some code where we have a model, and we have a prompt that's part of the messages. And we have a tool. And we're asking the LLM to solve this problem using a tool. Now, here's the catch. LLMs can't do anything. All they can do is give us the next word with a high probability. Amazingly, we can now have these conversations with it, but they can't do anything. But we can give it a tool, and we can give it what we want and say, "How do you think this tool can help us get what we want?" And then the LLM will set up the parameters and come back to us and say, "Okay, here's my response. I can't execute this tool, but I know what the input parameters are. I know what your context is. I know what your prompt is. So here is the call that you need to make of the tool." Because I can't do it. I'm the LLM. I'm just locked in this box. Okay? So the second chunk is stop reason. So stop reason means the LLM has stopped for some reason. The reason here is that it can't do anything. And if the reason is tool use, "Ah, now it's time. Let's go execute that tool." So that second line, get tool, it takes the response, which is formulating the parameters and triggering the action. Okay. Now, there's stuff in red here. This is where I think the LLMs and other— I'm sorry, not LLMs. The ontologies and stuff can come in. So if you look down there, after the tool is called, it said, "Tool runs." This is where ontologies could come in. The tool's going to give us information. We put the information in a form that our validator can use. And think about the validator as operating with these ontologies about our domain. Then we can make some sense of whether the response of the LLM is reasonable. So this is the loop. Call a tool. Check the stop reason. If it's a reasonable result, then let's go with it. If it's not reasonable, go back to the LLM. Say, "Oh, this is not working." Or get a human in a loop. But the idea is ### Pydantic Guard **Frank Coyle** [17:43] to surround the input with checks. Now, I've got this— something that you should be at least taking a look at if you're doing some of this coding is something called Pydantic. Pydantic is a way to specify the types of what you want the types of the parameters to be. Those of you who know Python, know Python is an unstructured type language. So you can have a variable, x equals 20, x equals hello, no problem. There's no typing. Pydantic adds typing to that. So you want to check your types with Pydantic and then check your results with the ontology. So Pydantic at the door, ontology at the ledger, and pure agents. By the way, your agents should try to have no side effects. That helps the whole logic. Meaning they're not running off doing something that they're changing things in the database, not yet. You want to run them through the ontology first and make sure that works. Okay. I only got an— I've got another— it's just a short time. I'm going to try to show you some of the things that you can— some logical constructs from something called OWL, the ### OWL Errors **Frank Coyle** [18:59] web object language for objects. So you have these functional properties, disjoint properties. I'll just put these— you can look at the slides. But essentially, the errors it can catch, look over in theright-hand column. A second refund on the same order is a problem. Ontologies could catch it. Whereas it's very tricky to do that in English. A payout sent to the support desk instead of the buyer. Okay? You can catch that with an OWL disjoint property where customer and support rep are two separate entities. Okay? One of a made-up value like probably shipped. You can specify you must have certain kinds of value. So the status: paid, shipped, or refunded. Nothing else. And when you're in the pure text world, this can get funky because the LLMs are, again, probabilistic and return some crazy stuff. Okay. So really, the point I want to make here is use these— you can have a reasoner built on ontology to check, keep the LLM on track, have guardrails to keep it honest. Okay? And for the guardrails, I'm referring to these concepts, these support technologies with RDFS and OWL. ### Conclusion **Frank Coyle** [20:29] And my bottom line is nothing is a mistake. There's no win, no fail, only make. Okay. Feel free to reach out to me, Coyle at Berkeley. I've got a little website, codesupreme.ai. I'm a big fan of— if you're John Coltrane, has some jazz called Love Supreme. So I've named my site Code Supreme. And if you go there, I've got some music, and it's all good. Okay. Thanks very much. 20 minutes. --- This library is powered by PodHood (https://podhood.com), the podcast website platform.