Every company has a semantic layer, even when it exists only in an analyst's head rather than in software.
2
A semantic layer should be separate from BI tools so the same definitions can support BI, ML pipelines, data applications, and AI applications.
3
Agents can automate much of data engineering, but they need concise, rich context and human approval for the definitions they create.
Summary
David Jayatillake argues that semantic layers are already present in every company. The question is whether business definitions live in a person's head or are written down in a system that others can use. He prefers semantic layers outside proprietary BI tools because logic locked into Looker or PowerBI cannot easily support other BI tools, ML pipelines, data applications, or AI systems. He explains the difference between data modeling and a semantic layer: data modeling organizes entities, events, and relationships, while the semantic layer describes how those models can be queried through metrics, dimensions, joins, and aggregations. Agents could automate connectors, routine transformations, semantic-layer creation, and queries. The harder parts are permissions, identity resolution, business context, and deciding what definitions mean. David also connects semantic layers with enterprise LLM use, MCP, memory, and feature stores. His practical preference is to have an LLM build a definition once, review and approve it, then reuse it instead of generating raw SQL for every question.
Every company already has a semantic layer, even when a person is doing the work
David says companies always use a semantic layer, whether they know it or not. If the logic is not in software, it is in a person's head. He spent much of his career acting as that human layer, answering questions because he knew the data model and could write SQL. As a junior analyst, he once completed 77 requests in a week and realized that people should not have to repeat the same work manually. The issue is therefore not whether a company needs semantics. It is whether the definitions are codified and reusable or remain dependent on one employee.
Semantic logic locked inside a BI tool creates multiple versions of the truth
David dislikes semantic layers built into proprietary BI tools such as Looker and PowerBI. Those systems let teams define logic in a tool-specific language, but the definitions cannot easily be reused elsewhere. This may work for a small company that only needs reporting in one tool. Problems begin when teams also need metrics in ML pipelines, data applications, multiple BI tools, or AI applications. They must duplicate the logic or maintain separate definitions, which creates different versions of the truth. Demetrios Brinkmann connects this to vendor lock-in and technical debt. David agrees that better-resourced teams should make the abstraction explicit early.
Data modeling organizes the business, while the semantic layer explains how to query it
David separates two closely related activities. Data modeling arranges business data around entities such as customers, orders, and products, along with state changes and events that describe interactions. He mentions Kimball, Data Vault, and wide tables as possible approaches, depending on the situation. The semantic layer then describes how those models join, aggregate, and group. It exposes a simpler REST, GraphQL, or similar API, allowing someone to request metrics and dimensions without knowing the underlying model or SQL. Good modeling makes the semantic layer easier to use, but thinking about how people will query the data can also guide the model from the beginning.
Agents can automate repetitive data engineering work in separate stages
David sees several routine parts of data engineering as suitable for agents. An agent could connect to Salesforce and move source data into raw storage because companies often repeat the same connector setup or rebuild connectors that already exist elsewhere. Another agent could handle standard raw-to-staging transformations such as deduplication, type casting, and null handling. Identity resolution and business-specific enrichment are harder, although David thinks they become more automatable if companies share common data models and questions. Later agents could expose the data model, build and maintain the semantic layer, and query it. He prefers a collection of specialists because extraction and transformation are different activities.
Business questions can define the data model and semantic layer an agent needs
David agrees that recurring business questions can drive the design. A request such as showing revenue by channel and product, with filters, implies a metric, dimensions, and entities. Those requirements determine what must exist in the semantic layer and are closely linked to the data model. Demetrios Brinkmann points out that companies may need a glossary explaining what terms mean in their own context. David agrees. This approach also prevents data teams from extracting and processing large amounts of data before knowing what anyone will do with it. The questions provide a more concrete starting point for deciding which data is needed.
Agent quality depends on giving the model concise, structured context
David identifies context as the difficult part of building an agent for a semantic layer. The model needs context that is concise, rich, and fairly complete. Too much information can cause what he calls attention drift. He used Claude Code and Cursor to help build systems that select and assemble the right prompt contents. He also tested whether SQL could be left in its original form or should be parsed into an explicit structure. Using a library called SQLGlot to represent joins and other details gave the LLM a better understanding. This experience makes him prefer having an LLM build and review semantic definitions once, then reuse them, rather than generating raw SQL for every request.
Enterprise LLM conversations could become a new source of governed data signals
David says companies are asking for access to enterprise data from ChatGPT and Claude, often through MCP. If that access sits on a semantic layer, the answers use agreed definitions and governed calculations instead of arbitrary CSV files. Conversation history could also show which questions employees repeatedly ask, what concepts they combine, and where people are testing an initiative. David and Demetrios Brinkmann discuss the possibility of analyzing these patterns across a company, while also acknowledging the privacy and surveillance concerns. David compares shared LLM memory to reusing a useful answer from one employee's conversation when another employee asks a related question.
A semantic layer can make different departmental definitions visible
David explains that different departments can be correct while using different definitions. At an online grocer, marketing, trading, and supply chain each had a different meaning of revenue. Marketing counted everything sold, trading counted what left the door, and supply chain counted what was not returned. A semantic layer can expose the filters and assumptions behind each version so that users understand what they are asking for. David says this transparency matters when marketing, finance, and executives ask about the same metric with different scopes. The system should make those choices explicit rather than hiding them inside separate queries.
Feature stores and semantic layers overlap, but their treatment of time and definitions differs
David compares semantic layers with feature stores such as Cube and Feast. Feature stores care about evaluating a feature at a particular point in time, which is less central to a semantic layer. He says a semantic layer describes entities for people, while a feature store selects features for a model. Feature stores can keep multiple versions, such as replacing E79 with E80 while older consumers continue using the earlier feature. A semantic layer should provide a canonical definition instead. David still sees value in semantic descriptions for features, since unexplained feature names and comments such as 'do not ever delete this' make it hard to understand how a feature was created or why it matters.
"Either way you end up with different versions of the truth and then you've kind of defeated the object of or part of the object of having a semantic layer."David Jayatillake06:00
Who should watch
You are deciding whether semantic definitions should live inside a BI tool or in a shared layer used by several systems.
Your data team spends time repeating connector setup, standard transformations, or requests for metrics that could follow a known pattern.
You are connecting enterprise data to ChatGPT or Claude and need agreed definitions, permissions, and visibility into how people query the data.
