AI for data analytics teams

Most wrong AI answers from a warehouse aren't syntax errors. The query runs, returns a tidy number and answers a slightly different question from the one you asked. Every warehouse makes its own choices about time zones, weeks and arithmetic, and an assistant that doesn't know yours picks one silently. Write the differences down once, in the project, and Claude can say which one each figure uses.

The metric definitions themselves are on monthly active users, churn rate and net revenue retention. The project instructions in the setup below turn this table into rules Claude follows.

Most data teams don't need another platform. Claude sits in the middle: a project holds the context above and your metric glossary, and official MCP servers connect it to the warehouse, dbt and the tools where questions arrive. Count sits beside it and checks the answers. You'll only need one warehouse from the map; pick yours.

If your company runs ChatGPT instead.

ChatGPT Business costs the same ($25 a user monthly, $20 annually) and adds custom MCP servers from its plugins page, as long as each server is reachable at a public HTTPS address (OpenAI Developers). Snowflake, BigQuery, Databricks and dbt all host theirs, so the same warehouse setup works there; only the redirect address in each OAuth client changes. The project instructions below paste into a ChatGPT project as they are.

A stakeholder messages at 4pm: trial conversions fell last week, why? The same afternoon an analytics engineer needs a new dbt model for it, finance sends a spreadsheet that disagrees with the warehouse, and someone wants three charts for tomorrow's meeting. Four jobs. Claude has a different surface for each, and picking the wrong one is the commonest reason a data team decides Claude "isn't good with data".

Sources: claude.com/pricing, the Claude Code docs, Anthropic's Excel and Dashboards help pages, all checked 22 October 2026. Free has no Claude Code, Research, Dashboards or Microsoft 365 add-ins, so a data team needs Pro at least, and Team once more than one person shares projects and connectors.

Our default: analysts live in a project, analytics engineers live in Claude Code, and everyone uses the Excel add-in when a spreadsheet arrives. Dashboards is the newest piece and the least proven. Anthropic itself calls it "made for quick questions about your data", which is the right way to use it.

SQL and dbt work belongs in Claude Code

Ask Claude in a chat to "write a model for weekly active customers" and you get SQL in a code block, cut off from your sources, macros, tests and naming rules. Ask Claude Code the same thing from inside the dbt repo and it reads models/, finds the staging model you already have, follows your conventions and writes the file where it belongs. That difference is most of the case for using it.

What Anthropic's docs say it does, and the parts that matter for data work:

• It works in the repo. Claude Code "reads your codebase, edits files, runs commands, and integrates with your development tools". It runs in the terminal, in VS Code and JetBrains, and on the web at claude.ai/code.
• It asks first, by default. In Manual mode it asks before editing a file or running a shell command, apart from a built-in set of read-only commands such as ls, cat and grep. Plan mode goes further: Claude "reads files and runs read-only shell commands to explore but doesn't edit your source files". Use Plan mode for the first pass on any model you care about.
• It reads a CLAUDE.md every session. Put your SQL style, layer conventions and test rules in ./CLAUDE.md at the repo root; /init drafts one from the codebase. Anthropic suggests keeping it under 200 lines, and warns that Claude treats it "as context, not enforced configuration". A rule written there is a request, not a lock.
• It takes MCP servers too. claude mcp add --transport http <name> <url> adds a remote server; --scope project writes it to .mcp.json so the whole team shares it, and Claude Code asks for approval before using a project-scoped server.

How good is it at dbt work specifically? The best public evidence is Spider 2.0's dbt track, which asks agents to complete tasks inside real dbt projects. Its best score is 65.6 (Spider 2.0 leaderboard, read October 2026). Impressive, and also one task in three not done. So keep the loop you already trust: Claude Code writes on a branch, you run dbt build against a dev target, and a person reviews the pull request. It's faster at the typing. It isn't a reviewer.

Most of this happens in Claude's settings and takes about half an hour. The warehouse is the exception. Snowflake, BigQuery, Databricks and Looker all want an admin to create the sign-in and a read-only role first, so that step goes to whoever owns the warehouse, and CSV exports cover the gap until it's done. Step 1 gives the project the context from the top of this page, so every workflow below starts from your definitions instead of a guess.

Technical steps for Snowflake, BigQuery, Databricks and Looker (for the admin)

• Snowflake. Create the server with CREATE MCP SERVER and leave read_only: true on any SYSTEM_EXECUTE_SQL tool (the default). It doesn't support dynamic client registration, so create an OAuth security integration with OAUTH_CLIENT_TYPE = 'PUBLIC', redirect URI https://claude.ai/api/mcp/auth_callback, OAUTH_USE_SECONDARY_ROLES = NONE and ALLOWED_ROLES_LIST set to a role with SELECT only (Snowflake docs).
• BigQuery. The server is at https://bigquery.googleapis.com/mcp. Grant roles/mcp.toolUser, roles/bigquery.jobUser and roles/bigquery.dataViewer (on reporting datasets only, if you can), create a web OAuth client with the same Claude redirect URI, and add an IAM deny policy on read-write MCP tools so execute_sql is blocked (BigQuery MCP docs).
• Databricks. Add an app connection with the ai-gateway scope and both Claude redirect URLs. Genie One is generally available; system.ai.dbsql needs the Unity Gateway beta and runs with the caller's own permissions, so give the Claude group SELECT only (Databricks docs).
• Looker. The Looker-managed MCP server is in preview for Looker-hosted instances. Every tool is off by default: in Admin > Platform > MCP, switch on the read tools you need, then register Claude as an OAuth client through the API Explorer (Looker docs).
• Then in Claude. A Team Owner adds each server under Organization settings > Connectors, choosing "Use your own OAuth client" where needed; each person then signs in with their own account.

Keep Claude reading, not changing, until you trust it.

Snowflake's SQL tool is read-only by default and BigQuery's write tool can be blocked by policy, but Databricks' SQL server can do whatever the person signing in can do, so the grants are the control. dbt's remote server can't run dbt commands, yet it can start and cancel jobs; switch those tools off in the chat's tools menu if you don't need them. Slack can post and Looker tools can edit content, so approve each change one at a time and never choose "Allow always". Claude's Research mode can use connector tools without asking, so turn off anything that writes before you start a Research run.

The question that fills a data team's week: why did this number go down? Claude splits the change into mix (the segments shifted) and rate (a segment got better or worse), runs a query for each piece, and checks that the pieces add back up to the total. What it won't do, if the project rules hold, is name a cause the data doesn't show. More prompt patterns in prompts for data analysis.

A new source lands and someone has to find out what's actually in it before it feeds a dashboard. Claude profiles the table with queries (row counts, null rates, duplicate keys, date ranges, load gaps) and turns each finding into a dbt test you can add. The checks are queries, so each result traces to SQL you can rerun.

Claude writes SQL quickly, and on a schema it hasn't seen it will choose join keys and filters that run but answer a different question. This workflow makes it look for a governed metric first, write SQL only for what the metric can't answer, and reconcile the two when both exist. Why that order matters is in text-to-SQL and dbt MCP.

A second reader for every model change: Claude reads the diff, finds what changes the grain, the joins or a metric, checks lineage for what sits downstream, and writes the tests that would catch the problem. Claude's GitHub integration syncs files from a branch but not pull requests, so you paste the diff. The dbt MCP guide covers what the remote server can see.

The pack that goes to leadership every Monday. Claude pulls each KPI from the governed metric, compares it with the week before, builds the dashboard as an artifact and drafts the Slack post, with the query under every tile. It's also where the most visible mistakes happen, because a tile shows one number with no working beside it. More on building them in AI dashboards.

Prompts reduce errors; they don't remove them. In a 2026 study of 14 models, the best produced working links more than 94% of the time, yet only 39 to 77% of their claims were accurate (Onweller et al., Cited but Not Verified, May 2026). A query that runs is the easy part.

Common pitfalls

• Trusting a query because it ran. Valid SQL that answers a different question is the commonest failure. Read the FROM, the joins and the WHERE before the number.
• Joins that fan out. Join users to subscriptions and anyone with two subscriptions is counted twice. Compare the row count before and after each join.
• Adding distinct counts. Seven daily active user counts don't add up to weekly actives. Neither do monthly uniques across plans that people move between.
• Truncating dates in the wrong zone. A timestamp cut to a date in UTC and reported in London time puts late-evening events on the wrong day.
• Summarising a capped pull. A result of exactly 3,000 rows from BigQuery's MCP server means there were more. Aggregate in the warehouse.
• Benchmarks from memory. "Healthy" retention or "typical" stickiness with no source is the model's memory. Treat it as a question, not a fact.

Rules for the team

• No number without a definition. An answer that doesn't say what it counted doesn't get forwarded.
• Governed metric first, SQL second, memory never. It's in the project instructions so nobody has to remember it.
• Read-only by default. Write access is switched on for a named job, then off again.
• The query travels with the number. If Claude wrote SQL, the SQL goes wherever the result goes.
• Keep twenty test questions. Questions from last month's queue with known answers. Rerun them when the model, the glossary or the schema changes.

One check before anything leaves the data team

Count audits every answer automatically, inside the chat, and it checks more than the numbers. For each claim it asks: did this come from a query or a file, and does the result really say it? Does the reasoning hold, or does a conclusion go further than the data? Was a definition, a join or a formula assumed without saying so? Is a statement from the model's memory rather than anything in the chat? It replies with a canvas where each claim is labelled a citation, an assumption, model knowledge or a hallucination, with the reasoning chain under it. A weekly active users tile built by adding daily counts, a cause read into a coincidence and a "healthy" benchmark nobody sourced all show up for what they are. Each workflow above shows an example.

How do I use AI for data analytics?

How much does it cost to set up AI for a data team?

Can Claude connect to Snowflake, BigQuery or Databricks?

Can Claude Code be used for data analysis and dbt?

Is Claude good at SQL?

Which Claude plan do I need for data work?

Can AI replace a data analyst?

Why does AI give a different number from our dashboard?