The state of agentic analytics, from 50 real data teams | Cassis<br>Skip to content Blog<br>Docs

Talk to us

Back to stories<br>The state of agentic analytics, from 50 real data teams<br>Field notes from 50+ conversations with data teams: the five stages of agentic analytics, what breaks at each, and what teams want next.

Matthieu Blandineau June 24, 2026

On this page

Summary

The five stages we kept seeingStage 1: bringing a general agent to the warehouse<br>Stage 2: using the native assistant in your data tool<br>Stage 3: pointing at the context you already have<br>Stage 4: building a curated context layer<br>Stage 5: keeping the context alive

The most immediate blockers to productionTrust in the numbers<br>Data access rights

Where everyone is heading<br>We spent the last few months talking to more than 50 data teams about agentic analytics.

Not the category slide version. The real version: what they actually wired up, what worked in a demo, what broke when someone asked a second question, and what they want to try next.

By agentic analytics, we mean an agent that answers a business question end to end. It reads the warehouse, the BI artifacts, the metric definitions, the docs, sometimes the codebase, then writes and runs the query. This is not a copilot suggesting SQL to an analyst, but something a non-technical person can ask directly and act on.

The first thing we learned is that “we are doing agentic analytics” means almost nothing by itself. The same words cover very different setups. Some teams point Claude Code at a warehouse. Some use the assistant built into their data platform. Some build a semantic layer. Some are trying to make that layer update itself from real usage.

So the useful question is not whether agentic analytics works. It is: which one you are running, what it knows, who maintains that knowledge, and how you know the answers are still right?

The five stages we kept seeing

What separates them is not the model but how much business meaning the agent has, and where that meaning comes from. The five line up as a progression: each gives the agent more context than the last, and most teams are trying to move further along it.

Stage 1: bringing a general agent to the warehouse

The simplest version is a general-purpose agent with database access. Claude Code, Cursor, an internal Slack bot, a thin MCP wrapper over Snowflake or BigQuery. The agent can inspect schemas, write SQL, run it, and explain the result.

What works: it is fast, flexible, and genuinely useful for technical users. It can explore a schema, draft queries, debug errors, and help an analyst move faster. For a data person who already knows the tables, it can feel like a better workbench. Several builders were comfortable giving an agent direct SQL access when the dataset was clean, narrow, and already well understood.

What breaks: the agent does not know the business meaning behind the schema. It can infer from table names, column names, dbt docs, and maybe a few pasted instructions, but that is not the same as knowing which definition of “active” the company uses. One head of analytics said the agent would pick the wrong table or grab the wrong column because it did not understand how the warehouse was structured.

A senior data engineer at a finance SaaS put the basic failure mode exactly: “You ask it a question, it answers with total confidence, but you already know the answer is wrong.” The quieter version of the same gap, from a data analyst at a public-sector org: the agent is “good on generic metric definitions, but it stays shallow on our specific context.”

Where teams go next: they start giving the agent more context. Not because the model cannot write SQL, but because SQL is the easy part once the meaning is clear.

Stage 2: using the native assistant in your data tool

The second version looks similar to the business user, but it is operationally different. The agent is built into the warehouse or BI tool: Snowflake Cortex Analyst, Gemini in BigQuery or Looker, Power BI Copilot, Databricks Genie, Omni’s AI agent, and the rest of the emerging native assistant layer.

What works: the assistant sits closer to the platform’s permissions, metadata, and semantic layer. There is less glue code. The demo path is cleaner. If the company has already modeled the right metrics inside that tool, the assistant can feel much safer than raw database access.

The strongest examples were scoped, not universal. One product analyst testing Omni’s agent described the setup as going “topic by topic”: add one domain, add context, make sure the dbt descriptions are correct for the relevant tables, then ask questions until the team is satisfied. Another operations leader said 80 to 85% of the data points they needed were already structured in Omni; the truly ad hoc questions were the exception. That is the happy path for this stage: a bounded domain, clean dimensions, known metrics, and enough documentation inside the tool.

What breaks: it is only as...