Ontologies: the persistence of business rules in the age of agents

I have argued here that the main purpose of Quality in software development is to ensure the persistence of business rules; well then, the rise of agentic systems — in which LLMs stop being conversational assistants and begin to execute complete flows, with decision loops and tool use — makes that thesis not merely current, but urgent.

To begin with, we need to understand the nature of the problem: an LLM is, by construction, probabilistic. It does not “know” the business rules of your domain; it estimates, with remarkably high statistical competence, which is the most likely next word. That is a feature, not a defect (it is precisely this nature that allows the flexibility we so celebrate). But it means that, in delegating decisions to agents, we are delegating decisions to a component that may, with disconcerting ease, approve a second refund for the same order, send a payment to the wrong recipient or create a delivery status that does not exist in the process (something along the lines of “probably shipped”).

This is where an old concept in new clothing comes in: ontologies. An ontology is, in Gruber’s classic definition, a formal specification of a shared conceptualization; in plain English, it is formalized domain knowledge — that is, the entities, relations, properties and constraints that describe what is valid in your business. A customer cannot simultaneously be the service representative who approves their own ticket; an order has exactly one payer; a status belongs to a closed set of values. None of this is conceptually new (the “categorization of being” has been with us for a good few centuries, and anyone who lived through the era of expert systems will recognize the kinship), but the role changes entirely: the ontology ceases to be documentation and becomes an active verification mechanism, a deterministic layer that validates, at each iteration of the agent, whether the probabilistic result adheres to the rules of the domain.

Note that this is, essentially, meta-quality applied to agents: it is not a matter of “who tests the agent”, but rather of applying the fundamentals of Quality (continuous verification, conformance, deviation analysis) to the agentic flow itself, at runtime. And there is a strategic consequence that strikes me as central: if AI accelerates the generation of code and of decisions, then code and decisions cease to be reliable repositories of business rules; the source of truth must migrate to formal, governed, verifiable artifacts. The ontology is a natural candidate for that role.

Returning to Fred Brooks: the essential complexities of the domain do not disappear because an agent executes the process; they need to be represented somewhere, and it is infinitely better that they live in a formal specification than scattered across prompts, generic user story descriptions or, worse still, in the memory of someone who one day leaves the project.

To decision-makers, an invitation to reflect: before asking “how many agents can we put into production this quarter”, ask “where is the domain knowledge that will keep them on the rails formalized”. The cost of answering the second question is orders of magnitude lower than the cost of discovering, in production, that no one ever asked it.