As AI moves from answering questions to taking action, enterprise data needs something it has often lacked: shared, operational meaning.
For years, the enterprise data challenge has largely been about access. Can we bring the right data together? Can we govern it? Can people find it? Can applications query it? Can analytics teams turn it into useful insight?
Agentic AI changes the problem.
Agents do not simply retrieve predetermined data through predetermined queries. They interpret requests, decide which information is relevant, reason across that information and, increasingly, act on the conclusions they reach.
In the HTEC work behind this point of view, that distinction is important: people and pipelines have largely operated through deterministic retrieval and explicit mappings, while agents introduce probabilistic interpretation and can write the results of that interpretation back into the system.
That introduces a fundamentally different requirement. It is no longer enough for an AI system to have access to enterprise data. It has to understand what that data means.
This becomes more important as enterprises move from AI systems that answer questions towards systems that are entrusted with decisions and actions. The more autonomy we give AI, the more precisely we need to define the business world in which it operates.
That is one reason ontology has become such a prominent topic in enterprise AI. The underlying argument is straightforward: agents taking action need some shared definition of the entities, relationships, rules, and context that constitute the business around them. But that does not mean every organization suddenly needs a large enterprise ontology. In fact, we think that is the wrong place to start.
The problem is no longer just retrieval
Traditional enterprise data systems operate within relatively deterministic boundaries. A dashboard uses known metrics. An application reads predefined fields. An integration maps one system to another. An analyst knows, or can investigate, what a particular field or measure represents.
Agents operate differently because interpretation becomes part of the execution path.
Consider a seemingly simple request:
“Book this patient with the right provider next week.”
The word “right” carries a significant amount of implicit business meaning. It could involve qualifications for a procedure, insurance coverage, location, availability, or the rules governing a particular care pathway. A person familiar with the organization may understand much of that context implicitly. An agent does not.
Yet the agent may still produce an answer.
The issue becomes more serious as AI gets closer to action. An agent interprets what somebody wants, determines what information to retrieve, makes a decision based on what it finds and potentially takes an action. An assumption introduced during interpretation can therefore influence retrieval. That retrieval influences the decision, and the decision determines the action. If the result is then written back into another system or consumed by another agent, the consequences of the original interpretation can travel further.
Our current thinking describes this as the spread: the range of possible answers and actions that the same request can produce when the system lacks sufficient grounding. Each additional layer of semantic grounding can narrow that spread.
This is where a data problem becomes a trust problem.
The question is no longer simply whether the model can produce the right answer. The more important question is whether we understand the conditions under which we can trust the system to take the next action.
That is where semantic layers, knowledge graphs, ontologies, rules and inference become much more interesting. Not as an abstract exercise in data architecture, but as mechanisms for creating sufficient context around an AI system for us to trust what it does.
The answer isn’t “ontology everywhere”
There is a strong argument for giving agents richer business context. There are equally legitimate reasons to be cautious about how that context is created.
The outside-in research we have reviewed reflects both sides. Proponents argue that ontologies can represent business entities, relationships, rules, constraints and context in ways traditional data models cannot. Critics point to the cost, skills requirements, maintenance burden, rigidity and delivery risk associated with large ontology programs. There are also concerns around ontology drift and vendor lock-in.
The evidence around outcomes is also less mature than some of the current enthusiasm might suggest. Much of the quantified evidence on either side comes through vendors or consultancies with a commercial interest in the debate, while independent evidence of return on investment remains limited.
For us, that leads to a pragmatic conclusion. The question should not be whether an enterprise “has an ontology.” The question should be how much meaning a particular AI system requires in order to operate reliably.
Metadata may be enough in one case. A governed vocabulary or semantic layer may be sufficient in another. Some problems require the richer understanding of relationships that a graph introduces. Others may justify an ontology, explicit rules, and inference.
The architecture should reflect the problem, rather than the problem being forced to justify the architecture.
This is also broadly where the debate appears to be settling. The more pragmatic approaches favor incremental development, guided by real requirements, rather than attempting to model an entire enterprise before value can be demonstrated.
Minimum Viable Meaning
We think there is a useful principle behind that approach: Minimum Viable Meaning.
Instead of beginning with the question, “How do we model our enterprise?”, begin with a much narrower one:
What does this agent need to understand to perform this particular task reliably?
That shifts the discussion away from ontology as an objective in itself.
For a given use case, we need to understand which entities the agent must recognize, which relationships matter, which definitions cannot be ambiguous, what rules constrain the decision, and what evidence should exist before an action is allowed. Only then should we determine the semantic architecture required to provide that context.
Just as importantly, we should be able to test whether adding that context actually improves the behavior of the agent.
The principle is therefore relatively simple: use the lightest semantic architecture capable of making the agent sufficiently trustworthy for the decision or action it needs to make.
In some cases, that may involve ontology. In others, it may not.
The distinction matters because the objective is not to build the richest possible representation of the enterprise. It is to provide enough governed meaning for an AI system to operate reliably.
Build from the decision backwards
This reverses the way large knowledge initiatives have often been approached.
Rather than first attempting to model the enterprise, populate that model and then find applications for it, we believe it makes more sense to start with a decision or action that matters.
From that action, work backwards.
What does the agent need to understand to make the decision? Which business entities and relationships create that understanding? Which rules or constraints cannot be violated? What semantic architecture is necessary to represent them? How should those elements be used to ground the agent? And finally, does the resulting system behave measurably better?
That approach is consistent with the pragmatic direction identified in our outside-in review: build incrementally around real requirements rather than starting with a large enterprise-wide program.
Put simply:
Don’t model the enterprise before you know what the agent needs to understand.
This changes ontology from a modelling destination into an operational capability that can evolve alongside AI use cases.
It also creates a much clearer connection between investment in semantic infrastructure and the business outcome it is supposed to improve.
From ontology as an artefact to meaning as infrastructure
An ontology sitting in isolation has limited value. The more interesting opportunity is to make enterprise meaning operational by connecting business definitions, relationships and rules to the AI systems that need to interpret and act upon them.
That distinction shapes how we are approaching the subject at HTEC.
Our objective is not simply to claim “ontology expertise.” We are working towards an engineering discipline for determining how much meaning an AI system needs, deciding how that meaning should be represented, connecting it to agentic systems and evaluating whether doing so improves behavior.
And importantly, we are building that capability through implementation rather than claiming that the problem is already solved.
The current HTEC program includes work around a domain-agnostic architecture, domain reference builds, ontology and knowledge management, validation concepts, a router designed to select components according to complexity, evaluation of different platform approaches, engagement frameworks and internal applications. It also includes work to evaluate and mature existing domain models rather than assuming those assets are already ready to deploy.
The distinction between what exists today, what is being built and what the target capability should become is deliberate.
There are already plenty of claims being made around ontology. We think evidence will ultimately be more valuable.
The next question is whether it actually changes agent behavior
This is why we believe the next stage of the ontology conversation needs to become much more empirical.
Take a real business problem and build an agent around it. Understand how that agent behaves with the context available today. Then introduce the appropriate definitions, relationships, domain models, rules or ontology and evaluate what changes.
Does the agent become more consistent? Are its decisions easier to explain? Does it adhere more reliably to business rules? Does it deal with ambiguity more effectively? Does the additional semantic grounding give the organization enough confidence to allow the agent to do more?
These are much more useful measures than whether an organization can claim to possess an ontology.
This evidence-led approach is reflected in HTEC’s current program. The work includes grounded agent proofs of concept using semantic layers and/or ontology, alongside an internal project intended to build practical experience with Databricks Genie Ontology in private preview.
The objective is not to prove that ontology “works” in the abstract. It is to establish where richer semantic grounding materially improves agent behavior, what level of grounding is required, and where additional complexity does not justify itself.
This is the opportunity we see with Databricks
For us, this is what makes the conversation with Databricks interesting.
The question is bigger than whether a particular ontology technology works. The more consequential question is how enterprise meaning becomes operational within agentic AI.
Answering that requires data, domain context, semantic modeling, and agent engineering to come together around real enterprise decisions. It also requires a willingness to measure what actually changes when additional semantics are introduced.
HTEC’s ambition is to develop repeatable patterns for doing exactly that: start with a high-value agentic use case, determine the level of semantic grounding required, implement it, evaluate the resulting behavior and use the evidence to inform what comes next.
Our current program already identifies grounded proofs as a concrete goal, including work involving Databricks Genie Ontology.
The opportunity is therefore not simply to tell enterprises that ontology matters. It is to build evidence about where it matters, how much is enough and what changes as a result.
Meaning is becoming infrastructure
The first generation of enterprise AI was largely concerned with giving models access to information. The next challenge emerges when AI begins to participate more directly in how businesses operate.
An AI system that retrieves an imperfect answer creates one category of risk. A system that interprets the business incorrectly and then acts on that interpretation creates another.
As autonomy increases, meaning therefore becomes more important.
Not because every enterprise suddenly needs an ontology, and not because ontology should become the next major architecture program by default.
It matters because AI systems entrusted with decisions need more than access to data. They need a sufficiently accurate representation of the business world in which those decisions are being made.
The sensible response is to build that understanding incrementally, around real decisions and at the level of semantic richness the problem actually requires.
Start with the action and work backwards to the meaning. Introduce the semantic structure that the use case requires. Measure what changes. Expand when the evidence justifies it.
That is how we believe ontology can move from an interesting architectural concept to useful infrastructure for agentic AI.
And it describes the path HTEC is taking not claiming that ontology is solved but building a repeatable way to make enterprise meaning operational for AI.
