Whoever Owns Your Ontology Owns Your Agents

The industry agrees that agents fail for lack of context. The harder questions are who defines it, how it changes, and what it costs to leave.

Ask two AI agents the same question: “How many active customers do we have?” One answers 41,200. The other answers 38,750. Neither is wrong. The first counted anyone who logged in during the last ninety days, which is how the product team defines “active.” The second counted accounts with a paid invoice this quarter, which is how Finance defines it. Neither said which definition it used, and both sounded certain.

The scenario is illustrative, but anyone who has sat through a reconciliation meeting will recognise it. What has changed is who reads the number. When a dashboard disagreed with a spreadsheet, someone noticed and picked up the phone. An agent does not pick up the phone. It acts on the number.

The diagnosis is settled

Over the past six months, vendors and analysts have converged on one explanation for confident wrong answers: the missing ingredient is context, not reasoning. Snowflake’s Christian Kleinerman was unusually candid about the problem when he spoke to VentureBeat in June: “you get a very confident answer, but whether it’s correct or not is different.” Gartner’s Rita Sallam argued in May that “context with semantic coherence will become a cost-control and trust strategy, not a nice-to-have,” and in October Gartner listed AI context platforms among its top strategic technology trends for 2027.

The platforms have moved accordingly. Snowflake launched Horizon Context and Cortex Sense, Microsoft made Fabric IQ generally available with ontologies to follow, Databricks put Agent Memory into beta in October, and Google added Knowledge Catalog on 4 November. The message is the same in each case: give agents governed business context and they will stop guessing.

The diagnosis is right. Retrieval had already stripped away the aggregation that once hid small data errors; meaning is the next safety margin to go. A dashboard fixed one definition inside each measure. An agent assembles its answer from whatever definitions it can find.

Where I part company with the current conversation is the cure. The market is treating context as a product to buy. I think it is better understood as a liability to manage, and that leads somewhere different.

Meaning is plural, and it moves

The instinctive response to conflicting definitions is to choose one and make it canonical. Governance teams have pursued that goal for two decades, and it fails for reasons that have little to do with discipline. Definitions differ because functions differ. Finance recognises revenue when it is earned, Sales counts it when it is booked, Operations when the order ships. In a hospital group, “patient” means one thing to clinicians, another to billing and another to research. Software architects have long had a name for this, bounded contexts, and data mesh was built on the same premise. None of it is new.

What is new is the reader. An analyst moving between Finance and Sales knew the contexts existed and translated between them without being asked. An agent knows only what the context layer tells it, and a single canonical ontology tells it there is only one meaning. You get consistent answers and lose the more valuable question of why two functions disagree. The most useful insight often sits in exactly those gaps between domains, and flattening them removes it before any agent has a chance to notice.

That does not mean everything should stay plural. Some numbers must be single: anything that goes to a regulator, an auditor, a lender or the board. The rule I would propose is simple. Canonical where the number leaves the building; plural where it informs a decision. Inside that boundary, plurality has to be governed. Each definition has an owner, a scope and a precedence rule, and every agent answer states which definition it used. “41,200 active customers (Product definition, 90-day login)” is a better answer than a bare number, because it turns a hidden conflict into visible metadata.

Meaning also varies over time, and this is the dimension most likely to go unnoticed. Companies redefine “active,” restate revenue after an acquisition, or split “customer” into two terms. In a BI estate, the change was visible because someone had to rebuild the report. In an agent estate, one definition serves many open-ended questions, so a change can spread without the data team in the room. Some of this year’s products make that easier, not harder. Snowflake’s Cortex Sense infers definitions from usage, Google describes Knowledge Catalog as learning from user behaviour, and agent memory accumulates by design. Each is useful, and each can change what an agent “knows” without anyone approving a release. One practitioner publication put the underlying problem well: an ontology is most accurate the day it ships. I have found no independent data on how often silent definition drift occurs, so this is reasoning rather than measurement. But the mechanism is plain, and the remedy is the one software learned long ago: versions, effective dates and a release process.

Context is stickier than data

The second issue is commercial. Data is getting easier to move. Google’s new cross-cloud lakehouse is built on Apache Iceberg, and analyst Donald Farmer observed that Google “no longer expects customers to bring their data into BigQuery.” When data can live anywhere, what holds a customer to a platform is increasingly the context around it. Snowflake’s own blueprint for an agent context layer lists six components: a semantic model, an ontology, operational playbooks, policy and entitlements, provenance, and decision memory. Read that as a business owner would. It is not metadata. It is a written record of how your company decides things.

Lock-in is not automatically a mistake. Integrated platforms do remove integration work, and Constellation Research’s Michael Ni made precisely that case for Google’s release. Every serious platform decision trades some freedom for speed. The mistake is lock-in that nobody has priced. The portability effort deserves credit: the Open Semantic Interchange, renamed Apache Ossie in July and now in the Apache Incubator, defines a vendor-neutral format for metrics, dimensions and relationships, with more than fifty organisations involved. But it is incubating, and what I have read of it describes the format of definitions, not how playbooks, entitlements or decision memory would travel, nor how definitions change. Even for Databricks’s Agent Memory, which keeps memories in the customer’s environment, one analyst noted that portability across a full agent fleet has yet to be shown in production.

The real exit cost is not moving definitions anyway. It is re-validating every agent that depended on them. Data moves with a pipeline. Meaning has to be rebuilt and then proven again, agent by agent.

Own the test, not just the layer

This brings me to the point I think matters most for architects. If accuracy, drift and portability all come down to whether an agent gives the right answer under the right definition, then the most valuable asset is not the context layer. It is the set of questions you use to test it.

Evaluation teams will recognise the idea as a golden dataset. The difference is who owns it and what it is tied to. A business-owned golden question set holds a few hundred real questions the organisation asks, each with its expected answer, the definition and version that answer depends on, and the person who signed it off. That one asset does three jobs no vendor can do for you.

It lets you judge context platforms on your own estate rather than on vendor benchmarks, which matters because every headline accuracy figure in this market is self-reported, from Google’s roughly fourfold improvement to Databricks’s threefold gain in completed tasks. It catches drift, because when a definition changes, the affected questions fail before users notice. And it makes exit credible, because a test set you own can be run against any platform. Farmer made the same point about Google: customers need to see, for each task, what the agent used, whether the answer was right and what it cost. The golden question set is how you check that yourself.

Architecturally, this implies two contracts. Every agent answer carries an envelope stating the definition, its version and its effective date. And every definition change runs against the question set before release, with a record of what changed, who approved it and which agents it affects.

Context debt

Taken together, these describe a third kind of debt, alongside the data debt and rules debt I wrote about in August. Context debt is the gap between the meaning your business runs on and the meaning your agents can find, trust and carry elsewhere. It compounds quietly, because every new agent inherits the ambiguity and adds its own interpretation. It can also be measured: the share of agent-consumed terms with a named owner, the number of terms with competing definitions and no precedence rule, the share of agent answers that state their definition and version, and the share of your golden questions you could run on another platform tomorrow.

A useful first test takes an afternoon. List the ten terms your agents use most and ask four questions of each. Who owns the definition? How many definitions exist? Which one does each agent use? Could we export it tomorrow in a form another system could read? The answers will say more about your agent readiness than any accuracy demo.

For technology leaders, the agenda that follows is short. Assign owners to meanings, not just to tables, and expect most of those owners to sit in the business. Decide explicitly which numbers are canonical. Build the golden question set before selecting a context platform, not after. And price the exit before you sign. IDC’s Devin Pratt says enterprises need a context layer “that’s governed, portable, and trustworthy enough to audit.” An accuracy demo tests none of the three.

What comes next

Gartner expects regulators to demand more semantic transparency and boards to treat semantic governance as a strategic risk. Those are predictions, and I hold them loosely. The underlying shift is harder to dismiss: once an agent’s answer can move money or change a record, “which definition did it use, and who approved it?” stops being a data question and becomes an accountability question.

In August I wrote that models are increasingly rentable by the token, and that what cannot be rented is the ability to answer a plain question about any output. Meaning belongs on the same list. The question for your next planning cycle is not which platform has the best context layer. It is whether, when the contract ends, your enterprise still knows what its own words mean.

Key takeaways

  • The industry has the diagnosis right: agents give confident wrong answers mainly because they lack governed business meaning. Treat context as a liability to manage, not a product to buy.

  • Canonical where the number leaves the building, plural where it informs a decision. One ontology for everything erases the cross-functional disagreements that carry insight.

  • Meaning changes over time, and inferred or self-learning context can change it without a release. Definitions need versions, effective dates and a release process.

  • Data is becoming portable; context is not. Lock-in is acceptable only when it is priced, and the real exit cost is re-validating every agent.

  • Own the test, not just the layer. A business-owned golden question set, tied to definitions and versions, checks vendor claims, catches drift and makes exit credible.

For further queries, please reach out to

Ask The Expert

Accelerating business clockspeeds powered by Sage IT

Share this blog, choose your platform!