Explicit concepts and relationships stop it from guessing how the business fits together.
A leading semantic layer vendor recently shared a “Guessing vs. Computing” comparison for enterprise AI, backed by a benchmark focused on semantic computation and query efficiency. The premise is right. AI agents should not have to rediscover business definitions, infer analytical logic, or generate every query from scratch. Their benchmark makes this concrete: an unguided LLM has to guess which table holds revenue, interpret regional codes, and infer fiscal-period logic before it can even attempt an answer, while a semantic-layer-guided path starts from predefined measures, dimensions, and time logic instead. That is a real step toward reliable enterprise AI.
But that alone is not enough. There is another kind of guessing that happens before the calculation even starts. Before an AI agent can compute anything, it needs to understand how the business itself is connected.
Two different problems, both worth solving
Traditional analytical questions fit naturally into measures and dimensions: what was revenue last quarter, how many active customers do we have, what is transaction volume by region, how are customers distributed across age groups. These are exactly the kinds of questions represented in the vendor’s benchmark, which walks through customer hierarchies, age buckets, gender normalization, transaction channels, and governed measures like transaction value and active customer count. For workloads like these, governed semantic definitions solve a real problem. Instead of asking the LLM to decide what “active customer” means each time, the definition is established once. Instead of asking the model to invent age brackets or fiscal-calendar logic, those rules are governed in advance and the query is routed to the cheapest correct path.
Call this the execution path: given governed metrics and dimensions, what is the correct and efficient way to calculate the answer. The benchmark is built around this problem, and its results make a strong case for governed semantic execution.
But enterprise questions are not always analytical slices over known measures. Many depend on understanding business entities and how those entities relate to each other before any calculation can happen. Call this the semantic path: given a business question, which concepts does it involve, and how are those concepts connected.
Consider a question like:
Which premium customers with active contracts are affected by suppliers connected to delayed shipments?
Before an agent can calculate anything here, it has to understand a chain of business concepts and the relationships between them: a customer holds a contract, a contract covers a product, a product is supplied by a supplier, a supplier is tied to a shipment. It also has to know what qualifies a customer as premium, what makes a contract active, and which relationships to traverse to connect a delayed shipment back to an affected customer. This is not a matter of picking the right metric. It is a matter of understanding the structure of the business itself, and that structure goes beyond the role of individual measures and dimensions.
Measures and dimensions describe analytics. Ontologies describe the business.
Measures and dimensions are powerful because they standardize analytical meaning. Revenue can be defined once. Active customer can be defined once. Region can follow an approved hierarchy. Those definitions reduce ambiguity and stop an AI agent from recreating established business logic at runtime, which is exactly the value the benchmark demonstrates.
An ontology extends that semantic foundation by explicitly modeling what exists in the business and how those things relate: a customer may have a relationship to a contract, a contract may cover a product, a product may be supplied by a supplier, a supplier may be associated with a shipment. Those relationships become part of a governed semantic model instead of something an LLM has to infer from foreign keys, table names, or scattered documentation. In many semantic-layer implementations, these connections are primarily modeled as joins in service of a specific metric. In an ontology, relationships are modeled as first-class business concepts in their own right, so they can be traversed independently of any single calculation.
The same reasoning that says an AI agent should not have to guess how revenue is calculated should also say it should not have to guess how a customer, a contract, a product, and a supplier are connected. If a commercial customer is a specialized type of customer, that inheritance should be part of the governed model rather than buried in a prompt or application code. If a supplier relationship follows specific business rules, those rules should be defined once rather than rediscovered independently by every AI application that touches them.
Why this matters for AI agents
BI tools have traditionally started from relatively structured analytical questions. AI agents do not have that constraint. A user might ask which enterprise customers renewed this year despite having unresolved critical support cases, a question that spans customer records, contract status, and support case history, and depends on understanding how those entities relate before anything gets summed or counted. For an agent, getting this right depends on more than choosing the correct SQL expression. It depends on understanding which path through the business model the question implies. Without an explicit model of those relationships, the system has to infer that path on its own, and inference is exactly where enterprise AI becomes difficult to govern.
How Timbr models the semantic path
In Timbr’s ontology-based semantic layer, this is not hypothetical. Business concepts like Customer, Contract, Product, and Supplier are defined once, with their properties and explicit relationships, rather than leaving an agent to infer those connections from foreign keys. A Commercial Customer can inherit properties and rules from Customer, so specialized business logic does not need to be redefined downstream. Each concept and relationship maps back to the underlying data, so applications and AI agents can query the ontology through standard SQL, with no data movement and no separate query language to learn. The result is a governed model of how the business fits together, directly accessible to agents and applications through SQL.
A semantic layer for both analytics and business structure
None of this makes governed metrics or optimized query execution less important. They are essential, and the benchmark makes a strong case for removing unnecessary runtime discovery from analytical queries. But reliable enterprise AI needs another dimension of semantic context alongside it: a model of the business itself, not just the calculations defined across its data.
At Timbr, this is the role of an ontology-based semantic layer. Business concepts, relationships, inheritance, rules, measures, and mappings are represented in one governed model, while applications and AI agents continue to work with the underlying data through SQL. The goal is not to replace semantic computation. It is to extend it, so agents get both the governed calculations they need and the business context required to use them correctly.
Stop guessing the calculation. Stop guessing the relationships.
