By May 2026, the way agents talk to enterprise data warehouses has been fundamentally rewritten. The 2024 pattern — give the agent a Snowflake user, a connection string, and hope it writes reasonable SQL — has been replaced by a governed control plane: Snowflake Cortex AI, Databricks Genie / AI/BI Agents, and the dbt Labs MCP server. These three tools share a common premise: the agent never holds a raw warehouse password and never writes a raw SELECT *. Instead, the agent calls into a governed semantic layer that knows the data model, knows the cost ceiling, and knows which users are authorized to see what. This lesson walks through wiring an analytics agent into all three control planes, shipping a "what changed in our pipeline last week" agent that reads dbt model lineage and writes a Slack summary, and avoiding the specific failure mode of the agent that ran SELECT * FROM customers and timed out the cluster.

The 2024 Pattern and Why It Broke

Through 2024 and into early 2025, the standard pattern for connecting an analytics agent to a warehouse looked like this. Create a Snowflake (or BigQuery, or Redshift) user with broad read scope. Hand the agent the connection string. Tell the agent: "answer questions about our data; write SQL." The agent runs SQL via a Python connector or a workflow node. Results flow back as JSON. The agent summarizes for the user.

This pattern worked for demos. It broke in production in three predictable ways:

1. Cost runaways. The agent wrote SELECT * FROM customers against a 400-million-row table and the warehouse charged $80 for the query. Or worse — the agent wrote a join across three large tables without filters and held a virtual warehouse for 40 minutes. We saw monthly Snowflake bills triple after agent enablement at one team in mid-2024 before they put guardrails in place.
2. Schema drift and confabulation. The agent didn't know cust_status was deprecated, that customer_tier replaced it, and that the values had different semantics. The agent ran a query against the old column, got null results, and confidently reported "no customers in tier A" because the column was empty (it had been retired).
3. Permission blowups. The agent's broad read scope gave it access to PII columns, financial data, and compliance-restricted tables. A user-facing chatbot leaked employee compensation data because no one had thought about the join path the agent might take to get there.

By Q3 2025, every major data-warehouse vendor had shipped their own response. Snowflake released Cortex AI Functions and Cortex Analyst (GA mid-2025). Databricks released Genie and AI/BI Agents (GA late 2025). dbt Labs released the dbt MCP server (GA early 2026). All three converge on the same architecture: the agent doesn't talk to the warehouse directly. The agent talks to a governed semantic layer that exposes safe operations.

The 2026 warehouse-agent control plane is "the agent never holds a SQL password." Authentication, cost controls, schema awareness, and row-level security all live in the semantic layer. The agent calls the semantic layer and the semantic layer calls the warehouse.

Snowflake Cortex AI: The Cortex Analyst Pattern

Snowflake's response to the warehouse-agent problem is Cortex AI, a suite of LLM-aware features inside Snowflake. The two most-used in 2026:

Cortex Analyst

A natural-language-to-SQL service that operates against a Snowflake semantic model. You define the semantic model — typically in YAML, listing tables, columns, joins, business-logic definitions, and named metrics — and Cortex Analyst answers questions only within that model. When a user asks "what was MRR last quarter," Cortex Analyst translates that to a SQL query against the semantic-model-defined revenue table, executes it, and returns the answer.

Critically, Cortex Analyst doesn't have the autonomy to write arbitrary SQL. It can only construct queries that map to the semantic model's published surface. SELECT * FROM customers is not a thing Cortex Analyst can do — there is no semantic-model affordance for "dump the whole customers table." The agent calling Cortex Analyst inherits this constraint.

Cortex AI functions

SQL-callable LLM functions inside Snowflake: SNOWFLAKE.CORTEX.SUMMARIZE, SNOWFLAKE.CORTEX.CLASSIFY, SNOWFLAKE.CORTEX.EXTRACT, SNOWFLAKE.CORTEX.COMPLETE. These let workflows run model calls against data without exporting the data — the LLM call happens in Snowflake's compute. Useful for "classify these 50,000 support tickets" jobs that would otherwise require export-process-reimport cycles.

How the agent connects

As of May 2026, Snowflake's Cortex services are exposed via an MCP server (Snowflake MCP, GA December 2025) and via Snowflake's REST API. The MCP server is the recommended path for agents. The agent connects via OAuth to a Cortex Analyst semantic model, asks natural-language questions, and Cortex Analyst returns structured results. Permissions: the OAuth user's grants determine which semantic-model surfaces the agent can see. PII columns flagged in the semantic model are excluded by default.

What this prevents

The runaway cost case. Cortex Analyst's queries are bounded by the semantic model — no SELECT *, no unconstrained joins. The schema-drift case. The semantic model is the source of truth; deprecated columns are removed from the semantic model and Cortex Analyst can't see them. The permission case. The agent's OAuth scope determines visible surfaces; PII and restricted data are out of reach unless explicitly granted.

Databricks Genie and AI/BI Agents

Databricks' analog. Two product surfaces:

Databricks Genie

Conversational analytics over Databricks Lakehouse. You configure Genie with a "Genie Space" — a named selection of tables, with documentation, sample questions, and benchmark queries. Users ask questions in natural language; Genie generates SQL constrained to the Genie Space's tables, executes against the Lakehouse, and returns charts or tables.

Same architectural premise as Cortex Analyst: the natural-language layer is bounded by a curated semantic surface. The agent calling Genie inherits the surface constraint.

AI/BI Agents (Databricks Agent Bricks)

Released GA at Data + AI Summit June 2025, expanded through 2026. AI/BI Agents are higher-level constructs: an agent that combines Genie (for data access) with other tools (for action). You define an agent's data sources (Genie Spaces), action capabilities (workflows, alerts), and persona; the agent operates within those constraints.

How the agent connects

The Databricks MCP server (GA April 2026) is the cross-host connector. Agents in Claude Desktop, Cursor, Claude Code, or any MCP-aware host connect to Databricks via the MCP server and gain access to configured Genie Spaces and AI/BI Agents. Permissions inherit from the Databricks workspace's Unity Catalog grants.

What this prevents

Same three failure modes as Cortex. Plus a Lakehouse-specific benefit: Unity Catalog's lineage tracking means the agent can answer "where does this column come from" questions natively — useful for the "what changed in pipeline" agent we'll ship later in this lesson.

dbt Labs MCP Server

The third leg of the 2026 warehouse-agent control plane is the dbt Labs MCP server, GA in early 2026. dbt is the dominant transformation layer in warehouse pipelines as of 2026 — most enterprises with non-trivial data infrastructure run dbt for their ELT transformations. The dbt MCP server exposes dbt's metadata as MCP tools:

• Model lineage. "What models depend on the customers staging model?" "What raw sources feed into the active_users mart?" The agent can traverse the lineage graph and explain dependencies.
• Test results. "Did any models fail tests in the last 7 days?" "Show me the failing rows for the orders.amount_positive test."
• Run history. "When did the nightly_full_refresh job last run?" "Did any models fail to build in the last run?"
• Documentation. "What does the customer_lifetime_value column represent?" — pulled from dbt's documentation YAML.
• Semantic-layer queries. Via dbt's MetricFlow integration: "what was MRR last quarter" routes through dbt's semantic-layer-defined metric and executes against the warehouse via dbt Cloud or dbt Semantic Layer endpoint.

The dbt MCP server is what makes the agent pipeline-aware, not just warehouse-aware. The agent can answer "what changed" questions, "what's broken" questions, and "what does this metric actually mean" questions — all without writing raw SQL.

Ship a "What Changed in Pipeline Last Week" Agent

This is the canonical 2026 warehouse-agent build. The agent's job: every Monday morning, summarize what changed in the data pipeline over the last week and post the summary to a #data-engineering Slack channel. The agent should call out new models, removed models, failing tests, schema changes, and meaningful run-time regressions.

The architecture

Three MCP servers connected to the agent host (Claude Code is what we used in the build we observed in April 2026): the dbt MCP server (for pipeline metadata), the Databricks MCP server (for warehouse-level usage stats and Unity Catalog lineage), and the Slack MCP server (for posting the summary). One Skill — weekly-pipeline-summary — that orchestrates the workflow.

The Skill body

---
name: Weekly Pipeline Summary
description: When invoked (typically scheduled Monday 8am), generate a "what changed last week" summary of the dbt pipeline and post to #data-engineering Slack.
---

# Weekly Pipeline Summary

Your job: produce a structured weekly summary of dbt pipeline changes for the data team.

Steps:

1. Query the dbt MCP for models added, modified, or removed in the last 7 days (use dbt's run history + git metadata).
2. Query the dbt MCP for test failures in the last 7 days. Note which tests, on which models, with row counts.
3. Query the dbt MCP for run-time regressions: any model whose build time increased >50% week-over-week. Cross-check with Databricks usage stats for the underlying job.
4. Query Databricks for any schema changes in upstream Unity Catalog tables that haven't yet been reflected in dbt staging models.
5. Compose the summary using the template in resources/weekly-template.md.
6. Post the summary to #data-engineering Slack via Slack MCP.

Constraints:
- Do not include PII or compensation data in any summary.
- Limit each section to 3-5 bullet points; defer detail to the dbt docs link.
- Always include "Questions? Ping @data-team-on-call" at the end.

Termination:
- After posting, reply with the message permalink so the operator can verify.

The flow in practice

Monday 8am, a scheduled trigger invokes the agent with "run the Weekly Pipeline Summary Skill." The agent:

1. Calls dbt.run_history(last_7_days) via the dbt MCP. Receives a list of runs, models built, test results.
2. Calls dbt.model_changes(last_7_days). Receives added/modified/removed model list with git context.
3. Calls dbt.test_failures(last_7_days). Receives 3 failing tests on 2 models.
4. For each failing test, the agent calls dbt.test_details(test_name) for context.
5. Calls databricks.unity_catalog.recent_schema_changes(7_days). Receives a list of upstream changes.
6. The agent identifies that one upstream change (a new column added to raw.events) hasn't been reflected in any downstream dbt staging model — a real pipeline drift signal.
7. Composes the summary per template. Posts to Slack via slack.post_message(channel="#data-engineering", text=...).
8. Returns the message permalink to the scheduler.

Total elapsed time: ~25 seconds. The agent at no point holds a Databricks SQL credential, never writes raw SQL, and never sees PII columns (Unity Catalog's column-level grants exclude them from the agent's view).

The "SELECT * FROM customers" Failure Mode

Here's the canonical 2024-pattern failure that the 2026 control plane prevents.

A team gave their support-triage agent a Snowflake user with read access to the analytics schema. The agent's job was answering "how many customers does X account have?" by querying the accounts and users tables.

One day, a customer's question routed through the agent unusually: "what's the total customer count for accounts with more than 100 users?" The agent's prompt-generated SQL was, in essence, SELECT * FROM customers c JOIN users u ON u.account_id = c.id WHERE (SELECT COUNT(*) FROM users u2 WHERE u2.account_id = c.id) > 100; — a correlated subquery that the agent's prompt didn't realize would scan the full users table for each row of customers.

The query ran for 47 minutes against a 600-million-row users table on an X-Large warehouse. Snowflake billed roughly $190 for the single query. The agent retried twice (the timeout returned an error the agent interpreted as transient), so the actual bill was closer to $570 across the three attempts. The team's monthly Snowflake budget had been $4,200; this one query was ~14% of that budget.

What the 2026 control plane would have prevented:

• Cortex Analyst: the question would have routed through a "customer count" semantic metric that has a defined, optimized query plan. No correlated subquery. The metric's query plan would have returned the answer in seconds.
• Genie Space: same. The Genie Space's curated tables and example questions would have produced a vetted query rather than a model-generated novelty.
• dbt MCP: if the team's "customer count by account size" was a defined dbt metric, the dbt semantic layer would have served it from a pre-aggregated model. Microseconds, not 47 minutes.

The 2026 pattern doesn't just save money. It removes the variance — the agent can't get unlucky with a costly query because the surface doesn't expose costly queries.

Cost and Permission Governance

Cost governance

The 2026 stack provides cost governance through three mechanisms:

1. Semantic-layer query plans are pre-vetted. A metric defined in Cortex Analyst, Genie, or dbt has an execution plan that's been reviewed for cost. The agent invoking the metric inherits that plan.
2. Warehouse-level cost caps. Snowflake's resource monitors, Databricks' workspace quotas. Per-agent service account budgets limit damage from any agent that misbehaves.
3. Query-cost annotation in tool responses. The MCP servers can return query-cost estimates with results, letting the agent decide whether to proceed (or letting the host's audit log capture the cost).

Permission governance

Four layers of permission control, all inherited from the warehouse-side identity:

1. OAuth scope. The agent's OAuth token is scoped to specific semantic models / Genie Spaces / dbt projects.
2. Row-level security. The warehouse enforces RLS policies on the agent's queries; data the agent's identity can't see doesn't leak.
3. Column-level masking. PII columns are masked or dropped from the agent's view. Unity Catalog and Snowflake both support this natively.
4. Time-bound consent. For high-stakes data, time-bound tokens that expire and require re-consent.

The principle: identity flows from the agent's OAuth credential through the semantic layer to the warehouse. The warehouse enforces. The agent inherits. Nothing the agent does can bypass warehouse-side policy.

Three Real Warehouse-Agent Stories

Story one: the $570 query

Covered above. A 2024-pattern agent with raw SQL access generated a correlated subquery that scanned 600M rows three times. $570 across retries. The team migrated to Cortex Analyst the following quarter; their average per-query cost dropped from $0.40 (with high variance) to $0.06 (low variance) within two months.

Story two: the schema-drift confabulation

A 50-person SaaS had a customer-success agent that answered questions like "what was customer X's MRR last quarter?" The agent used a Snowflake credential with raw SQL access. Operations had deprecated the monthly_recurring_revenue column six weeks earlier and replaced it with arr_monthly, but the agent's prompt still referenced the old column name. The agent ran queries that returned null and reported "no MRR data available" for affected customers.

The migration to Cortex Analyst removed the problem: Cortex Analyst's semantic model was the source of truth for column names, and the data team had updated it as part of the deprecation. The agent, which now asked Cortex Analyst for MRR (not raw SQL), automatically used the new column.

Story three: the lineage-aware agent that saved an afternoon

A 200-person fintech ran the "what changed in pipeline last week" agent we walked through above. In April 2026, the agent's Monday summary flagged: "Upstream Unity Catalog table raw.transactions added a new column 'fraud_score' on Wednesday. No downstream dbt staging model has been updated. This may cause null fraud_score values in customer_risk_summary." The data team had been about to ship a Tuesday dashboard featuring fraud_score and hadn't yet caught that the staging model wasn't pulling the new column. The agent's flag caught it 22 hours before the dashboard would have shipped with bad data.

The agent's value here wasn't in any one query — it was in cross-system pipeline awareness. The dbt MCP knew the downstream graph; the Databricks MCP knew the upstream change; the agent stitched them together.

The Five-Step Build Routine

For a builder bringing up an analytics agent on the 2026 stack:

1. Inventory. Which warehouse(s) does the agent need to reach? Snowflake, Databricks, or both. Does your team run dbt? Almost certainly yes if you're at this stage.
2. Install the MCP servers. Snowflake MCP, Databricks MCP, dbt MCP, plus the SaaS MCPs (Slack, Atlassian, etc.) for output. All from official sources; see Lesson 2 of this chapter on the allowlist.
3. Define semantic surfaces. Cortex Analyst semantic model, Genie Space, dbt metrics. This is the work that pays for itself over and over — clean semantic definitions are the foundation.
4. Scope OAuth. Service account with least-scope grants. Read-only against the semantic surfaces the agent needs; no raw SQL on production tables.
5. Build the Skill. The agent's procedural guidance for the specific analytics task. Wire to the MCP servers' tools. Test against a fixed set of historical questions before going live.

Time to first running analytics agent on the 2026 stack: typically 1-3 days, depending on how mature your semantic layers already are. Teams with mature dbt projects and existing Cortex Analyst / Genie configuration ship in hours. Teams starting from scratch invest a week or more in semantic-layer definition before the agent is useful.

What to Avoid

• Giving the agent raw warehouse credentials "for now." The 2024 pattern. Every team we've seen do this regretted it within months. Cortex Analyst, Genie, and dbt MCP exist specifically so you don't have to.
• Skipping the semantic layer because "we'll do it later." The semantic layer is where governance lives. An agent on top of a missing semantic layer is an agent without governance.
• Trying to use one mega-Skill for all warehouse work. Split by task — one Skill for daily summaries, one for ad-hoc questions, one for incident response. Each Skill's manifest is sharper this way.
• Holding tokens with broad scope. The agent's OAuth should be scoped to the specific semantic models / Genie Spaces it needs. Not "all of Snowflake," not "all of Unity Catalog."
• Forgetting cost monitoring. Even with semantic-layer governance, set warehouse resource monitors. Belts and suspenders.
• Letting the agent run unbounded retries on errors. The $570 story tripled in cost because the agent retried after the first timeout. Cap retries at 1-2 with exponential backoff.

Key Takeaways

• The 2024 pattern — give the agent a Snowflake user and let it write SQL — broke in three predictable ways: cost runaways (the $190-per-query SELECT *), schema-drift confabulation (deprecated column returning nulls), and permission blowups (PII leaking through join paths). By Q3 2025, every major warehouse vendor had shipped a governed control plane.
• The 2026 warehouse-agent control plane has three legs. Snowflake Cortex AI (Cortex Analyst for nat-lang-to-SQL bounded by a semantic model; Cortex AI functions for SQL-callable LLM ops). Databricks Genie / AI/BI Agents (Genie Spaces; agent constructs over Lakehouse). dbt Labs MCP server (model lineage, test results, run history, docs, semantic-layer queries).
• All three share the architecture: the agent never holds a raw warehouse password. The agent calls the semantic layer; the semantic layer calls the warehouse. Identity flows from the agent's OAuth credential through the layer to the warehouse, which enforces.
• The canonical 2026 agent: "what changed in pipeline last week." Three MCP servers (dbt, Databricks, Slack) + one Skill orchestrating. The agent traverses dbt lineage, checks Unity Catalog upstream changes, identifies drift, and posts a Slack summary. No raw SQL. No PII access. ~25 seconds end-to-end.
• The $570 query failure mode. A correlated subquery scanned 600M rows three times after retries. The 2026 control plane prevents this — Cortex Analyst/Genie/dbt semantic surfaces only expose vetted query plans, not raw SQL with unbounded surface.
• Cost governance: semantic-layer query plans are pre-vetted, warehouse resource monitors enforce caps, MCP responses can carry query-cost annotations for agent self-throttling.
• Permission governance: OAuth scope, row-level security, column-level masking, time-bound consent. Four layers, all warehouse-enforced. The agent inherits; the agent can't bypass.
• Three real stories. The $570 query (migrated to Cortex Analyst → $0.06 average). The schema-drift confabulation (semantic layer became the source of truth for column names). The lineage-aware agent (caught a pipeline drift 22 hours before a dashboard would have shipped with bad data).
• Five-step build routine. Inventory (which warehouses + dbt). Install MCP servers from official sources. Define semantic surfaces. Scope OAuth. Build the Skill. Mature teams ship in hours; from-scratch teams invest a week in semantic-layer definition first.
• Avoid: raw credentials "for now," skipping the semantic layer, mega-Skills covering all warehouse work, broad-scope tokens, no cost monitoring, unbounded retries. Each of these has a direct mapping to one of the 2024-pattern failures.