The short version

Reliable agents need clear owners of meaning

The problem is not that enterprises lack business definitions. It is that the same meaning is often defined in too many places.

Most enterprises already have a semantic architecture. They just did not design it as one.

Humans learn how to navigate this. Agents expose the cost of it.

Reliable agents require clear ownership of meaning, not more copies of it.

In this article

What you will learn

• why duplicated business meaning becomes a bigger problem for AI agents
• what belongs in the semantic layer
• what belongs in an ontology
• when a knowledge graph adds value
• how to avoid creating three competing sources of truth
• where data teams should focus first

Duplicated meaning

The same concept is defined in too many places

Revenue logic lives in BI tools. Customer definitions live in warehouse models. Relationships are encoded in transformation pipelines. Application teams maintain their own terminology. Important rules survive in documentation or institutional knowledge.

When an agent encounters several definitions of the same concept, it has to decide which one applies. When relationships are implicit, it has to reconstruct them. When business logic is duplicated across systems, it has to determine which version is authoritative. That is the wrong place to resolve enterprise meaning.

Consider one real-world entity.

• The CRM calls it an Account.
• The ERP calls it a Customer.
• Legal refers to a Counterparty.
• A risk system may call it something else again.

Each system can be internally correct while the enterprise as a whole remains semantically inconsistent.

The same happens with metrics. Revenue may have one definition in finance, another in sales reporting and a third embedded inside an operational application.

For people, this creates friction. For agents, it creates ambiguity at runtime.

A model can infer from names, descriptions and examples. But if the organization has never decided which interpretation is authoritative, better inference does not solve the underlying problem.

A business question should resolve to the same governed meaning whether it is asked by a person, an application or an AI agent.

Achieving that means giving different kinds of meaning a clear home, not putting every kind into one giant model. The practical question for data teams is what each should own, rather than whether to adopt a semantic layer, an ontology or a knowledge graph.

Analytical meaning

Put it in the semantic layer

A semantic layer for AI agents should own the definitions required to interpret enterprise data consistently. That includes:

• Business entities: What do we mean by Customer, Product or Contract?
• Metrics: How is revenue calculated? What qualifies as active ARR?
• Dimensions: How should those metrics be analyzed?
• Relationships: Which analytical relationships should be consistently reusable?
• Authoritative sources: Which data should be used when several representations exist?

The outcome is consistency. If an agent is asked:

Which customers have contracts renewing next quarter, what revenue is exposed and which products are affected?

the semantic layer should already know what Customer, Renewal and Revenue mean. The agent should not discover the calculation from transformation code or infer the correct source from table names.

What the semantic layer should not become

It should not become a dumping ground for every possible business relationship or rule. A semantic model can tell an agent how Customer relates to Contract for analytical purposes. That does not mean it should also carry every role, hierarchy, equivalence and constraint that exists across the enterprise.

Eventually, analytical semantics reach a boundary. That is where ontology starts to matter.

Business structure

Put cross-domain structure in the ontology

Some questions are less about metrics than about what kinds of things exist and how they can relate.

• A reseller may also be a customer.
• A renewal may be a type of commercial event.
• A legal entity may simultaneously be a supplier and a customer.
• A subsidiary may belong to a parent organization.
• Certain relationships may only be valid for particular classes of entity.

These are not simply analytical definitions. They describe the structure of the business. An ontology gives those concepts, relationships and rules a governed representation.

The semantic layer standardizes analytical meaning. The ontology standardizes business concepts, relationships and rules. That distinction keeps both layers useful.

For our recurring example, the semantic layer:

• defines Customer
• defines exposed Revenue
• defines Renewal
• identifies authoritative sources

and the ontology states that:

• Customer signs Contract
• Contract contains Product
• Product belongs to Product Category
• Renewal is a Commercial Event
• Legal Entity can play the role of Customer

The ontology should not recalculate revenue. The semantic layer should not become the enterprise’s universal class system. Clear ownership matters more than architectural purity.

Connected instances

Use a knowledge graph only when you need it

Once concepts and relationships are explicit, another question appears: should the organization materialize those relationships as a knowledge graph? Sometimes. Not always.

A relational platform can answer many relationship-based questions perfectly well. The existence of relationships does not automatically justify a graph architecture. A knowledge graph becomes useful when traversing connected instances is itself an important part of the workload.

Consider extending our question:

Which customers have contracts renewing next quarter, what revenue is exposed, which products are affected, and which parent organizations ultimately own those customers?

Now the agent may need to navigate: Parent Organization → Customer → Contract → Product → Revenue

The ontology defines what those relationships mean. The knowledge graph, if used, contains the actual relationships:

• Acme Group owns Acme Belgium
• Acme Belgium signs Contract C-10482
• Contract C-10482 contains Product P-410

That gives us a useful separation:

The graph is not the meaning. It is one representation of instances connected by governed meaning.

Three sources of truth

Put meaning in the lowest governed layer

This is where semantic architectures often go wrong. A team introduces a semantic layer. Another team builds an ontology. A third builds a knowledge graph. Then all three redefine Customer, all three model the same relationship, and all three become places where business logic can drift.

Nothing has been solved. The organization has simply moved semantic inconsistency higher up the stack.

A better rule is:

Put meaning in the lowest appropriate governed layer, then reuse it above.

• If a definition is fundamentally analytical, govern it in the semantic layer.
• If it describes a cross-domain concept, class or rule, govern it in the ontology.
• If it describes an actual relationship between real entities, materialize it where that relationship needs to be queried.

Do not copy logic upwards just because another technology can represent it.

The ownership model

• Semantic layer owns interpretation: metrics, analytical entities, dimensions, commonly used relationships and authoritative sources.
• Ontology owns conceptual structure: classes, roles, hierarchies, equivalence, constraints and cross-domain relationships.
• Knowledge graph owns connected instances: actual entities and their instantiated relationships where graph representation improves the workload.
• Agents own orchestration: they consume these governed structures. They should not redefine them.

That separation makes the architecture easier to operate and easier to trust.

Do you need all three?

Start with the smallest layer that removes the ambiguity

A good architecture removes the ambiguity your use cases actually encounter; it is not the one with the most layers.

Start with the semantic layer when

Your agent needs governed answers about:

• revenue
• margin
• pipeline
• inventory
• customer activity
• operational KPIs

For many analytical agents, this may be enough.

Add ontology when

The agent needs to reason across:

• different roles for the same entity
• multiple business domains
• class hierarchies
• equivalent concepts from different systems
• rules governing valid relationships
• business concepts that outlive individual applications

Add a knowledge graph when

The workload depends on:

• deep relationship traversal
• ownership networks
• fraud networks
• supply-chain dependencies
• complex product structures
• contextual investigations

The principle is simple: do not add a layer because the technology exists. Add it when it removes a specific ambiguity or makes a required query materially easier.

Where should data teams focus first?

Six steps, in order

The first task is to understand where meaning is duplicated today, before selecting any ontology platform.

1. Find competing definitions. Identify business concepts and metrics with several active interpretations. Customer and revenue are obvious places to start.
2. Assign ownership. Decide where each definition should live. Do not allow the same business rule to become independently authoritative in multiple layers.
3. Formalize the semantic core. Start with the entities, metrics and relationships behind the highest-value agent use cases. Do not try to model the enterprise in one pass.
4. Identify the ontology gap. Look for concepts the semantic layer cannot express cleanly: roles, classes, hierarchies, equivalence and cross-domain rules. Only model the ones agents actually need.
5. Materialize relationships selectively. Use graph representations where relationship traversal creates clear value. Do not convert relational data into a graph simply because agents are involved.
6. Reuse what already exists. Mature platforms already contain useful source material: transformation models, metadata, documentation, lineage, tests, relationships and semantic definitions. Use those assets to accelerate the work. Human effort belongs on semantic decisions, not repetitive mapping.

Where does meaning belong?

Seven questions for your team

Ask these questions:

• Where is the authoritative definition of Customer?
• Where is Revenue calculated?
• Who owns cross-domain concept definitions?
• Are the same relationships modeled independently in several tools?
• Which rules still exist only in application logic or documentation?
• Which agent use cases genuinely require graph traversal?
• If a definition changes, how many places must be updated?

If the answer to the last question is “several,” the architecture still has a semantic ownership problem.

FAQ

What is a semantic layer?

A semantic layer is a governed layer that defines business entities, metrics, dimensions and relationships once, so every tool and every AI agent interprets enterprise data the same way. It owns analytical meaning. It does not need to own every concept, role or rule in the business.

What is the difference between a semantic layer and an ontology?

A semantic layer governs analytical interpretation, including entities, metrics, dimensions and commonly used relationships. An ontology models concepts, classes, roles, relationships and rules across a broader business domain. Neither replaces the other.

What is the difference between an ontology and a knowledge graph?

An ontology defines what kinds of things exist and how they can relate. A knowledge graph contains the actual connected instances, such as Acme Group owning Acme Belgium. The ontology supplies the meaning; the graph is one way to store and traverse what that meaning describes.

Can an ontology replace the semantic layer?

Usually not. Ontology and semantic modeling solve different problems. Metric calculations and analytical definitions still need a governed home.

Do AI agents need a knowledge graph?

Not necessarily. Many agent use cases can operate effectively over governed relational and semantic models. Knowledge graphs become useful when relationship traversal is central to the workload.

Can you build a knowledge graph without an ontology?

Yes. But without governed semantics, teams can represent similar relationships differently and create a connected dataset whose meaning is inconsistent.

Where should a business rule live?

In the lowest governed layer appropriate to its purpose. Analytical calculation logic belongs in the semantic layer. Conceptual constraints and cross-domain rules belong in the ontology.

Can existing data models be reused?

Yes. Existing models, lineage, metadata and documentation are often the best starting point. The aim is to formalize and reuse existing meaning, not recreate it.

Reliable enterprise AI does not require one enormous knowledge model. It requires every important piece of meaning to have one clear owner.

Earlier in this series: What Makes a Data Platform AI-Ready?

Next in this series: How to Make Snowflake AI-Ready Without Rebuilding Your Data Platform.

Contact us now to make your data AI-ready.