Semantic Models: Turning Enterprise Data Into Meaning for AI Agents
AI agents can access more enterprise data than ever. Semantic models address the harder problem: giving that data consistent, governed business meaning that agents can understand and use.
AI agents can access more enterprise data than ever. The harder question is whether they understand what that data means.
Your AI agent can read your enterprise data.
But does it understand what that data means?
Consider a seemingly simple request:
“Show me the total revenue from my active enterprise customers.”
A person familiar with the business may understand that immediately.
For an AI agent, the request contains several hidden questions.
What qualifies as an enterprise customer? What makes a customer active? What does my customers mean? And which calculation represents total revenue?
The answers probably exist somewhere in the enterprise. They may be encoded in data models, field descriptions, application logic, calculations, documentation, or simply understood by people who know the business.
But every AI agent should not have to rediscover that meaning independently.
This is where semantic models become important.
A semantic model provides a governed translation layer between the language of the business and the underlying enterprise data.
As enterprises move from applications that retrieve data to agents that interpret requests and reason over data, that layer of meaning becomes increasingly important.
Data Is Not the Same as Meaning
Enterprise platforms are very good at describing data structurally.
A CRM system might contain Customer Type, Status, Revenue, Owner, and dozens of related fields. Those fields may have excellent descriptions. Relationships may be documented. APIs may be well designed.
All of that is valuable.
But the agent still needs to understand that Enterprise Customer is a classification, Active represents a business definition, My Customers implies a particular relationship, and Total Revenue refers to a specific business metric.
The data tells the agent what exists.
Semantics helps explain what it means.
That distinction becomes very real when working with mature enterprise platforms.
In my experience, business concepts that sound obvious in conversation can require interpretation across classifications, relationships, fields, and application logic before they can be translated into data retrieval.
Take something as simple as “my customers.”
To a user, the phrase may seem unambiguous. But an enterprise system can support multiple legitimate relationships between a person and a customer. The challenge may not be finding the customer data at all. The harder problem can be determining which business relationship the user intended.
When a developer builds a deterministic application, that interpretation is usually encoded during design.
When an AI agent interprets the request dynamically, the distinction becomes much more consequential.
Metadata Is the Foundation, Not the Entire Meaning
Good metadata matters.
Object descriptions, field descriptions, data types, relationships, and API documentation make enterprise systems easier for both humans and machines to understand.
But business concepts frequently extend beyond a single field.
Think about terms such as Active Customer, Customer Relationship, Total Revenue, Customer Lifetime Value, or Qualified Opportunity.
Some may map cleanly to one field.
Others depend on classifications, multiple data points, relationships, calculations, or business rules.
That creates an important distinction:
Metadata describes the structure. Semantics describes the business meaning behind that structure.
Most enterprises already possess this meaning.
The problem is that it is often distributed across application code, automation, reports, dashboards, queries, prompts, documentation, architecture, and institutional knowledge.
That becomes increasingly difficult when multiple consumers independently reconstruct the same concept.
One agent may receive the definition of an Active Customer through instructions. Another may rely on logic embedded in an action. Analytics may implement a similar definition. A future agent may introduce yet another interpretation.
When the definition changes, the challenge is no longer simply changing the rule.
The challenge is discovering everywhere the meaning has been duplicated.
Enter Semantic Models
A semantic model makes important business meaning structured and reusable.
Instead of every consumer independently translating business terminology into physical data structures, the semantic model provides a common interpretation.
At a high level, a semantic model can contain several types of meaning.
Dimensions describe how data can be classified or analyzed, such as Customer Type, Customer Status, Industry, Region, or Product Category.
Relationships describe what connections between business concepts mean.
A technical data relationship might connect a Customer ID to an Account ID. The semantic relationship explains the business meaning of that connection, such as a customer owning an account.
The first describes how data connects.
The second describes what the connection means.
Measures represent numerical values such as Revenue, Balance, Quantity, Cost, or Margin.
Metrics bring those measures closer to business language, with concepts such as Total Revenue, Average Revenue, Customer Lifetime Value, or Conversion Rate.
The underlying data still resides in objects, fields, tables, and records.
The semantic model does not duplicate all of that data. It creates a business-oriented interpretation over it.
A semantic model is not simply another document describing the data. It is structured business meaning.
From Business Language to a Grounded Answer
Now consider the original question semantically:
- Enterprise Customer → Which customer classification?
- Active → What is the approved business definition?
- My Customers → Which business relationship applies?
- Total Revenue → Which governed metric should be used?
Once those meanings are understood, the actual data still needs to be retrieved.
The flow becomes:
Natural Language → Semantic Interpretation → Query or Action → Enterprise Data → Grounded Response
That is an important boundary.
Semantics does not replace execution. It gives execution a more consistent understanding of business intent.
The same distinction applies to APIs and reusable application services.
- Semantic model: What does this concept mean?
- API, service, or action: How do I retrieve it or execute it?
- Enterprise data: What is actually true?
- AI agent: How do I use the result to fulfill the user's intent?
I think of the distinction simply:
Reusable code centralizes execution. Semantic models centralize meaning.
That is why I see semantics as complementary to the architecture enterprises have already built, not a replacement for it.
Semantics Is Not the Entire Context
Semantic models are not the entire context an AI agent may need.
Agents may also need broader business and architectural context: why a process exists, how systems interact, what exceptions matter, which architectural decisions shaped the solution, and what constraints need to be respected.
This connects to an idea I explored earlier in Context Is the New System of Record: preserving business, functional, technical, operational, and decision context as reusable organizational understanding.
Semantic models complement that broader context by making selected business meaning structured and computationally usable.
I think of the distinction simply:
Data provides facts.
Semantics provides meaning.
Context provides broader understanding.
A semantic model does not need to contain every piece of business and architectural knowledge. Its value comes from making the meaning required for consistent data interpretation explicit and reusable.
Semantics Without Governance Creates Another Problem
There is an important caveat.
Centralizing meaning does not automatically make that meaning correct.
Someone still has to decide what Active Customer means.
Someone has to own the definition of Total Revenue.
And when those definitions change, there needs to be a way to govern those changes.
That raises architectural questions that are just as important as the semantic model itself:
- Who owns a semantic definition?
- Who is allowed to change it?
- How is a change reviewed and approved?
- How are definitions versioned?
- How are dependent consumers affected by a change?
- How do we prevent multiple definitions of the same concept from drifting apart?
Without governance, the semantic layer can eventually become one more place where meaning diverges.
A semantic model reduces ambiguity only when the semantics themselves are governed.
For AI agents, the consequences become more significant.
A duplicated definition creates inconsistency.
A centrally governed definition can improve consistency.
But a centrally managed incorrect definition can also distribute incorrect meaning broadly.
Centralization therefore increases the importance of ownership, traceability, and change control.
There is another boundary worth keeping clear:
Semantics defines meaning. It does not replace authorization.
Understanding what a customer, relationship, or metric means does not determine whether an agent should be allowed to access the underlying records.
Identity, permissions, sharing, data security, and execution controls remain separate architectural responsibilities.
This distinction matters as agent autonomy grows.
Semantics can help an agent understand what something means.
Governance determines whether that meaning is authoritative.
Security still determines what the agent is allowed to see and do.
Where Data 360 Fits
For Salesforce organizations, Data 360 provides a native path for applying these ideas.
Salesforce's Tableau Semantics provides business context over Data 360 and supports semantic definitions including dimensions, calculated dimensions, measurements, calculated measurements, relationships, logical views, and metrics. Salesforce describes Semantic Models as first-class Salesforce metadata integrated with Data 360.
Salesforce also provides semantic query capabilities. Its Semantic Metric Query API accepts metric-based requests against a Semantic Model, and Salesforce states that the Semantic Metric Query Generator translates the logical request into optimized SQL over Data 360 objects and executes it.
This creates an interesting opportunity for Salesforce architectures.
Instead of putting every interpretation into prompts, custom code, reports, or individual agents, selected business meaning can become part of a structured semantic layer that multiple consumers can use.
The broader principle, however, matters more than any individual implementation:
Critical business meaning should not have to be rediscovered independently by every AI agent.
Why This Matters for AI Agents
Traditional applications are largely deterministic.
Developers decide which data to retrieve, which relationships to traverse, which calculations to perform, and which APIs to invoke.
AI agents introduce a different interaction model.
Users increasingly express intent, and the agent must interpret that intent before determining which data and capabilities are relevant.
The flow increasingly becomes:
Natural Language → Business Meaning → Reasoning → Data + Actions → Outcome
The more autonomy we give agents, the more important that interpretation becomes.
If business meaning remains implicit, the agent must infer more.
If critical meaning becomes explicit and governed, the agent has a stronger foundation from which to reason.
Enterprise systems have spent decades making data structured, integrated, accessible, and API-enabled.
AI adds another requirement:
Understandable.
Giving an agent access to more objects, APIs, databases, and documents does not automatically create greater understanding.
Access answers:
What information can I reach?
Semantics answers:
What does that information mean?
And governance asks:
Who decided that this is what it means, and how do we keep that meaning trustworthy?
That may ultimately be the most important role semantic models play in the agentic enterprise.
The next generation of enterprise systems will not simply expose data to AI.
They will expose the meaning behind the data.
