How to Connect Your Semantic Layer to AI Agents: Architecture Guide

The most common pattern when organizations deploy their first data agent: give the agent warehouse credentials and instruct it to generate SQL.

The demo looks good. The agent translates "show me Q1 revenue by region" into a plausible SELECT statement, executes it, and returns a table. The team is excited.

Then production happens. Finance asks the same question and gets a number that differs from the official dashboard by double digits. The agent is querying a raw orders table that has not applied refund logic. The metric the business actually uses includes three adjustments, promotional discount netting, and a 14-day return window. None of that logic is in the agent's context.

This is the default failure mode. And it compounds at scale.

When five departments each build their own agent with their own SQL templates, you end up with five different definitions of the same metric. Agents contradict each other. Business users stop trusting the outputs. The AI initiative that was supposed to democratize data access instead generates a new category of data quality incidents.

The problem is not that agents cannot write SQL. It is that raw data warehouses contain schemas, not meaning. The schema tells an agent which tables exist. It does not tell the agent what "an active customer" means in this business, whether "revenue" includes or excludes refunds, or which time zone determines the close of a quarter.

That meaning has to live somewhere. It should live in the semantic layer. If you want to understand why agents hallucinate on business data specifically, this is the root of it: the absence of a governed translation layer between raw data and agent reasoning.

Most data teams think about their stack in two layers: data infrastructure below, AI tools above. That framing is the source of the problem.

The Intelligence Allocation Stack has four layers. Understanding where the semantic layer sits in that stack changes how you architect agent connections.

Layer 1 is the Data Foundation. Your warehouse, ingestion pipelines, data quality checks, governance policies, and raw tables. Snowflake, Databricks, BigQuery, Redshift. This is where data lives, but not where meaning lives.

Layer 2 is the Semantic Layer. This is where raw data becomes governed business meaning. Where "monthly recurring revenue" gets defined precisely, once, for every downstream consumer. Where access controls, time logic, fiscal calendar definitions, and metric calculations get encoded into reusable governed definitions.

Layer 3 is the Orchestration Layer. Pipelines, workflow automation, API integrations, reverse ETL, and event processing. The plumbing that moves data and triggers actions.

Layer 4 is the AI Layer. AI agents, conversational analytics tools, autonomous systems, and large language models that reason over business data.

Most organizations building AI agents today are trying to connect Layer 4 directly to Layer 1. They skip Layer 2 entirely. That is the architectural mistake that explains most agent failures in the field.

McKinsey describes the semantic layer's role clearly in their agentic AI architecture research: it turns data into knowledge by sitting between raw data and AI applications and codifying business meaning into machine-readable form. Rather than treating data as disconnected tables, the semantic layer defines what things are, how they relate, and what rules govern them.

When AI agents query through Layer 2 instead of directly against Layer 1, they get governed metric definitions. Hallucinated column names become structurally impossible. Inconsistent joins get prevented at the query interface. Access controls enforce themselves without agent-level prompt engineering. The agent's output can be audited because every data point traces back to a recorded, versioned definition.

There are two distinct modes in which AI agents interact with a semantic layer. Understanding both matters for how you build the connection.

The first mode is grounding. Before the agent generates any query or responds to a business question, it reads the semantic layer's descriptive context. It discovers what metrics and dimensions are available. It reads the definitions: what constitutes an active customer in this organization, how net revenue is calculated, what "last quarter" means given the fiscal calendar. This grounding step prevents the agent from hallucinating a metric name that does not exist or inventing a join that would produce incorrect results. Think of it as briefing a new analyst on the data model before asking them to produce a report.

The second mode is execution. Rather than generating raw SQL against base tables, the agent queries the semantic layer's interface using governed metric definitions. The semantic layer translates that business-level query into the correct SQL or API call against the underlying warehouse. The agent does not need to know which raw tables "active customers" comes from or what join conditions apply. It queries the governed vocabulary and receives results that match what the official dashboard would show.

These two modes work together. Grounding ensures the agent knows what it can ask. Execution ensures the answers it produces are derived from the same governed logic that powers every other consumer of the semantic layer: dashboards, reports, notebooks, and now AI agents.

This dual-mode architecture is why a well-built semantic layer is not optional for production AI deployments. An AI system that cannot explain where its numbers came from will not pass governance review. An AI system that produces different numbers than the official dashboard will lose business trust. Both problems are solved by routing agents through the semantic layer.

There are three connection patterns in production architectures today. Each serves a different part of the architecture.

The first is direct REST API or JDBC queries against the semantic layer's query endpoint. The agent constructs a query using metric and dimension vocabulary and sends it via a standard interface. Tools like Cube, AtScale, dbt Semantic Layer, and Omni expose REST endpoints that accept metric-level queries and return results with full governance applied. This is the most compatible approach for legacy agent frameworks that predate MCP adoption.

The second is Model Context Protocol (MCP). MCP is the open standard for connecting AI agents to external tools and data sources. It handles tool discovery, semantic descriptions of capabilities, authentication, and structured execution in a way REST APIs never were designed to. Several semantic layer vendors now ship dedicated MCP servers for exactly this purpose.

The third is the Open Semantic Interchange (OSI). Where MCP governs how an agent calls a semantic layer, OSI governs how semantic definitions can be shared and consumed across different platforms and tools. It is the portability layer that prevents metric definitions from fragmenting across your BI stack.

In most production architectures, you will use more than one. MCP handles agent-to-semantic-layer calls. OSI handles portability across BI tools and AI surfaces. REST or JDBC remains the fallback for systems that predate MCP. Understanding which protocol serves which connection keeps the architecture coherent instead of accidentally mixed.

Model Context Protocol was released by Anthropic in November 2024. By early 2026, it had been adopted by every major AI provider: Anthropic, OpenAI, Google, Microsoft, and Amazon. The Linux Foundation's Agentic AI Foundation now governs it as a vendor-neutral open standard, co-founded by Anthropic, OpenAI, and Block in December 2025. By February 2026, MCP had crossed 97 million monthly SDK downloads across Python and TypeScript combined.

The practical impact on semantic layer connectivity is significant.

Before MCP, connecting an AI agent to a semantic layer required custom integration work for every agent framework. You built a LangChain connector. Then rebuilt it for the next agent. Then rebuilt it again when the semantic layer's API version changed. Every integration was proprietary plumbing that someone on the data team owned and maintained.

MCP changes that model. A semantic layer vendor builds one MCP server. Any MCP-compatible agent can discover and use it without custom integration. The server exposes tools with natural-language descriptions so the agent understands what each metric is and when to use it. The agent gets self-describing capabilities, not raw schema documentation written for human developers.

The technical architecture of MCP is relevant here. The protocol operates over JSON-RPC 2.0, with stdio transport for local connections and HTTP/SSE for remote cloud deployments. For enterprise data architectures, the HTTP/SSE path is the relevant one: it supports OAuth 2.1 authentication, TLS, and scales to concurrent agent requests. A semantic layer MCP server exposes three types of capabilities: resources (metric definitions and business vocabulary the agent can read), tools (queries the agent can execute against governed definitions), and prompts (reusable templates that guide agent behavior on common business questions).

Omni's MCP server is a working production example of this pattern. It exposes governed metric definitions directly to agents running in Claude, Cursor, or any MCP client. The agent queries Omni as a tool call, gets back a governed answer derived from the semantic model, and can explain which metric definition produced it. The architectural implications of this pattern run deeper than a simple integration: it makes the semantic layer a first-class tool in the agent's operating environment, not a passive data source the agent routes around.

I have been using Claude as my primary AI tool for over a year and was MCP-native from the start. The difference between querying a semantic layer through MCP versus building a custom connector is not just convenience. It is the difference between an agent that queries governed definitions and an agent that improvises. The former scales. The latter creates maintenance debt that compounds with every new agent you deploy.

The architectural decision that matters most with MCP: does your semantic layer vendor ship an MCP server, or do you need to build one? Most mature tools now ship them. If you are running a custom or legacy semantic layer, building the MCP server is the investment that pays forward for every agent deployed afterward. As argued in the post on why MCP without a semantic layer will fail, the reverse is also true: MCP alone, pointed at raw schemas, reproduces the same hallucination problem at higher protocol sophistication.

Most organizations do not have one BI tool. They have Tableau for the executive team, Power BI for finance, notebooks for data science, and now AI agents for business users. Each of these consumers needs access to the same governed metric definitions. Without a portability standard, each team maintains their own copy. Revenue is defined slightly differently in Tableau than in Power BI. An AI agent queries a third version of the definition. The same metric produces three different numbers.

The Open Semantic Interchange addresses this by defining a standard protocol for sharing semantic definitions across platforms. Vendors that adopt OSI can read each other's metric definitions, expose them through a standard API, and consume them in agents through a consistent interface. An OSI-compliant semantic layer can serve a Tableau dashboard and an AI agent from the same governed definition without rebuilding the metric for each consumer.

For AI agent architecture specifically, OSI matters in multi-tool deployments. Teams running both Snowflake Semantic Views and dbt Semantic Layer face a real question: which definition does an agent use when the same metric is defined in two places? OSI provides the answer at the vocabulary level rather than the platform level. Shared definitions enforce consistency regardless of which underlying tool holds them.

The OSI ecosystem has expanded significantly in 2025 and 2026. Atlan participates as a named OSI partner, exposing semantic context to AI agents through the standard protocol rather than bespoke plumbing. Platform-native tools are developing OSI compatibility for their semantic capabilities. The direction is clear: portability is becoming table stakes for any semantic layer that claims to serve both BI tools and AI agents.

For architecture planning: OSI is the layer that future-proofs the connection. MCP protocol versions will evolve. Individual vendor APIs will change. Metric definitions encoded in an OSI-compliant semantic layer remain accessible and portable regardless of what happens at the protocol layer above them.

The architecture question gets substantially more complex when multiple AI agents work together.

Google introduced the Agent-to-Agent (A2A) protocol in April 2025. A2A governs horizontal communication between autonomous agents: how an orchestrator delegates subtasks to specialist agents, how results pass back up the chain, and how task state is tracked across the workflow. It has since been incorporated into the Linux Foundation's Agentic AI Foundation alongside MCP.

In a single-agent architecture, one agent connects to the semantic layer and gets governed answers. That is manageable.

In a multi-agent architecture, the orchestrator delegates to five specialist agents. Each specialist queries the semantic layer independently. If each specialist carries a different version of what "active customer" means, the orchestrator's aggregated answer will be semantically inconsistent even if each specialist's individual answer is locally correct. The orchestrator combines five internally valid but mutually incompatible numbers into a single output. The answer is wrong in a way that is extremely difficult to detect without tracing every query back to its source definition.

This is the consistency problem in multi-agent data architectures. And it is why a shared semantic foundation matters even more in A2A workflows than in single-agent deployments.

When specialist agents query through a shared semantic layer using standard interfaces, they all resolve metrics from the same governed definition. The orchestrator assembles answers from specialists that are semantically consistent with each other. Every query is auditable because every data point traces back to the same versioned metric definition.

The combination of MCP and A2A represents the current consensus architecture for enterprise agentic AI. MCP answers "what tools does my agent need access to?" A2A answers "which agent handles this subtask?" The semantic layer sits underneath both as the single source of truth for what business data means. Without that foundation, A2A-based architectures amplify the inconsistency problem by distributing it across multiple agents instead of containing it in one.

Here is how these pieces fit together in a concrete, production-grade architecture.

Layer 1 (Data Foundation): Your warehouse holds raw tables, ingestion pipelines, and data quality checks. Snowflake, Databricks, BigQuery, or Redshift. This is where data lives, but it is not the entry point for agent queries.

Layer 2 (Semantic Layer): Implemented in a tool like dbt Semantic Layer, Omni, Cube, AtScale, or Snowflake Semantic Views, this layer holds governed metric definitions: revenue, active customers, NRR, churn rate, customer acquisition cost. It exposes three interfaces: REST or JDBC for traditional BI consumers, an MCP server for AI agents, and an OSI endpoint for cross-platform portability. Definitions are version-controlled, reviewed like code, and updated through a formal process.

Layer 3 (Orchestration): Pipeline orchestration, workflow automation, and event triggers that activate agents on business conditions. The orchestration layer schedules agent runs, handles retries, and manages the A2A coordination when multiple agents collaborate on a workflow.

Layer 4 (AI Layer): AI agents, conversational analytics tools, and LLM-powered workflows. Agents connect to the semantic layer via MCP. They do not query raw tables directly. They do not generate freeform SQL against the warehouse schema. Every data query routes through Layer 2.

A concrete agent workflow through this architecture: a business user asks "Why did our enterprise customer acquisition cost spike in March?"

The agent connects to the semantic layer's MCP server and discovers that "enterprise customer acquisition cost" is a defined, governed metric. It queries the metric for the March period, with segment filters and fiscal calendar logic already applied by the semantic layer. It receives a governed number. It then queries adjacent metrics from the same semantic layer: pipeline stages by segment, marketing spend by channel, deal close rate by territory. Each query routes through governed definitions. The agent assembles the analysis and returns an answer where every data point can be traced back to a versioned metric definition that matches the official dashboard.

This is the architectural gap between a demo and a production deployment. The demo looks identical whether you have a semantic layer or not. The production system diverges within weeks, as soon as business users compare the agent's outputs to official reports and find discrepancies.

Understanding what breaks is as useful as understanding what works. These are the three patterns I see most often in failed or stalled AI agent deployments.

Anti-pattern 1: Text-to-SQL against raw tables. This is the starting point for most AI data agents because it is fast to prototype. The agent gets warehouse credentials, uses an LLM to translate natural language questions into SQL, and queries the raw schema. It works in demos. It breaks in production because the SQL generation is probabilistic. Different sessions produce different queries for the same question. There is no governed definition of revenue or active customers. Governance cannot audit what the agent produces because the SQL is generated on the fly and not recorded against any metric definition. The fix: route agent queries through metric-level vocabulary in the semantic layer, not freeform SQL generation.

Anti-pattern 2: Per-agent custom context. Each agent gets its own system prompt stuffed with metric definitions, business rules, and schema documentation. This feels like adding a semantic layer, but it is not. Each agent maintains its own copy of business logic. When the revenue calculation changes, someone has to update every agent's context manually. Definitions drift between agents. An agent built last month uses last month's revenue formula. The fix: a single semantic layer that all agents query through a shared interface. Update the definition once. Every agent gets the updated answer automatically, because the definition lives in the semantic layer, not in the agent's prompt.

Anti-pattern 3: Platform-native semantic layer for a multi-platform stack. An organization adopts Snowflake Semantic Views and treats it as the complete semantic layer for all agent connections. This works while everything lives in Snowflake. The moment a second platform enters the architecture (Databricks for ML, Redshift for a legacy application, a SaaS data source with its own metrics), the platform-native semantic layer cannot govern definitions across all of them. The agent ends up with inconsistent definitions depending on which platform a given metric lives in. The fix: a universal or headless semantic layer that abstracts across platforms, or an OSI-compliant approach that enforces vocabulary portability at the definition level rather than the platform level.

Recognizing these anti-patterns before they reach production is the difference between an AI initiative that compounds over time and one that accumulates governance debt with every new deployment. The full data architecture for AI agents context explains how each layer of the stack contributes to or undermines this.

The biggest implementation mistake is trying to model everything at once. Most semantic layer projects that stall do so because the team defined scope as "the entire enterprise data model" and then got buried in the effort of defining five hundred metrics before any agent could use one.

Start with five disputed metrics.

Every data team has them: the metrics that generate the most friction in data reviews, the ones where finance and marketing disagree, the ones where the agent returns a different number than the dashboard. Pick five of them. Bring the metric owners into a room, or onto a shared document, and get explicit agreement on each definition. Write the definition as code in your semantic layer tool. Version it. Deploy it.

Wire up the MCP server for your primary AI agent. Test by querying those five metrics through the agent and comparing the answers to your official reporting. They should match exactly. If they do not, the discrepancy points to where the definition is incomplete or where the agent's context is still reaching around the semantic layer to raw tables.

Expand to the next ten highest-friction metrics. Not all metrics. The ten that generate the most questions in data reviews, the most Slack messages from analysts asking "which version of this number is right?" Twenty trusted, verified, agreed-upon definitions are more valuable to a production AI deployment than five hundred unvalidated ones.

Add OSI-compliant exposure once the definitions are stable. This is what makes the semantic layer portable across new consumers as they come online: a new agent framework, a new BI tool, a new conversational analytics surface that does not yet exist in your stack.

The sequencing matters. Build the semantic foundation first. Connect the agent after. Most organizations do this backwards: they deploy the agent first, then attempt to add governance once the agent is already in production use. At that point, you have to tell business users that the answers they have been receiving for three months were ungoverned, and the new governed answers might differ. That is a credibility problem that is difficult to recover from.

Fix the floor before you let the agents run.

The 2026 Semantic Layer Summit, taking place virtually on May 20, brings together over 8,500 data and analytics leaders to focus on exactly this architecture question. AtScale's CTO David Mariani summarized the state of enterprise AI directly: "The biggest hurdle for enterprise AI in 2026 is not the AI, it is the meaning."

That framing captures why connecting the semantic layer to AI agents is not a technical nicety. It is the bottleneck for every enterprise AI deployment trying to get past the demo stage and into production at scale.

Every major data platform has validated the semantic layer as critical infrastructure in the past 18 months. Snowflake shipped Semantic Views. Databricks launched Metric Views alongside the LakehouseIQ agentic framework. Google has consistently emphasized structured semantics as foundational to making LLMs reliable for enterprise use. The industry is converging around a shared architectural understanding: AI agents need governed business context to produce trustworthy answers at scale.

What the Summit will surface, and what every independent architect should hold onto, is that every vendor on stage has their own version of what the "right" semantic layer looks like. AtScale's universal semantic layer. Databricks' LakehouseIQ. Snowflake's Semantic Views. They are each solving the same problem from inside their own platform boundaries.

The independent practitioner's job is not to pick the vendor with the best stage presence. It is to build the architecture that serves the actual stack, the actual metrics, and the actual AI agents the organization needs today, without locking into any single platform's version of what a semantic layer should be.

That means: define metrics as code. Expose them through MCP. Ensure portability through OSI. Connect agents to the semantic layer, not to the warehouse schema. Start at Layer 2, not Layer 4.

The dbt Semantic Layer's MetricFlow architecture is one concrete implementation of this principle. The broader point is vendor-agnostic: the semantic layer is the connective tissue between your data foundation and any AI system that needs to reason reliably over business data. Getting that connection right is the infrastructure work that determines whether your AI agents produce answers anyone will trust.

The real question going into the Semantic Layer Summit is not whether your semantic layer can connect to AI agents. Every vendor will tell you theirs can.

The question is whether you have a semantic layer worth connecting.