MCP Is Not Enough: Why Enterprise AI Agents Need a Governed Semantic Layer

This is the argument the rest of this series has been building toward. It runs in four claims, each backed by a primary source, and it ends where the evidence points: MCP is necessary and not sufficient, and the missing piece is a governed semantic layer.

Capability	MCP alone	dbt SL + MCP	Cube + MCP	Cortex Analyst + MCP	Databricks Genie + MCP	Colrows
Standardized agent access	Yes	Yes	Yes	Yes	Yes	Yes
Metric definition governance	No	Yes	Yes	Within Snowflake	Within Databricks	Yes
Warehouse-agnostic	N/A	Yes	Yes	No	No	Yes, 16+ engines
Compile-time RBAC / ABAC	No	Partial	Partial	Within Snowflake	Within Databricks	Yes
Compile-time RLS / CLS	No	Partial	Partial	Within Snowflake	Within Databricks	Yes
Join-path proof	No	Requires modeling	Requires modeling	Within semantic view	Within metric view	Yes, automated
Deterministic SQL	No	Yes, metric-scoped	Yes, metric-scoped	Within Snowflake	Within Databricks	Yes
Dual MCP + REST surface	Varies	Yes	Yes	Partial	Partial	Yes

Read the table honestly. Warehouse-native layers are excellent inside a single platform. Standalone layers like dbt and Cube are warehouse-agnostic but ask for substantial modeling. Every row that says "yes" for more than one product is a row where the market has already agreed the capability matters. The question is not whether you need a semantic layer. It is which one, and how much of your estate it covers.

Claim 1: MCP has become enterprise infrastructure

Start by conceding the winner. MCP is not a bet anymore. In December 2025 Anthropic donated the protocol to the Linux Foundation's Agentic AI Foundation, with Block and OpenAI as co-founders. Anthropic's Mike Krieger described MCP as having "become the industry standard for connecting AI systems to data and tools." Per Anthropic's own figures there are more than 10,000 active public MCP servers and 97 million-plus monthly SDK downloads.

The production evidence is just as strong. Bloomberg reported that MCP "reduced experimentation time from days to minutes" in its account of embracing the protocol, and Block, per its Anthropic customer story, has 12,000 employees using AI agents across 15 job functions. Salesforce made Hosted MCP Servers generally available in April 2026 with per-user identity. The full picture of that shift is in enterprise MCP adoption. The transport war is over, and MCP won it.

Claim 2: MCP standardizes connectivity, not meaning

Here is the pivot the market keeps missing. Look at what the protocol actually specifies. The MCP specification defines three primitives: Tools, Resources, and Prompts. Every one of them describes how an agent reaches a capability. None of them describes what the data means. The 2026-07-28 release candidate hardens transport and authorization further, which is real progress, and it still says nothing about which definition of revenue is the approved one.

That gap is not a defect in MCP. It is the correct scope for a transport protocol. HTTP does not define what a web page means either. But it means the meaning problem is left entirely to whatever sits behind the server. As covered in APIs vs MCP vs A2A, MCP solves connector fragmentation. It does not solve definitional fragmentation. The protocol made every connector look the same. Something else has to make every answer mean the same thing.

MCP is the transport. The semantic layer is the logic. You need both. The protocol made every connector look the same. The semantic layer makes every answer mean the same thing.

Claim 3: meaning failures are the dominant failure mode of production agents on data

If the meaning gap were rare, it would be a footnote. It is not. It is the main way agent analytics fails in production, and the benchmarks make it measurable.

Raw text-to-SQL collapses on real schemas. On the Spider 2.0 benchmark, built from enterprise databases that average around 800 columns across multiple dialects, models score roughly 6 to 25 percent under agentic evaluation, against more than 90 percent on the toy-sized Spider 1.0. The gap between the demo and production is that cliff, which we cover in the text-to-SQL accuracy cliff. Three structural failures drive it: metric ambiguity, where "revenue" means booked orders to sales, recognized earnings to accounting, and gross order volume to marketing; join hell, where a model joins orders to products and bypasses the subscription model, returning total order value instead of monthly recurring revenue; and non-determinism, where the same question yields different SQL and different numbers on different runs, which the team at Omni Analytics catalog in detail. Each of these is a meaning failure, not a connectivity failure, and each is examined in MCP for business intelligence.

State the evaluation regime whenever you quote any of these figures, because the benchmarks are noisier than the leaderboards imply. A 2026 UIUC study of annotation errors found error rates of 52.8 percent in BIRD Mini-Dev and 62.8 percent in Spider 2.0-Snow. The honest reading is not that models cannot write SQL. It is that raw accuracy on real enterprise data is both low and genuinely hard to measure, so no single number should anchor a production decision. What is not ambiguous is the direction: grounding the same model in a semantic layer moves it up, consistently and by a lot.

The other half of the meaning gap is governance. IBM's 2025 Cost of a Data Breach report put breaches involving shadow AI at an average of 4.63 million dollars, with 97 percent of AI-breached organizations lacking proper AI access controls, and research on authorization propagation in multi-agent systems shows that RBAC and ABAC alone do not carry permissions correctly through delegation, aggregation, and time. Both the wrong-number problem and the wrong-access problem are failures of resolving meaning before execution, which is why governance in an MCP world and correctness turn out to be the same engineering problem.

Claim 4: the fix is a governed semantic layer behind the protocol

Now the constructive part, and the strongest single piece of evidence in this series. dbt Labs' 2026 benchmark, with a companion paper by Ganz and Perigaud, measured the same models with and without a semantic layer. On a well-modeled project, Claude Sonnet 4.6 moved from 90.0 percent raw to 98.2 percent grounded, and GPT-5.3-Codex moved from 84.1 percent to 100.0 percent. On messier real-world data, dbt's internal testing moved raw-schema text-to-SQL from about 40 percent to 83 percent grounded. dbt's own summary is the line to keep: "When the semantic layer can't answer a question, it says so. Text-to-SQL gives you a wrong answer that looks right." A failure you can see beats a wrong number you cannot.

The analysts have priced this in too. Gartner's February 2026 Market Guide for Agentic Analytics carries a projection worth citing precisely as a projection: by 2028, 60 percent of agentic analytics projects relying solely on MCP will fail due to the lack of a consistent semantic layer. And the vendors have voted with their roadmaps. The Open Semantic Interchange, launched in 2025 with dbt Labs, Snowflake, and Salesforce, defines vendor-neutral semantic definitions on MetricFlow, which is the market agreeing that portable meaning is worth standardizing. The mechanism behind all of this is the subject of what a semantic compiler is: intent in, governed and deterministic SQL out.

Why agents raise the stakes that dashboards only hinted at

Inconsistent metrics are an old problem. Dashboards have carried duplicated business logic for years, and organizations mostly survived it because a human read the chart and applied judgment. Agents remove that buffer, and they do it along three axes at once. They operate at speed, so a wrong interpretation propagates in seconds rather than in a quarterly review. They operate with autonomy, choosing tools, queries, and sometimes actions without a person checking each step. And they operate at scale, where one governed layer can serve many agents correctly, but one ungoverned setup multiplies the same error across every function that calls it. With a dashboard, bad logic causes reporting confusion. With an agent, it causes wrong actions, data exposure, and policy violations, at machine speed.

The raw database trap, and the pattern that replaces it

Most early MCP deployments fall into the same trap: expose raw database tools and let the agent write SQL directly. It demos beautifully and fails quietly. The approach assumes a model can infer business meaning from schema structure, and at enterprise scale it cannot. Schema names are inconsistent, tables evolve, sensitive columns sit beside routine ones, and the important business rules live outside the database entirely. Even a16z, in its deep dive on MCP, frames the protocol as "API++" and notes the mapping from a raw API to a safe agent tool is rarely one to one. So "MCP plus run-SQL" is not governed enterprise analytics. It is a well-connected guesser.

The pattern that works inverts the flow: the agent expresses business intent, not implementation detail. Rather than letting it choose arbitrary joins and filters, the system exposes governed capabilities, get finance-approved revenue by region and quarter, explain churn using the approved customer-health model, retrieve policy-compliant funnel metrics, compare forecast against actuals on validated definitions, summarize support performance without exposing sensitive ticket content. The agent asks the question; the governed semantic layer validates it, applies policy, resolves the right definitions, proves the join path, compiles deterministic SQL, and returns an auditable answer. That is the move from "it connected" to "it can be trusted," and it is the whole difference between a pilot and a production system.

The semantic-layer landscape, credited honestly

A governed semantic layer is not a Colrows invention; it is a category, and several implementations are genuinely good. It helps to see the four shapes of the market. Standalone layers like the dbt Semantic Layer on MetricFlow, Cube, and AtScale are warehouse-agnostic and metric-first. Warehouse-native layers like Snowflake's Semantic Views with Cortex Analyst and Databricks' Metric Views with Genie are deeply integrated inside one platform. BI-native layers like Looker's LookML, Power BI, and MicroStrategy carry decades of modeling. Context and catalog tools like Atlan and Alation describe and organize meaning, a landscape mapped in Atlan's own survey of semantic layer tools.

Their MCP integrations are real. Snowflake Cortex Analyst serves governed, semantic-view-grounded querying with RBAC per tool and built-in OAuth, capped at 50 tools and Snowflake data. Databricks Genie does the same under Unity Catalog, within Databricks. The dbt Semantic Layer MCP server is warehouse-agnostic if you invest in the modeling. Cube, used by more than 400 companies, exposes SQL, REST, GraphQL, and MCP with row-level access control; Brex chose it for an embedded AI financial analyst after evaluating dbt Semantic Layer and LookML, a decision the LookML versus dbt Semantic Layer comparison examines. Dremio enforces fine-grained access control in the query engine on every MCP query. If your estate is one warehouse, one of these may be the whole answer.

Where Colrows fits, and what its wedge actually is

Colrows is one implementation of Claim 4's pattern: the semantic execution layer behind your MCP fleet. It does not compete with MCP and it does not dismiss the vendors above. Its wedge is a specific combination that a multi-warehouse enterprise needs.

It is warehouse-agnostic, compiling dialect-perfect SQL across 16-plus engines including Snowflake, Databricks, BigQuery, Redshift, Postgres, MySQL, ClickHouse, and Trino, so one governance model spans the estate instead of one per platform. It enforces RBAC, ABAC, and row and column predicates at compile time, which means unauthorized queries fail compilation, not in production, the discipline detailed in building an MCP semantic layer server. It is a deterministic compiler: it proves join paths automatically and produces the same governed SQL for the same intent, so metric drift is eliminated by construction rather than caught in review, a contrast drawn out in RAG vs. semantic layer and semantic layer vs. knowledge graph. And it exposes both an MCP server and a REST surface over the same governed graph, so agent traffic and conventional traffic return the same answer. None of that makes other layers wrong. It makes Colrows the warehouse-agnostic, compile-time-governed option when your data does not live in a single platform.

One more property matters at enterprise scale: the graph maintains itself. Hand-modeled semantic layers are only as current as the last person who updated the YAML, and on a large, drifting estate that upkeep becomes the bottleneck on answer quality. Colrows builds and continuously updates its typed semantic graph from the data, the metadata, and real usage, with drift detection when definitions or schemas move underneath it. The point is not that modeling is bad; dbt, Cube, and LookML all reward careful modeling. The point is that autonomous maintenance changes the operating cost of keeping meaning correct across many warehouses and many agents, which is the cost that quietly decides whether a governed layer stays governed a year after launch.

What to evaluate before you build or buy

If you are putting agent access on top of MCP, the architectural questions that matter are about trust, not protocol support. Ask them of any option, including Colrows:

• Can the same question produce the same approved answer, consistently, across runs and agents?
• Are metrics defined once and reused everywhere, or re-invented per query?
• Are access controls enforced before execution, not after the answer is already assembled?
• Can sensitive rows and columns be masked or filtered automatically, per requester?
• Can the system explain which sources and definitions produced a given answer?
• Do ambiguous or unauthorized questions fail safely instead of guessing?
• Can the generated SQL or execution plan be reviewed and audited?
• Does the semantic definition travel across warehouses, or is it locked to one vendor's dialect?

This is also the honest frame for the build-versus-buy decision. A homegrown middleware layer can encode a few of these checks. Keeping RBAC, ABAC, row-level, and column-level policy correct across every warehouse, every metric, and every agent, as definitions change and the estate grows, is the recurring cost most teams underestimate, and it is the same maintenance burden that makes broad agent access risky in the first place. Bessemer's State of AI research tracks how quickly that surface area expands once agents are in production. If most of the answers above are no, then MCP alone is not enough, and a governed semantic layer is the thing you are actually shopping for.

Why this is the real path to the company brain

Step back and the pattern is larger than analytics. A genuine company brain is not a chat box with many connectors; it is a governed intelligence layer that interprets business questions correctly, uses approved knowledge safely, and returns consistent answers across the organization. MCP is part of that architecture because it standardizes the interface. But the brain also needs memory, semantics, policy, and deterministic execution, or it becomes a well-connected guesser. That is the same conclusion reached from the memory side in from ambient memory to deterministic autonomy, and it is why the meaning layer, not the connector, is the part worth funding. Y Combinator has said as much: its Summer 2026 Requests for Startups names "Company Brain" as a category, a signal we unpack in the YC Company Brain RFS analysis. And it is why a catalog that finds the table still leaves the agent to guess, the point of why data catalogs cannot execute AI agents: discovery is not execution.

Put the pieces together and the conclusion is not subtle. MCP won because standardized connectivity was worth standardizing, and enterprises were right to adopt it. The next thing worth standardizing is meaning: which definition of revenue is approved, which join is valid, which rows this requester may see. That is a semantic layer's job, not a protocol's, and it is the work that remains once the connectors all look the same.

Fix the Context, Not the Model. The evidence is not that the models are weak. The same model jumps from 84 percent to 100 percent when the context is governed. It is that the model was given no way to be right until a semantic layer gave it one.

Frequently asked questions

Does MCP replace a semantic layer?

No. MCP is the transport that lets an agent reach tools and data. The semantic layer is the meaning-and-governance tier that decides what the data means, which join is valid, and what the requester may see. You need both.

What is a semantic execution layer?

A compile-time tier that turns business intent into deterministic, governed SQL for any warehouse. It resolves the request against a typed semantic graph, proves join paths, enforces policy, and emits dialect-correct SQL, so the same question yields the same governed answer every time.

Why isn't the protocol enough on its own?

MCP standardizes connectivity, not meaning. Without a semantic layer, the same question can produce different SQL and different answers across runs, and an agent can pick the wrong join or the wrong definition of revenue while returning a number that looks right.

What is compile-time governance?

Policy checks embedded in the step that compiles intent into SQL, so unauthorized or ill-formed queries fail before they touch the database. Unauthorized queries fail compilation, not in production.

What is the difference between the dbt Semantic Layer and Colrows?

dbt's Semantic Layer is metric-scoped and depends on substantial hand modeling in MetricFlow. Colrows compiles a governed semantic graph autonomously and enforces RBAC, ABAC, and row and column policy at compile time across 16-plus SQL engines. Both are valid; they sit at different points on the modeling-effort and warehouse-coverage axes.

Do I need a semantic layer if I use Snowflake Cortex Analyst?

For a Snowflake-only architecture, Cortex Analyst plus the Cortex MCP server covers a great deal. For a multi-warehouse estate, you still need a warehouse-agnostic layer that applies one governance model across Snowflake, BigQuery, Databricks, and the rest.

Is a semantic layer just a metric store?

No. A metric store is one component. A full semantic execution layer adds governance, join-path proof, compile-time policy, and deterministic execution, so it decides not only what a metric is but whether this requester may compute it right now.

How does a semantic layer relate to a data catalog?

Catalogs describe; semantic layers execute. A catalog tells you a table exists and what it roughly contains. A semantic layer compiles a governed, policy-checked query against it. Discovery is not execution.