Anthropic is telling you that Agentic Analytics is not just text-to-SQL
Anthropic's Agentic Analytics suite using Claude achieves 95% accuracy and they share how in their latest post. Trustworthy analytics is all about semantic layers, skills, evals, and data engineering.
Anthropic's June 3, 2026 post on self-service analytics is one that I have shared with many of my stakeholders and Data Science team because, at last, someone is putting in writing that Agentic Analytics is not simply plugging Claude Code to your database and ask it questions.
You are probably familiar with the term AI slop, but have not encountered Analytics slop? If you haven’t, let me tell you what this is. Armed with Claude Code, anyone can now ask Claude to connect to a database and produce analytic reports.
On one side, this is amazing, as the barrier of entry to data analysis lowers. On the other… well, on the other no one is checking the produced numbers. Absolutely not a single person that has recently sent me an .html dashboard, confluence page or screenshot of their terminal, has checked that the numbers are right.
And all of this is because of the false sense of security that because LLMs are great at translating English to a given language (for example SQL for analytics), then the answers must be right.
Let me break it to you, but that is far from true. If you reduce agentic analytics to query generation, you narrow the problem too early. You ignore the infrastructure that determines whether the answer is useful or dangerous. Anthropic's own architecture and their stack puts data foundations, sources of truth, skills, and validation ahead of the moment when Claude ever touches a query.
This last part is what I believe Anthropic contribution with their post really shines. They explicitly call out old school data engineering practices as a must have, and also, some key lessons learnt for the rest of us to not repeat.
If you are interested in Agentic Analytics, I will break down Anthropic’s post for you to take advantage of.
Where can you find the blog post?
How Anthropic enables self-service data analytics with Claude
This is an Anthropic blog post published on June 3, 2026, under the Enterprise AI category. It is not a research paper, but it is one of the clearest production write-ups I have seen on what trustworthy agentic analytics actually requires in practice.
What will we cover in this post?
Why do so many teams reduce agentic analytics to text-to-SQL? — Why the category keeps getting framed around query generation, and why that breaks.
Why is data ambiguity the real problem in analytics agents? — Why analytics fails before syntax fails, and why business meaning dominates the risk surface.
What did Anthropic actually build for self-service analytics? — The architecture behind the 95% accuracy numbers: data foundations, sources of truth, skills, and validation.
What does an Agentic Analytics stack need before it writes SQL? — The data engineering layer that shrinks ambiguity before the agent starts exploring.
Why is the semantic layer the analytics agent’s map? — Why governed definitions, grain, joins, and source priority do more for quality than another prompt tweak.
Why do skills change the accuracy story? — Why procedural knowledge matters so much, and why Anthropic’s biggest accuracy jump comes from there.
Why do evals and maintenance matter as much as prompts? — Why drift, provenance, offline tests, and correction loops are part of the product.
What should data teams do if they want Agentic Analytics now? — A practical starting sequence for teams that want to move without building a cathedral on day one.
Let’s begin!
Why do so many teams reduce agentic analytics to text-to-SQL?
Teams reduce agentic analytics to text-to-SQL because query generation is the part you can demo and try in 30 seconds.
→ Ask a question in plain English.
→ Watch the model generate a query.
→ Run it against the warehouse.
→ Return a number or a chart.
The interaction looks magical, and for a moment it feels like the analytics layer has been solved. I mean, can you imagine how do non-technical people feel when they can get answers at the tip of an English question? Even more, when, in the past they required a data analytics team or pre-built dashboards?
However, whilst it can feel magical, none of the numbers and sound explanation coming out of Claude or Codex prove that the business question was answered correctly. Anthropic names the trap directly: pointing Claude at a warehouse can create a false sense of precision.
Let me give you a specific example. Assume a stakeholder asks:
"What was active customer revenue last month?"
Here is where the analytic nuances begin:
What counts as active?
Which customer definition is official?
Gross revenue or net revenue?
Which date field?
Which refunds, fraud filters, or product exclusions apply?
As you can see, the text-to- SQL comes after those choices. Therefore, the only way to run reliable text-to-SQL agents is to build a whole infrastructure around them to guide their understanding of your business (more details on this later).
Why is data ambiguity the real problem in analytics agents?
I have been answering this questions for a long time. In fact, this sort of question was the main anchoring point of a legendary Google paper about Hidden technical debt in Machine Learning systems, where they describe how a Machine Learning model is just a very tiny part of the whole ML in production.
We could take this line of thought and apply it to data ambiguity in analytic agents, and replacing the small black box with the text-to-SQL.
Anthropic’s answer to this question is also very aligned to this:
“Data is not software”
Analytics work fails differently to software features. For example:
There is often 1 correct answer from 1 correct source, yet no deterministic way to prove that answer is correct from the final output alone.
The system can write perfect SQL and still miss the business meaning entirely.
Anthropic provide a more detailed set of examples comparing both paradigms which I found quite useful.
I also compiled some that bring the same idea with a different set of questions.
What are the 3 risk or failure modes for analytics?
The categorisation of these 3 modes comes from Anthropic’s blog post, where they differentiate the modes the following way:
Concept/entity ambiguity. The user says “active users” or “revenue” or “retention,” and the agent has to choose among multiple plausible implementations. Those choices are often subtle enough that the wrong answer still looks professional.
Data staleness. Tables, business rules, and documentation change. A metric that was valid three weeks ago becomes quietly wrong after a schema change, a new exclusion rule, or a dashboard rewrite.
Retrieval failure. The right answer exists somewhere in the stack, but the search space is too large. The model misses the correct table, metric, or document and confidently builds on a near miss.
The warehouse alone is not enough. Warehouses store data. They do not automatically store the full meaning of the business. That meaning lives across metric definitions, semantic models, caveats, human conventions, ownership, and historical context.
Think again about the simple question from earlier: “What was active customer revenue last month?” The hard part is not producing a GROUP BY. The hard part is deciding whether “active” means one purchase in the last 30 days, non-fraud paid usage in the billing period, or some domain-specific threshold defined in the semantic layer and nowhere else.
Therefore, the interesting question, then, is not whether Claude can write SQL (it can probably write it better than you or me). The interesting question is what Anthropic had to build around Claude so those problems stopped dominating the outcome
What did Anthropic actually build for self-service analytics?
The answer is that they mixed old-school proven engineering practices with extra layers of what agents can do. But basically, this still built a full system around Claude to enable analytics (or if you prefer, with Claude at the front if you visualise the system with Claude being the interface layer and the system living underneath it).
The article organizes that system into 4 parts.
First come data foundations: canonical datasets, data models, transforms, tests, freshness checks, and metadata.
Then come sources of truth: the semantic layer, lineage, business context, and curated reference material that helps the agent map a question onto governed meaning.
Then come skills: domain procedures that tell the model how to work, not just what data exists.
Finally comes validation: offline evals, online checks, provenance, and maintenance loops.
Notice where SQL sits in that sequence: downstream of all the hard decisions. By the time the model writes a query, the stack should already have narrowed what the question means and which governed path deserves trust.
That stack explains the headline result better than the model choice does. Read the 95% accuracy figure quickly and it sounds like a model benchmark. Read it carefully and it is a systems benchmark. Their article spends far more time on the harness around Claude than on Claude itself.
With this in mind, we are going to cover specific elements of this stack in more detail throughout the rest of this blog post.
What does an Agentic Analytics stack need before it writes SQL?
Anthropic is explicit that standard data engineering still applies: Dimensional modelling, freshness & completeness checks, consumption-ready canonical datasets, clear data dictionaries, etc. None of that disappears because the interface becomes conversational.
If anything, because the consumer is now an agent (via a human question), the stakes increase. A human analyst can sometimes smell that a table looks wrong, but an agent can scale a bad assumption much much faster.
It is so “funny” to read that the frontier companies are explicitly telling the world that good old data engineering practices are essential for agents to perform well. I find it a bit pejorative to describe these point below, because these are not new fancy things that are being described. You can take any 20 year old book on data warehouse management and find the same answers. But, anyway, it is still positive to remember them.
Canonical datasets
These datasets reduce the number of plausible answers before retrieval begins. By having fewer, more heavily governed logical models, then this small set of canonical, single source-of-truth datasets are the foundations for any analytics stack.
You might need different levels of aggregations, but these roll-up aggregations will always read from these small set of single source of truth. The same applies to analytic agents: if they have access to the smaller sets of truth and how they map to different enriched dimensions, then the chances of failure of selecting incorrect data sources reduce drastically.
Treat metadata as a first-class product
Metadata gives the agent a usable description of tables, columns, grain, owners, and caveats. If you don’t spend time describing well your data model, what each column means, what is the lineage (or joining keys) index… then the LLM will make lots of assumptions.
Colocating models, docs, dashboards, and skill files
This is quite interesting, because co-location could perfectly mean having bigger monolithic repo or lots of artifacts living close to each other in the system. Anthropic’s statement defines it really well: “Nearly all data code (i.e., modeling, semantic layer, reference docs, canonical dashboard definitions) lives in a single repo, with CI checks that protect cross-layer integrity. If a modelling change would break a downstream dashboard or invalidate a documented metric, CI flags it and the fix ships in the same PR.”
As you can read, I do not buy the lazy narrative that AI analytics will make data engineering less important. As more questions get routed through models, the quality of the modelling layer becomes more visible, not less.
That pattern shows up outside Anthropic too. The dbt Semantic Layer exists to centralize metric definitions and make them reusable across tools. Microsoft's Power BI guidance for Copilot recommends AI-ready schemas, verified answers, and explicit instructions so the model has grounded context before it responds. Even Snowflake's Cortex Analyst architecture leans on semantic models, verified queries, and monitored behavior around the SQL generation layer. Different products, same lesson: prepared context is part of the answer.
Why is the semantic layer the analytics agent’s map?
First of all, what is a semantic layer when dealing with data?
Well, a semantic layer is an architectural bridge that translates raw, complex data into familiar business terms, metrics, and relationships. The semantic layer sits between your data storage (data warehouses like Snowflake, Databricks, or BigQuery) and your consumption tools (BI platforms like Power BI/Tableau, or AI agents).
