We Build Ontologies. We Just Don't Let Them Die

Everyone in enterprise AI is building ontologies. The question isn't whether to build one. It's whether yours will still be accurate in six months.

There's a new consensus forming in enterprise data: AI agents need ontologies. Knowledge graphs. Semantic layers. Context graphs. The terminology shifts depending on which vendor you're talking to, but the pitch is the same — formalize your business knowledge into a structured representation, feed it to your agents, and watch the magic happen.

As a result, most enterprise data and AI practitioners now have a working definition of an ontology. A structured model of the concepts in a domain — what things exist, how they're described, how they relate to each other — encoded in a form that machines can read and reason over. That part of the conversation is largely done.

The harder part is the method the industry has been selling for how to build one.

When vendors make the case for enterprise ontologies, they almost always reach for the same proof points. Gene ontology was constructed over more than twenty years by thousands of researchers, cataloging how genes interact and what biological processes they participate in, and is now one of the most comprehensive knowledge models ever built. SNOMED CT, encoding over 350,000 clinical concepts, was hand-curated piece by piece through decades of collaborative scientific work. These are genuine achievements. And the industry's message, implicit in every pitch deck, is: do this for your business.

It's the wrong blueprint.

Those ontologies succeeded for a reason that rarely gets acknowledged: the knowledge they encode doesn't move. A gene's behavior doesn't get redefined after a quarterly business review. A clinical diagnosis doesn't shift when the company enters a new market. The researchers who spent 20 years building the gene ontology had a luxury that no enterprise has: the subject matter stayed still while they worked.

Ask yourself whether your organization has twenty years and thousands of domain experts available to build and maintain a comparable model. Then ask whether your business definitions would stay stable long enough for the effort to matter.

The industry has drawn a straight line from what the bioinformatics community built to what enterprise AI needs. That line is broken. And the teams who follow it faithfully are discovering the gap not at the whiteboard, but in production — when the ontology they spent months building has already stopped reflecting how the business actually works.

What the market gets wrong about enterprise ontology

Google just launched Knowledge Catalog. Palantir has been building their Ontology since 2012. Snowflake is exploring ontology patterns. Jessica Talisman wrote a widely shared piece arguing that ontologies are fundamentally different from semantic layers and that AI demands the former. Even MotherDuck weighed in, arguing that LLMs can discover the semantic layer from query history alone.

Everyone has an opinion. Almost nobody is talking about what happens on day thirty.

Here's the thing: we agree that you need an ontology. The relationships between your business entities, the definitions that give data meaning, the governance rules that determine what's trustworthy — all of that is essential context. Without it, agents hallucinate. With it, they reason.

But here's what we've learned building this at enterprise scale: the ontology you ship on day one is already drifting by day thirty. The business changed. A metric got redefined. A table got deprecated. A team reorganized. And if your ontology can't keep up, you don't have a knowledge system. You have a snapshot that's slowly becoming fiction.

The real question isn't whether to build an ontology. It's how to build one that stays alive.

The ontology everyone agrees on (and its hidden problem)

Let's give credit where it's due. The industry is right that AI agents need structured business context — not just raw schemas, but meaning. Relationships. Governance. Trust signals.

Gene Ontology has powered bioinformatics for 20+ years. SNOMED CT has 350,000 clinical concepts and millions of relationships. Palantir's Foundry Ontology models entire organizations as digital twins — object types, properties, link types, action types. These are extraordinary achievements.

But here's the part the ontology evangelists leave out: those ontologies serve domains where the underlying knowledge changes slowly. "Myocardial infarction" meant the same thing in 2006 as it does in 2026. Gene pathways don't reorganize quarterly.

Your enterprise is not like that. Your definition of "active customer" changed three times last quarter. Your revenue recognition rules shifted when you entered a new market. Your data warehouse has four tables with "revenue" in the name and only one of them is right — and which one depends on who's asking.

The ontology is the right idea. The static ontology is the wrong implementation.

Three approaches, one missing piece

The industry has split into three camps on how to build business context for AI. All three get something right. All three are missing the same thing.

Camp 1: Build a formal ontology from scratch. This is the Palantir model, the academic ideal. Define your entities, properties, relationships, and inference rules using formal knowledge representation — RDF, OWL, or proprietary equivalents. The intellectual rigor is real. So is the problem: it requires knowledge engineering skills most data teams don't have, takes months to build, and has no built-in mechanism to detect when it's drifted from reality. The ontology is most accurate the day it ships. After that, it's a maintenance liability.

Camp 2: Let LLMs discover the ontology from usage. This is the MotherDuck thesis. Jacob Matson argued compellingly that "the semantic layer is not a static definition problem, but rather a search problem." Mine query history. Let LLMs discover patterns. Use AI skills — modular packages of domain context — that evolve over time.

It's a smart insight. Query history is an underutilized signal. But it has a blind spot: query history tells you what people have asked, not what changed yesterday. It encodes existing knowledge and existing biases. It doesn't capture the metric that was redefined this morning, the table that was certified last week, or the policy that changed after an audit. It's a rearview mirror. Powerful, but incomplete.

Camp 3: Aggregate everything into a knowledge catalog. This is Google's play with Knowledge Catalog. Aggregate metadata from everywhere — BigQuery, Looker, partner catalogs, semantic models. Enrich it continuously with LLM-powered extraction. Deliver it to agents through high-precision semantic search.

It's architecturally sophisticated. But read the fine print: it's still fundamentally about assembling context. Aggregation. Enrichment. Search. What happens when the assembled context is wrong? When a definition drifted and nobody noticed? There's no self-correction mechanism.

The missing piece in all three: none of them answer the question, "What happens when the ontology is wrong, and how does it fix itself?"

Ontology as context: Why this changes everything

Here's the insight that reframes the entire debate: an ontology delivered as context to an LLM is fundamentally more powerful than an ontology queried through a graph database.

Traditional ontologies are built for SPARQL queries and graph traversal. They're rigid, formal, and optimized for machine reasoning through predefined inference rules. That's powerful in stable domains.

But LLMs don't need RDF triples to reason. They need context — rich, natural-language-accessible descriptions of what things are, how they relate, what's trustworthy, and what's changed. Feed an LLM a well-structured ontology as context, and it can reason about your business in ways that formal graph queries never could. It can handle ambiguity. It can synthesize across domains. It can adapt to questions nobody anticipated when the ontology was designed.

This is the paradigm shift: the ontology isn't the query engine. The ontology is the context layer that makes the LLM smart.

And when you think about ontology as context, the design constraints change entirely:

The ontology doesn't need to be complete on day one — it needs to be improvable. It doesn't need formal inference rules — it needs rich, accurate descriptions that LLMs can reason over. It doesn't need to anticipate every question — it needs to capture the relationships and governance that make answers trustworthy.

Most importantly, it needs to stay current. Because stale context fed to a powerful LLM doesn't produce "no answer." It produces a confidently wrong answer. And that's worse than no ontology at all.

Feedback loops: How we build ontologies that don't decay

At Alation, we build ontologies. We build them as living context — and we keep them alive through feedback loops.

This is not a metaphor. It's an architecture with two concrete mechanisms:

Feedback loops above the catalog. When agents interact with users — whether those agents run natively on Alation or on external platforms like Snowflake Cortex, Databricks Genie, or any MCP-connected system — the system captures what worked and what didn't. User corrections, failed queries, ambiguous questions that exposed a definition gap. Those signals flow back into the catalog and update the ontology. The context improves from use.

We run structured evaluation cycles where failures are diagnosed, metadata is updated, and the agent is re-tested. Each cycle compounds accuracy. We've seen agents climb from roughly 60% accuracy on initial deployment to 90%+ through systematic feedback — the exact trajectory depends on the domain and data quality, but the compounding pattern is consistent. And critically, this works regardless of where the agent is built. The feedback loop improves the ontology-as-context, which improves every agent that consumes it.

An ontology without a feedback loop is a snapshot — accurate on the day you build it, drifting every day after. An ontology with a feedback loop is a living system. Every agent interaction is a chance for the context to get smarter. Every correction compounds. That's the difference between a demo and a production system.

Data quality monitoring below the catalog. Feedback loops catch errors at the top — when agents and users interact. Data quality monitoring catches degradation at the bottom — when the raw data itself goes stale. Freshness, completeness, conformance to business rules. When a table's data quality degrades, that signal propagates up through the ontology to every data product and agent that depends on it — before any agent builds an answer on top of it.

Together, these two mechanisms create what most ontology architectures lack: an ontology that improves from the top (through agent feedback) and is validated from the bottom (through data quality), continuously, without requiring a dedicated maintenance team.

The ontology doesn't rot. It compounds.

Why static ontologies break at enterprise scale

Let's be specific about where the traditional approach fails — not because ontologies are wrong, but because static ontologies are wrong for enterprises.

The knowledge engineering bottleneck. Building a formal ontology requires skills most data teams don't have — formal logic, knowledge representation, taxonomy design. As Jessica Talisman correctly noted, "metric definition and ontology engineering are fundamentally different disciplines." But the answer isn't to staff an army of knowledge engineers. It's to build an architecture where the ontology improves through use, so you don't need an army to maintain it.

The completeness trap. Formal ontologies reward completeness. The more entities, relationships, and inference rules you define, the more powerful the system. But completeness is the enemy of agility. Every relationship you formalize is another thing that can drift when the business changes. Past a certain point, more formalization creates more maintenance burden than value. An ontology built as context for LLMs doesn't need to be complete — it needs to be accurate where it matters, and the feedback loop tells you where it matters.

The platform lock-in problem. Palantir's ontology only works inside Palantir. Google's Knowledge Catalog is optimized for GCP. If your ontology only powers agents on one platform, it's a product feature. If it powers agents across platforms — through context that any LLM can consume — it's an architectural advantage.

What we actually build

Let's be transparent about our architecture, because the honest version is more useful than the marketing version.

Alation's Federated Knowledge Graph uses ElasticSearch to power the discovery and context layer. We enforce schema constraints at the metadata ingestion pipeline level — through data stewardship workflows, policy enforcement, field-level governance, and trust flags. We connect tables, schemas, metrics, glossaries, lineage, and governance across your entire data estate.

Is this a formal ontology in the W3C sense? No. It's something more useful: an ontology built as context that LLMs can reason over, kept alive by feedback loops that capture what agents learn and write corrections back automatically.

The knowledge representation format matters less than you think. What matters is whether the context is accurate, whether it's accessible to LLMs, and whether it self-corrects when the business changes. RDF triples that are six months stale are less useful than natural-language context that was corrected yesterday through agent feedback.

If your organization requires strict W3C-compatible ontology validation for a specific use case — clinical data, regulatory compliance, interoperability standards — we want to understand that use case and map the right solution. Ines Chami, who brings deep expertise in knowledge representation from her research at Stanford, can work through the architectural tradeoffs with your team.

But for the vast majority of enterprise AI use cases, what you need isn't a more formal ontology. What you need is an ontology that stays alive.

Four questions to ask any vendor

The next time someone pitches you an ontology, a knowledge graph, a knowledge catalog, or a context engineering platform, ask these four questions:

1. When the business changes and context drifts, how does your ontology detect it and correct it without manual intervention?

If the answer involves "a team that maintains the ontology," ask how many people that team requires and how many use cases they can support simultaneously. You're measuring whether this is an architecture or a staffing plan.

2. When an agent gets an answer wrong, does the system diagnose which piece of context failed and write the fix back automatically? Show me the mechanism.

Ask for a demonstration, not a description. Anyone can describe a feedback loop. Very few can demonstrate one.

3. Does this work for agents built on external platforms?

If the ontology only powers agents on their platform, it's a product feature. If it powers agents across platforms — Snowflake Cortex, Databricks Genie, custom MCP agents — it's an architectural advantage.

4. Is the ontology designed as context for LLMs, or as a formal graph to be queried?

Ontologies built for SPARQL are powerful in narrow domains. Ontologies built as context are powerful everywhere — because LLMs can reason over rich context in ways that graph queries can't.

The bottom line

The industry is right: AI agents need ontologies. They need structured business context that captures entities, relationships, governance, and trust signals.

But the debate over how to represent that ontology — RDF vs. property graphs vs. knowledge catalogs vs. semantic layers — is a distraction from the question that actually determines whether you succeed in production: does your ontology stay accurate as the business changes?

We build ontologies at Alation. We build them as a living context that LLMs can reason over. And we keep them alive through feedback loops that compound accuracy over time — from the top, through agent corrections, and from the bottom, through data quality monitoring.

The ontology is the right answer. The feedback loop is what keeps it right. And delivering it as context is what makes LLMs powerful over it.

Build the ontology. Wire the loops. The rest compounds.

Alation is the enterprise data intelligence platform trusted by 600+ organizations worldwide. To learn more about how living ontologies power accurate AI agents, visit alation.com.