$cat why-agentic-systems-need-ontologies.md

Why Agentic Systems Need Ontologies

August 16, 202617 min readby MDflowview as .md

A diffuse cloud of emerald particles passing through a precise wireframe lattice gate and emerging as ordered nodes snapped onto a grid, on a dark terminal-grid background

Somewhere around 2023 the agent loop quietly acquired the last piece of the structured program theorem. Böhm and Jacopini showed in 1966 that sequence, selection and iteration are enough to compute anything computable. Agents had sequence and conditionals from the start. When we gave them loops, we handed a probabilistic text generator a Turing-complete execution environment and wired it to production APIs.

Frank Coyle, who has been teaching computer science for about 35 years and now does so at UC Berkeley, made exactly this point at AI Engineer in July 2026, and then made the uncomfortable follow-up: loops break. They spin forever, they drift as agents talk to each other, and they burn tokens the whole time. The fix he proposes is not a better prompt. It is the oldest branch of AI, brought back on purpose.

TL;DR — An agent loop is Turing-complete and probabilistic at the same time, which is a combination no type checker fully covers. An ontology — a formal description of your domain's entities, relationships and constraints — gives you a symbolic layer that can reject a second refund on the same order or a status of probably shipped before the tool call executes. That is neuro-symbolic AI, and the hard part is not the reasoner but authoring and maintaining the shared conceptualization it reasons over. MDflow is a markdown workspace where that prose half lives — definitions, allowed values and the reasoning behind each constraint — readable by every agent over MCP and an HTTP API, versioned, and attributable to the token that wrote it.

What is an ontology, in agent terms?

An ontology is a formal, machine-checkable description of a domain: the entity types that exist, how they relate, what properties they carry, and what must always be true of them. The definition everyone quotes is Tom Gruber's, from 1993 — an explicit specification of a conceptualization — usually cited in its refined form, a formal specification of a shared conceptualization. That last phrase is the one that matters for agents. You are handing the machine your organization's view of its own universe.

The lineage is older than the software. Aristotle wanted a philosophy of being and produced categories of it; Willard Van Orman Quine formalized the question of what a theory commits you to existing. Graph databases arrived when people noticed that relational tables were too rigid to hold that kind of model: adding a new fact meant adding a column and reworking the schema, whereas in a graph you attach another node, another property, another edge.

You do not have to invent one. There are mature public vocabularies that models have already seen in training:

schema.org — entity types and relationships for the open web
Dublin Core — descriptive metadata for documents and publications
FOAF — people and social relationships
DBpedia — structured knowledge extracted from Wikipedia

Reusing an existing vocabulary is not just cheaper to author; it is cheaper for a model to reason over, because the terms are already in its priors.

The part that does the work

The graph holds facts. The interesting machinery sits beside it, in RDFS and OWL, and it comes in two flavors.

Inference derives facts you never stated. In RDFS, a property has a domain and a range: declare that teaches has domain Teacher and range Student, and the single statement Bob teaches Scooter yields three more — Bob is a teacher, Bob is therefore a person, Scooter is a student. OWL adds property characteristics: ancestorOf is transitive, so Sue → Mary → Ann collapses into Sue → Ann without anyone writing it down.

Constraint rejects facts that cannot be true. OWL's functional properties mean at most one: hasFather is functional, so if the graph says Bob is Jim's father and BB is Jim's father, the reasoner does not shrug — it concludes Bob and BB are the same individual, or that something is wrong. Disjoint classes say two categories cannot overlap: nothing is both a Customer and a SupportRep.

For validating data rather than reasoning about it, the modern tool is SHACL, a W3C recommendation since 2017. The distinction is worth internalizing because it decides which one you reach for. OWL is open-world: what is not stated is unknown, not false. SHACL is closed-world: it treats the graph in front of it as complete and reports violations against declared shapes. Agents mostly want SHACL semantics for gating an action and OWL semantics for enriching what they know.

Why agentic systems need ontologies

Because a language model cannot do anything, and that turns out to be the whole security model. The model emits a stop reason of tool_use along with the parameters it thinks the call needs. Your code executes it. Everything between those two moments is yours to control — and today, for most systems, that gap contains nothing but a JSON schema check.

Coyle's framing of what belongs in the gap is the most portable idea in the talk: Pydantic at the door, ontology at the ledger. A type validator confirms the shape of the arguments. An ontology confirms that the action means something legal in your domain. They catch different failures, and only one of them is currently standard practice.

Consider three errors that pass every type check ever written:

The agent proposes	Why it type-checks	What catches it
A second refund against an order already refunded	Valid order ID, valid amount	Cardinality: one refund per order
A payout routed to the support representative handling the ticket	Valid party ID, valid amount	Disjoint classes: `Buyer` and `SupportRep` do not overlap
Setting an order's status to `probably shipped`	It is a string	Enumerated values: `paid`, `shipped`, `refunded` — nothing else

Every one of these is trivially expressible in an ontology and awkward to express in English in a system prompt, where it competes for attention with everything else and degrades probabilistically. And the third one is not a hypothetical — a hedged, plausible-sounding value is precisely the artifact a probabilistic generator produces when it is unsure.

The corollary Coyle draws is a design rule: agents should have no side effects until validation passes. Propose, validate, then act. Run the proposal through the reasoner while it is still just a proposal, because after the API call the refund exists.

For developers

You get a failure surface that is inspectable. When an ontology rejects a call, you have a named violation against a named constraint — not a vague sense that the model got confused. That difference shows up immediately in on-call: sh:in violation on Order.status is a bug report, while "the agent set a weird status" is an investigation.

You also get a place to put business rules that is neither the prompt nor scattered if statements. Rules in prompts are non-deterministic and invisible to tests. Rules buried in handler code are deterministic and invisible to everyone else. A declared constraint is both checkable and readable.

And there is a measured argument for the whole approach. Ontology-Constrained Neural Reasoning in Enterprise Agentic Systems (Thanh Luong Tuan, Golden Gate University, and Abhijit Sanyal, Novartis, April 2026) ran 1,800 trials across five industries and three models, and found significant improvements in metric accuracy, role consistency and regulatory compliance from ontological grounding. Its most interesting result is an inverse parametric knowledge effect: Vietnamese-language domains improved roughly twice as much as English ones. Ontological grounding is worth most exactly where the model's pretraining coverage is thinnest — which is to say, in your proprietary domain, not in the public web the model already memorized.

For AI agents

An ontology gives an agent something a prompt cannot: a stable referent. When an agent reads Customer, it is not inferring a meaning from context and vibes; it is resolving a defined type with declared relationships and constraints. Multi-agent systems benefit disproportionately, because the failure mode there is two agents using the same word for different things and neither noticing.

It also gives the agent a legitimate way to be wrong. A validator that rejects a proposal and explains why is a retry signal. The loop becomes: propose, validate, on failure return the violation to the model with the constraint it broke, try again, and escalate to a human after N attempts. That is a far better control structure than hoping the next sample is better, and it is the same shape as the verification loop that makes AI-written code trustworthy.

Which applications benefit most

Financial and transactional agents — refunds, payouts, ledger entries, anything where a duplicated or misrouted action costs real money and cannot be quietly retried.
Regulated process automation — healthcare, insurance, pharma, public sector. Neuro-Symbolic Agents for Regulated Process Automation (Rombach, Lauer and Mehdiyev, June 2026) argues these domains structurally require symbolic constraint reasoning, because compliance and explainability are not satisfiable by a probabilistic component alone.
Enterprise data and analytics agents — where "revenue" means four different things in four systems and the agent has to pick the right one.
Multi-agent systems — a shared ontology is the cheapest way to stop agents from silently disagreeing about vocabulary.
Long-running autonomous agents — the ones most exposed to loop drift, where a constraint violated on step 40 compounds through step 400.
Agentic coding and infrastructure — environments, ownership and dependency relationships are already a graph; making it explicit is what lets an agent reason about blast radius.

The objection: didn't this already fail?

Yes, twice, and pretending otherwise would be dishonest.

Expert systems were going to be AI in the 1980s. Companies formed, budgets were spent, Japan launched the Fifth Generation Computer Systems project. Then the systems could not scale — every rule was hand-authored, every edge case a new rule, and the maintenance burden outran the value. The AI winter followed. Neural networks had been sitting there since the 1960s, unable to scale for their own reason, until GPUs built for video games turned out to be the missing hardware.

The Semantic Web repeated the pattern in the 2000s. The standards were sound. Authoring and maintaining the ontologies was the part that did not happen.

The reason to revisit it now is that the bottleneck was always authoring, and authoring is what language models are good at. The bottom-up path Coyle describes — watch what actually happens, extract entities and relationships, add them to the graph — is a task you can hand to a model over real traffic. This is the genuinely new element in 2026: the symbolic layer does not have to be hand-built by a committee of domain experts before it is useful.

It is not free. As the Latent Space discussion of this revival puts it, maintenance is still the open problem, and the proposed answer — agents that maintain their own ontology, updating definitions when they hit edge cases — needs a human review step or you have simply moved the drift somewhere less visible. Neo4j's Emil Eifrem separates ontologies into three kinds worth keeping distinct: business-facing concepts, technical metadata, and execution traces from runtime. They rot at different rates and need different owners.

How MDflow fits

MDflow is not a graph database and not a reasoner. It does not run OWL inference, evaluate SHACL shapes or hold RDF triples. Neo4j, GraphDB, Stardog, Oxigraph and your reasoner of choice do that, and if you need mechanical enforcement you should use one.

What MDflow holds is the half of an ontology that is prose, and that half is where these projects usually die. A formal ontology encodes that Buyer and SupportRep are disjoint. It does not encode why — that the classes were separated after an incident in March, that a contractor is modeled as a SupportRep even though they invoice like a vendor, that the exception everyone asks about was considered and rejected. That reasoning is what makes an ontology maintainable, and it is what a triple store has no place to put.

What already lines up today

A written domain vocabulary is the version most teams should build first. Entity definitions, allowed status values, invariants, and the reasoning behind each one, in markdown documents every agent can fetch. It is not enforcement, and it should not be sold as enforcement — but putting the same definitions in front of every model call removes a real class of error, and it is the artifact that makes a later formal ontology cheap to author instead of a greenfield project.

Folder descriptions are declared intent. Every folder carries a description of what belongs in it, and mdflow_get_context ranks those descriptions above folder names and document titles before returning matching bodies. A folder described as "Canonical domain vocabulary — one document per entity type, with allowed values and the invariants that must hold" is a retrieval signal you wrote deliberately, which is why folder descriptions beat file names.

Markdown is the native unit, with a raw twin for machines. Every document is also served as a plain .md endpoint with YAML frontmatter, so a sandboxed validator can fetch the current definition of Order.status over plain HTTP with no client library — which matters when egress is allowlisted.

Version history is how a definition survives being changed. Every saved change on every write path captures the previous version, with line-by-line diffs and non-destructive restore. When a constraint stops matching reality you can see exactly when it changed and revert it. It is deliberately Pro, private to the document owner, and not exposed over the API or MCP — an agent cannot quietly rewrite the record of its own edits.

The Document Log answers "which run proposed this?" A cross-document activity feed records created, edited, shared and deleted events with the actor on every row, shown as automated · <token name> for anything arriving through the API or MCP. Give each loop its own Personal Access Token and you know which extraction pass proposed which definition change.

Every runtime reads the same workspace. The same documents are reachable from Claude, ChatGPT, Cursor and Codex over the remote MCP server with OAuth or a Personal Access Token, and from cron, CI, an orchestration DAG or n8n over the HTTP API — plus a local stdio server, a VS Code extension and an iOS app. The extraction job that proposes a new entity type at 03:00 and the domain expert reviewing it on a phone are looking at the same document.

Proposed changes become reviewable checkboxes. /tasks aggregates ordinary - [ ] lines from every markdown body, so "confirm whether contractors should be modeled as SupportRep" written by an autonomous pass becomes something a person can prioritize and tick off, with the document remaining the source of truth.

Where we are headed

Direction, not a dated commitment. Two things about this use case interest us. The first is richer structured retrieval over folder descriptions, so an agent asking "what does refunded mean here?" reliably lands on the one canonical definition rather than the three most lexically similar documents. The second is narrower agent credentials: a Personal Access Token today reads and writes everything its owner owns, which is enough for attribution but is not least privilege — and an extraction pass proposing vocabulary changes on a schedule is exactly the case that wants a token scoped to one folder. Neither turns MDflow into a reasoner, and that is deliberate.

The bottom line

The agent loop gave us Turing completeness on top of a probabilistic generator, and the industry's answer so far has mostly been better prompts and a JSON schema. Ontologies are the other half — a symbolic layer that can say no for a reason it can name, before the side effect happens. Pydantic at the door, ontology at the ledger.

The technology is thirty years old and the standards are stable. What killed it twice was the cost of writing and maintaining the shared conceptualization, and that is the part that changed: models can now do the extraction, provided a human still reviews it and something durable records the reasoning. Start with the vocabulary written down where every agent reads it. Add the reasoner when the constraints are worth enforcing in code.

Start free · Connect an AI agent · Read the API docs

Frequently asked questions

What is an ontology in the context of AI agents?

An ontology is a formal, machine-checkable description of a domain: the entity types that exist, the relationships between them, their properties, and the constraints those must obey. The definition usually quoted comes from Tom Gruber in 1993 — an explicit specification of a conceptualization — later refined to a formal specification of a shared conceptualization. For an agent, it is the written-down version of what your organization means by customer, order, refund and shipped, in a form a program can check rather than a form only a person can read.

Why do agentic systems need ontologies?

Because an agent loop is Turing-complete and probabilistic at the same time. The model proposes tool calls that are statistically plausible, but plausible is not the same as permitted, and nothing in a language model has a deterministic notion of your business rules. An ontology gives you a symbolic layer that can reject a second refund on the same order, a payout routed to a support representative instead of a buyer, or a status value like probably shipped — before the tool executes and the side effect becomes real.

What is neuro-symbolic AI?

Neuro-symbolic AI combines a neural, probabilistic component such as a large language model with a symbolic, rule-based component such as a knowledge graph, an ontology and a reasoner. The neural half generates and interprets; the symbolic half constrains and verifies. In an agent, the practical form is a validation step between the model proposing a tool call and the system executing it, where the proposal is checked against declared types and declared domain rules.

What is the difference between OWL, RDFS and SHACL?

RDFS and OWL are inference languages under an open-world assumption: they let you derive new facts, such as inferring that Bob is a teacher because he teaches someone, or that two names refer to the same person because a property can only have one value. SHACL, a W3C recommendation since 2017, is a validation language under a closed-world assumption: it treats the data you have as complete and reports violations against declared shapes. Agents generally want SHACL-style validation for gating tool calls and OWL-style inference for enriching what they know.

Do you need a graph database to get value from an ontology?

No. The first useful step is usually a written domain vocabulary — the entity types, the allowed status values, the invariants and the reasoning behind each one — kept somewhere every agent and every engineer reads. That document is what makes an eventual formal ontology cheap to author and possible to maintain, and it catches a surprising number of errors on its own by putting the same definitions in front of every model call. Formal reasoning over RDF, OWL or SHACL is the layer you add when the constraints are worth enforcing mechanically.