Semantic Layers, Agents, and the Coming Wave of FUD

Semantic layers have entered their fear, uncertainty, and doubt (FUD) era. This is what happens whenever a category becomes strategically important. Adjacent technologies start explaining why it is unnecessary, obsolete, too rigid, or already solved somewhere else.

One distinction runs under every objection that follows. Most of what people offer as a substitute for a semantic layer is descriptive: documentation, catalog entries, prompts, ontologies, retrieval context. It sits beside the query as advice. A semantic layer is executable. It sits in the execution path and shapes how a question becomes a query. Nearly every argument against semantic layers is really an argument for keeping meaning descriptive when the agent era requires it to be executable.

So let's take the objections one by one.

1. "Agents can infer the business logic from the schema"

They can infer some things. They can make educated guesses from table names, column names, comments, sample values, and data profiles. But schemas encode physical structure, not business meaning.

A table called orders does not tell you whether cancelled orders count toward revenue. A column called customer_id does not tell you which customer hierarchy is authoritative. A field called status does not tell you which statuses should be included in active customer counts. A timestamp does not tell you whether the business uses order date, ship date, invoice date, or recognition date for a particular metric.

The agent can guess, and sometimes it will even guess well, but the enterprise should not rely on guessing when answering governed business questions. Metadata helps an agent reason about data. A semantic layer tells the agent what the enterprise has agreed those concepts mean.

2. "The data catalog is enough context"

Catalogs are valuable. They help people find data, understand assets, identify owners, inspect lineage, and read descriptions. A good catalog can be part of the context stack, however, a catalog is not the same thing as an executable semantic layer.

A catalog may tell you that a table exists. It may tell you what a column means. It may tell you who owns it. It may even point to documentation describing a metric. That is different from defining the approved measure, its aggregation behavior, its dimensionality, its allowed join paths, its filters, its grain, and the executable logic required to answer a question consistently.

A catalog helps you discover and understand data. A semantic layer governs how business questions are executed against that data. Both matter, but they are not substitutes.

3. "The warehouse or lakehouse should own the semantic layer"

This objection will become more common as cloud data platforms introduce their own semantic modeling, metric, or ontology capabilities.

There is nothing wrong with warehouse-native semantics. For organizations that live entirely inside a single platform, it can be useful. The problem is that most enterprises do not live inside a single platform.

They have multiple warehouses. They have BI tools, notebooks, spreadsheets, APIs, orchestration tools, embedded applications, and now AI agents. They have workloads spread across Snowflake, BigQuery, Databricks, Redshift, Postgres, Oracle, SQL Server, Trino, and other systems. They have governance requirements that do not stop at the boundary of one vendor's compute engine.

If the semantic layer is trapped inside one warehouse, then semantic consistency becomes another form of platform lock-in. Definitions are governed only for the tools and workloads that happen to pass through that vendor's environment.

Enterprise semantics need to be portable. They need to serve multiple tools, multiple engines, and multiple consumers. The goal is not to bury business meaning inside a single platform. The goal is to make business meaning reusable across the enterprise.

4. "BI tools already have semantic layers"

They do. Power BI, Tableau, Looker, MicroStrategy, and other BI platforms all have semantic modeling concepts. In many organizations, the BI layer is where semantic work first became visible.

However, BI semantic layers were usually designed to govern dashboards and reports inside a particular consumption experience. That is useful, but it is no longer sufficient.

Today the consumers of governed business meaning include analysts writing SQL, engineers building data products, data scientists building cohorts and features, applications calling APIs, automation workflows, and agents answering questions on behalf of users.

A semantic model locked inside a BI tool cannot govern all of those experiences. BI semantic layers helped govern dashboards. Enterprise semantic layers need to govern analytical meaning across humans, tools, APIs, and agents.

5. "Semantic layers slow analysts down"

Bad governance slows analysts down. That part is true.

A semantic layer implemented as a bureaucratic approval gate will frustrate people. A semantic layer that prevents exploration will be routed around. A semantic layer that only restricts usage and never packages reusable knowledge will feel like another compliance burden.

But that is not an argument against semantic layers. It is an argument against bad implementation.

A good semantic layer speeds analysts up because it eliminates repetitive work. Analysts should not have to rediscover the approved revenue calculation every time they start a project. They should not have to reverse engineer join logic from old dashboards. They should not have to ask five people which version of customer churn is correct.

Governance that only restricts slows people down. Governance that packages reusable knowledge speeds them up.

6. "Semantic layers are just metric stores"

Metric stores are part of the story, but they are not the whole story.

Enterprise analytics is not just a list of measures. It is a network of business concepts and relationships. Metrics need dimensions. Dimensions belong to entities. Entities have relationships. Relationships have cardinality and grain. Measures have aggregation behavior. Hierarchies matter. Filters matter. Visibility rules matter. Ownership matters.

A metric without its surrounding business structure is incomplete.

"Revenue" is not enough. Revenue by what? Customer? Product? Region? Sales channel? Contract? Invoice? Fiscal quarter? Recognized date? Booked date? Shipped date? At what grain? Through which relationship path?

Semantic layers are not merely stores for metric formulas. They model the business structure required to answer analytical questions consistently.

7. "Semantic layers cannot handle complex analytics"

This criticism usually comes from people who have seen semantic layers used only for dashboards.

A semantic layer should not replace every form of SQL, statistical modeling, exploratory analysis, or data engineering. Not every analytical question needs to be pre-modeled. Not every workflow should be forced through a narrow governed interface.

But that does not make semantic layers irrelevant to complex analytics.

Complex analysis still depends on stable definitions. A data scientist building a churn model needs to know which customers count as active. An analyst investigating margin erosion needs trusted definitions of revenue, cost, discount, region, and product hierarchy. An agent exploring claims trends needs governed definitions for claim status, service date, provider, member, and plan.

The semantic layer provides the governed starting point. From there, analysts and agents can explore, extend, and investigate. A semantic layer is not a cage for all analysis. It is the governed foundation for analysis that depends on shared business meaning.

8. "Semantic layers are brittle because the business changes"

The business does change. Definitions evolve. Products are renamed. Fiscal calendars shift. Segments get reorganized. Policies change. Acquisitions introduce new systems. Regulatory requirements force new reporting definitions. That is exactly why semantic definitions need governance.

When business meaning changes, the enterprise needs ownership, review, versioning, impact analysis, lineage, approvals, and communication. The alternative is not flexibility. The alternative is silent divergence across hundreds of queries, dashboards, notebooks, spreadsheets, and agent prompts.

A semantic layer does not prevent business change. It gives organizations a way to manage business change operationally. When meaning changes, you want governed change management, not accidental drift.

9. "Semantic layers are too hard to maintain"

Enterprises are already maintaining semantic logic. They are just doing it informally.

It lives in BI workbooks, SQL snippets, dbt models, stored procedures, spreadsheet formulas, notebook cells, dashboard filters, tribal knowledge, and Slack threads. It gets copied. It gets modified. It gets partially remembered. It gets reimplemented by different teams with slightly different assumptions.

The semantic layer does not create the maintenance burden. It makes the burden visible.

That visibility can be uncomfortable because it exposes how much business logic has been scattered across the estate. But surfacing the problem is not the same as causing it.

The choice is not between maintaining semantics and not maintaining semantics. The choice is between maintaining them explicitly or letting them sprawl.

10. "Semantic layers are only for business users"

This is a leftover assumption from the self-service BI era.

Semantic layers were often marketed as a way for business users to ask questions without writing SQL. That remains useful, but it is too narrow.

Technical users need semantic layers too. Analysts need reusable definitions. Data engineers need governed interfaces for downstream consumption. Analytics engineers need contracts between modeled data and business usage. Data scientists need consistent cohorts and features. Application developers need APIs that return trusted metrics. Agents need executable business context.

Semantic layers are not just for nontechnical users. They are for every consumer of analytical meaning, including software.

11. "Semantic layers will be replaced by ontologies or knowledge graphs"

Ontologies and knowledge graphs can be powerful. They can model concepts, relationships, taxonomies, and domains in rich ways. They can help describe how the business thinks about itself. But describing the business is not the same as answering governed analytical questions against enterprise data.

An analytical semantic layer must connect business meaning to executable data access. It needs to know how to calculate measures, aggregate them, filter them, join entities, respect grain, and generate queries against real systems. Ontologies can complement semantic layers. They may provide broader conceptual context. But they do not automatically replace the governed analytical interface.

An ontology can describe the business. A semantic layer must answer questions against the data.

12. "The LLM can just use retrieval over documentation"

Retrieval over documentation is useful. Documentation should absolutely be part of the context available to agents. But documentation is not operational governance.

A markdown page can explain how the business defines revenue, a wiki can describe customer segmentation, or a policy document can define eligibility criteria, but unless those definitions are tied to executable measures, dimensions, joins, filters, and data sources, the model still has to translate prose into query logic. That translation step is where drift enters.

The model may retrieve the right document and still produce the wrong query. It may interpret the document differently than another model. It may miss an exception. It may combine the right definition with the wrong table. It may apply the right filter at the wrong grain. Documentation can explain a metric. A semantic layer operationalizes it.

13. "Semantic layers are just another abstraction"

They are an abstraction. That is not a flaw.

All enterprise analytics depends on abstraction. Tables abstract files. Views abstract queries. Data marts abstract source systems. APIs abstract services. BI dashboards abstract analytical logic. Even SQL itself is an abstraction over physical execution. The question is not whether abstraction is bad. The question is whether the abstraction captures the right contract.

A semantic layer abstracts business meaning. It gives the enterprise a governed contract for measures, dimensions, entities, relationships, and analytical usage. That is a different level of abstraction than raw tables or physical storage. The problem is not abstraction. The problem is the wrong abstraction at the wrong level.

14. "Semantic layers hide the underlying data"

They should not.

A good semantic layer should make business logic more transparent, not less. It should expose definitions. It should show generated SQL. It should provide lineage. It should identify owners. It should support version history. It should make changes reviewable. It should allow technical users to inspect how an answer was produced.

The purpose of the semantic layer is not to conceal complexity. It is to make the approved logic explicit and reusable. That is especially important for agents. If an agent answers a business question, the user should be able to inspect which metric definition was used, which dimensions were applied, what filters were included, and what query was executed.

A good semantic layer does not hide logic. It makes business logic explicit, inspectable, and governed.

15. "Semantic layers are an old BI idea with new marketing"

Semantic layers are not new. That is true.

The industry has been trying to separate business meaning from physical data structures for decades. BI platforms, OLAP systems, cubes, universal semantic layers, business objects, metric stores, and modeling languages all come from that long history. However, that history is a strength, not a weakness.

What has changed is the number and variety of consumers. In the past, the main consumers were dashboards, reports, and business users. Now the consumers include agents, notebooks, operational workflows, embedded applications, and automated decision systems. The old problem has become more urgent because the surface area has expanded.

Semantic layers are not suddenly important because the idea is new. They are important because AI has increased the number of systems that need governed access to business meaning.

16. "Governance kills agent autonomy"

This gets both governance and autonomy wrong.

Agents should be able to explore. They should generate hypotheses, investigate anomalies, explain trends, compare scenarios, and help users ask better questions. But when an agent answers an enterprise metric question, it should not invent the definition. There is a difference between exploration and authoritative reporting.

For exploration, agents need flexibility. For enterprise answers, agents need governed semantics. The semantic layer does not eliminate autonomy but rather gives autonomy a reliable operating frame. A self-driving car still needs traffic laws, lane markings, maps, and constraints. An analytical agent still needs governed definitions, relationships, and execution rules.

Agent autonomy is useful for exploration, but governed semantics are necessary for enterprise answers.

17. "We can solve this with prompt engineering"

Prompts can guide agent behavior. They can tell the agent to prefer certain tables, follow certain rules, avoid certain mistakes, or ask clarifying questions, but prompts are not durable governance.

They are hard to audit, hard to version across tools, and easy to bypass. They are difficult to test systematically. Worse, they often live outside the normal data governance lifecycle. Most importantly, they do not replace executable definitions.

A prompt that says "use approved revenue" is not the same thing as a governed revenue measure that is connected to the data and enforced in the execution path.

Prompt engineering can guide behavior, but a semantic layer governs meaning.

18. "Semantic layers are only useful after the data is perfect"

This is the perfection trap.

No enterprise has perfect data. Definitions are incomplete and ownership is uneven. Some domains are well modeled and others are still messy. There are duplicate fields, legacy systems, ambiguous names, and inconsistent assumptions. Waiting for perfect data before building a semantic layer means waiting forever.

A semantic layer can be part of how the organization improves its data. It forces important questions into the open. Which metrics matter? Who owns them? Which definitions are approved? Which joins are valid? Which dimensions are authoritative? Which domains are ready for governed consumption?

You do not need to model the entire enterprise on day one. Start with the metrics, domains, and use cases that matter most.

Semantic layers are not the reward for perfect data. They are part of how organizations make data usable.

19. "Nobody agrees on the definitions anyway"

That is exactly the point.

Disagreement over definitions is not an argument against semantic layers. It is the reason they exist.

If sales, finance, operations, and product all define "customer" differently, the enterprise needs a way to make those differences explicit. Sometimes there should be one approved definition. Sometimes there should be multiple definitions for different domains. Sometimes the right answer depends on the frame of analysis, but those distinctions should be governed, visible, and intentional.

Without a semantic layer, disagreement gets encoded silently into dashboards, spreadsheets, SQL queries, and agent responses. With a semantic layer, disagreement becomes part of an explicit governance process.

A semantic layer does not magically solve organizational disagreement. It gives the organization a place to resolve it, document it, and operationalize the result.

20. "Semantic layers are too rigid for AI"

This sounds plausible because AI feels flexible and semantic layers sound structured.

However, the more probabilistic the interface becomes, the more important the deterministic contract underneath it becomes. Agents can reason flexibly over governed definitions. They can interpret user intent, ask clarifying questions, select relevant measures, generate explanations, and explore adjacent questions. But when it is time to answer with enterprise data, they need a reliable substrate.

Otherwise, the same question can produce different answers depending on prompt wording, model version, retrieved documents, schema interpretation, or conversational history. That is not acceptable for governed analytics. AI does not eliminate the need for semantic layers. It increases the cost of not having one.

The probabilistic layer needs a deterministic contract underneath it.

21. Semantic layers are not "the context layer"

That is true, but only because there is no such thing as THE context layer.

Context is always relative to a frame. If a user asks a general business question, the right context may be a product brief, policy document, wiki page, meeting note, support ticket, contract, or data catalog entry. If the user asks about system behavior, the right context may be code, logs, deployment history, and architecture documentation. If the user asks about fourth quarter sales, net revenue retention, claim volume, margin by region, or active customers, the right context must be connected to the data. That is where the semantic layer matters.

A semantic layer is not a universal context layer. It is the governed business-and-data context required to answer analytical questions consistently. It belongs alongside catalogs, documentation, lineage systems, policies, vector search, model instructions, and user permissions. But it plays a distinct role because it is not just descriptive. It is executable.

The real issue is operational governance

Enterprises need operational governance over analytical meaning: approved metrics, governed relationships, ownership, versioning, cross-tool consistency, and business logic that lives in the execution path rather than in scattered documentation or fragile prompts.

Agents make this urgent because they change the speed and scale at which questions get asked and answered. A model can generate a hundred plausible queries, each defensible on the surface, each producing a different version of the truth. That is the confidence-reality gap operating at machine speed. The more probabilistic the interface becomes, the more the deterministic contract underneath it matters.

The answer is not to keep agents away from data. It is to give them governed interfaces that encode enterprise meaning. AI does not remove the need for semantic layers. It is the reason governed meaning finally has to live in the execution path. The probabilistic layer needs a deterministic contract underneath it. That is what a semantic layer is.