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.

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 belongs in the context stack. It is still not an executable semantic layer.

A catalog may tell you that a table exists, what a column means, who owns it, and where the metric is documented. 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 to make business meaning reusable across the enterprise rather than buried inside a single platform.

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, filters, visibility rules, and ownership all matter.

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 model the business structure required to answer those 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. It is the governed foundation for any 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. Skipping that governance does not buy flexibility. It buys silent divergence across hundreds of queries, dashboards, notebooks, spreadsheets, and agent prompts.

A semantic layer gives organizations a way to manage that change operationally, through governed review rather than 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 between maintaining semantics explicitly and 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 serve 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 read the document differently than another model does, miss an exception, combine the right definition with the wrong table, or apply the right filter at the wrong grain. Executable definitions remove the translation step entirely.

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, at a different level than raw tables or physical storage.

14. "Semantic layers hide the underlying data"

They should not.

A good semantic layer should make business logic more transparent. It should expose definitions, show generated SQL, provide lineage, identify owners, keep version history, and let technical users inspect how an answer was produced.

The purpose of the semantic layer is to make the approved logic explicit and reusable. That matters most 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.

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. That history is a strength.

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 matter now 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 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.

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, and 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.

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.

19. "Nobody agrees on the definitions anyway"

That is exactly why semantic layers 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 will not resolve the disagreement for you. It gives the organization a place to work it out, document the outcome, and operationalize it.

20. "Semantic layers are too rigid for AI"

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

The more probabilistic the interface, the more the deterministic contract underneath it matters. 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.

21. "Semantic layers are not the context layer"

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. It plays a distinct role because 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 answer is to give agents governed interfaces that encode enterprise meaning, so that meaning lives in the execution path instead of in documentation or prompts.

If you are weighing any of the twenty-one objections above, the practical test is the same each time: when an agent answers a business question tomorrow, can you see which definition it used, who approved it, and what query ran? If not, the meaning is still descriptive.