One Ontology or Many? What Survives Contact with Production Agents

A buyer asked us this recently, in almost exactly these words: “We are choosing between one enterprise ontology and per-use-case ones. Which actually survives contact with production agents?”

It is the right question, asked at the wrong altitude. Neither answer survives on its own. An ontology exists to satisfy the business needs you have today and the ones you can see coming. It is not a hammer looking for a nail. If one ontology serves those needs, build one and keep it small. If several serve them better, build several, and build them from the first day to interoperate, to endure change, and to travel to another team, another agent, or another platform. The pattern matters less than whether the result passes six tests that production agents apply whether you planned for them or not.

This guide covers why the question is back, what each pattern buys you, the six tests, the shape that passes all of them, and how we support both patterns at Fluree.

Why is this question back?

Because an agent is the first consumer of an ontology that reads the definitions directly, crosses several domains inside one task, and acts on the result with nobody in between.

Every earlier consumer had a person in the loop. A dashboard had an analyst who knew that “active customer” on the finance report meant something different from “active customer” in the CRM. An integration had a developer who wrote the translation. The reconciling happened in someone’s head, slowly, and the cost of ambiguity was paid in meetings.

An agent pays that cost in the moment. Juha-Pekka Joutsenlahti of Solita described the failure in a May 2026 piece on ontologies as the missing guardrail: an agent that has “silently decided ‘revenue’ means gross when finance means net will pass every behavioural guardrail you have.” It is authorized, rate limited, and logged, and it is wrong in a way no filter catches.

The analysts have caught up with the practitioners. In Gartner’s May 2026 release on semantics and agent accuracy, Rita Sallam predicted that organizations that prioritize semantics in AI-ready data will raise agentic AI accuracy by up to 80% and cut costs by up to 60% by 2027, and said that “context with semantic coherence will become a cost-control and trust strategy, not a nice-to-have.”

That is why the ontology question moved from the data team to the buying committee. It is no longer a modeling preference. It decides whether an agent can be trusted to act.

Haven’t we fought this before?

Yes, three times, and each time the monolith lost to a small shared core, local autonomy, and explicit contracts at the seams.

Stefan Tilkov’s 2015 verdict on the canonical data model, in his INNOQ post on why you should avoid one, still reads well: “It’s a horrible, horrible idea. Don’t do it.” His description of what such models become is the part to remember: “tons of optional attributes because everyone insisted theirs need to be there.” The software world’s answer was the bounded context. Each context keeps a model that fits its job, and the boundaries carry explicit translation.

Data mesh reached the same answer for data. Jesús Barrasa of Neo4j, in a July 2026 post on the enterprise knowledge layer, called federated ownership of meaning “the same lesson data mesh learned about data, now applied to meaning itself.”

Ontology engineering never needed to learn it. Nicola Guarino’s 1998 paper “Formal Ontology and Information Systems” already distinguished top-level, domain, task, and application ontologies. The buyer’s either/or is a choice the field resolved before most of us had email.

What does one enterprise ontology buy you?

One answer to “what is a customer,” which is exactly what an agent needs when it crosses domains, at the price of consensus, scope, and lock-in.

The case for one model is strongest where agents span domains. Palantir’s product documentation states it plainly in its guidance on ontologies: “Working with other teams is not a reason to create a second ontology.” Stephen Kaufman of Microsoft, in a May 2026 CIO article on ontologies as an architecture asset, made the agent argument directly: if “customer” means different things in sales, finance, and support, “the AI will confidently act on the wrong interpretation.” His placement is the one we agree with most: “your ontology belongs in the data layer, not the AI layer.”

Notice how small the one model is in practice. Semantic Arts describes gist, its upper ontology for the enterprise, as “around 100 classes and about the same number of attributes and relationships.” Dave McComb’s case for an enterprise ontology recounts an integration that used “46 classes and 36 properties out of the several hundred in the enterprise ontology.” The people who have shipped one enterprise ontology did not boil the ocean. They found the small shared core and left the rest to the edges.

The costs are real. Consensus is the first. Palantir’s own list of ontology anti-patterns names the failure it fights hardest: department silos, where “each department creates their own version of shared entities.” Getting departments to agree on what a customer is surfaces disagreements that table sprawl let everyone avoid.

Scope is the second. Nimisha Asthagiri of Thoughtworks wrote in a June 2026 piece on why ontologies fail that “an enterprise-wide master model is just the boil-the-ocean trap with a tidier name.” Kurt Cagle and Chloe Shannon added the modeling objection in a May 2026 essay on upper ontologies: “You cannot have both precision and universality in the same artefact.” Every domain class has to fit the hierarchy, so, in their words, “you will always be forking it.”

Lock-in is the third, and it is the one buyers underweight. Tony Seale, in a June 2026 post on the agentic web, offered the test: “If your ontology cannot leave the platform that created it, it is not your ontology in any durable sense.”

What does one ontology per use case buy you?

Speed and clear ownership, at the price of forked meaning that compounds every time an agent crosses a boundary.

The case for starting local is the case for shipping. Atlan’s guidance, in its 2026 framework for ontology design, is to “pick one domain, not the enterprise,” and its authors note that most enterprise ontology projects stall “not because the modeling is wrong but because the scope is.” Ananth Packkildurai, in an August 2026 Data Engineering Weekly essay, gives the sharpest version: “Do not begin by modeling the enterprise. Begin with one decision an agent must explain or execute.”

There is a deeper argument too. Domains sometimes disagree for good reasons, and a model that forces them to agree lies about the business. Nicolas Figay, in an August 2026 post on vocabulary-first versus formal-first modeling, argues for keeping several domain ontologies and stating their overlaps as equivalence mappings, because “equivalence is not agreement.” It is a machine-checkable statement that two things remain distinct in their own domains.

The costs show up the day a second agent needs the first agent’s terms. Barrasa’s warning is the one we hear most from prospects: “Build that meaning into each agent and you create multiple private copies of the enterprise; copies drift.” Joutsenlahti’s follows from it. Agents run dozens of queries across domains in one workflow, and “each domain boundary they cross is another silent interpretation.”

The quieter cost is that “start with one use case” is a sequencing decision, not an architecture. Everyone in this camp expects to expand domain by domain. Expansion without a shared core is how a company arrives at twelve definitions of customer, each one correct somewhere.

What survives contact with production agents?

An ontology that serves the business questions you have and the ones you can see coming, built so that it interoperates, endures change, and can travel. The pattern is secondary. These six tests are not.

We run every ontology plan through the same six tests. They come in three pairs, one pair for each property that decides whether a model is still useful in three years.

The evidence behind the tests is not theoretical. On the change test, Tian Pan documented in a June 2026 post on tool version drift a renamed status field that an agent adapted to without complaint; six weeks later, wrong “out of stock” replies had crept up from two percent of queries to eleven. His summary: “Agents break quietly.” On the collision test, Krista Davis of Salesforce showed in a November 2025 post on structural and descriptive ontologies that “active customer” has three plausible definitions inside one company. On why meaning matters at all, Juan Sequeda, Dean Allemang, and Bryon Jacob found in their November 2023 benchmark on knowledge graphs and LLM accuracy that GPT-4 answered enterprise questions over raw SQL with 16% accuracy and over a knowledge-graph representation of the same data with 54%. Fluree’s April 2024 study, GraphRAG for GenAI Accuracy, found the same pattern on a different corpus.

Now score the two patterns. One big model passes the cross-domain test and, if it is versioned with its data, the change and replay tests. It fails the exit test whenever it lives inside one platform, and it fails the slice test by size: a model with thousands of classes cannot be handed to an agent whole. One model per use case passes the slice test by accident and fails the cross-domain and collision tests by design. Its change and replay results depend on whether anyone owns it after the project ends.

The shape that passes all six is a governed core with use-case extensions:

• A core, kept small and owned like a product. It holds identity, meaning one identifier per real-world thing, and the concepts every domain shares: party, product, location, agreement, event, time, document, and your own top ten. The one-ontology camp’s numbers are the guide. About a hundred classes is a core. Adopt existing standards for the parts that are not yours.
• Extensions per use case that import the core. An extension subclasses a core term, adds properties, adds constraints, and adds rules. It never redefines a core term locally. A pricing agent’s “eligible account” is a subclass of the core’s account, not a second account.
• Mappings at the seams, stored as data. Where two domains legitimately disagree, the disagreement is written down as an equivalence or a narrower-than relation, versioned like everything else, so an agent crossing the boundary can check it rather than guess.
• All of it as data. The definitions live beside the facts they describe, carry the same history, and are served to each agent as the slice its permissions allow.

One rule keeps the core small and the extensions honest. A term moves into the core when two agents write to it, when it gates an action that cannot be undone, or when a second use case asks for it. Until then it stays local. That is the whole promotion policy, and it means the core is discovered from real use rather than designed in a workshop.

Is this one ontology or many? It is both, which is why the buyer’s dichotomy dissolves. There is one namespace of identity and shared meaning, and there are as many governed extensions as the business has decisions worth automating.

How do you run this without a two-year program?

Start with one decision an agent must make, model only what that decision needs, and promote into the core only what a second use case asks for.

1. Write down the questions, present and future. List the questions agents must answer next quarter and the ones you expect in two years. The first list scopes the first extension. The gap between the lists is your roadmap, and it is the only honest way to judge “existing and future business needs” instead of modeling for its own sake. Asthagiri’s advice applies: make competency questions the funding gate.
2. Adopt before you author. Person, organization, location, time, document, and provenance are solved by open standards. Spend your modeling effort on the concepts that make your business different.
3. Version the core like software. Owners, release notes, deprecations, and a test suite, which is the competency questions rerun on every release. Jessica Talisman, in her March 2026 refresh of the ontology pipeline, put the reason in one line: “the day an ontology is deployed is the day it starts to drift.”
4. Give business owners the pen, with review before publish. Taxonomists and domain experts should propose terms in their own language and see changes held until they are approved. Our guide From Taxonomy to Governed Ontology walks through that path step by step.
5. Keep the seams explicit. Every mapping between two vocabularies is a record with an owner, a type, and a version, never a line in a prompt.
6. Score the plan quarterly against the six tests. The score is the health metric. A falling score on the change test means drift; a falling score on the slice test means agents are receiving copies.

Teams that work this way have a first governed use case live in four to eight weeks, and the second one is faster, because it inherits the core.

Where does Fluree fit?

Fluree supports both patterns because the ontology, the data, the policies, and the history live in one governed graph, and because many ledgers can be governed by one and queried as one.

We built FlureeDB to store an ontology as data, not as a file beside the data. Its documentation describes the consequence directly: Fluree stores ontology declarations as regular triples in your graph, so the schema evolves with the data, is time-travelable, and is subject to the same policy controls. That single design decision is what lets the same database serve a company that wants one ontology and a company that wants several. Here is how it lines up against the six tests.

Interoperability. A query can span several ledgers at once: the documentation states that Fluree supports SPARQL datasets, “enabling queries across multiple graphs and ledgers simultaneously,” with joins on shared identifiers across them. Equivalences are handled as equivalences, not as duplicates. With reasoning switched on for a query, facts about two identifiers declared the same are merged under one canonical representative. Mappings between vocabularies live as data in the graph, and Fluree’s taxonomy and ontology management records them as typed, scored mappings between vocabularies rather than tribal knowledge.

Durability. Because definitions are triples in the same immutable ledger as the facts, every change to the ontology is a commit you can diff, and any past state can be queried by transaction, by timestamp, or by commit. A policy or a definition can be tested on a branch and merged when it passes. Vocabulary changes are held until they are reviewed and approved, and multiple versions live side by side. The replay test becomes a query: ask the graph what “active customer” meant on the day the agent acted, and rerun the agent’s question under that definition.

Portability. Everything is expressed in W3C standards: RDF, JSON-LD, OWL, SHACL, and SPARQL. The ontology can leave, with identifiers any standards-based system can resolve. The slice test is where the many-ledger design pays off. One model ledger holds the shared schema, the constraints, the policies, and the rules; any number of data ledgers reference it and add their own. In the documentation’s words, “a single model ledger can hold governance artifacts that govern many data ledgers that reference it.” Each agent connects over MCP, asks for the data model it is allowed to see, and gets answers under its own identity. The documentation puts the permission model in one sentence: the same query returns different results to different identities. In Fluree AI, the hosted platform, every workspace is an MCP server, and write-capable tools are withheld from an agent until a human clears them.

We have run both patterns with customers. A Global 500 consumer goods company needed one product ontology, and the durable result was that new sources, new analytics, and new AI agents classify against the same model instead of starting over. A government biodiversity department needed many vocabularies under one governance regime, with version control and a full audit history across ontology changes, plus sensitive-species access rules applied by design. A global beauty brand needed reusable ontology patterns to reach new markets and use cases without rebuilding. Three businesses, three shapes, one set of survival properties.

If you are weighing this decision now, bring us the two use cases whose definitions disagree. We will show you the core they already share, the extensions each one keeps, and what it takes to pass all six tests on your data.