Anthropic recently published an unusually candid look at how it uses Claude to enable self-service analytics across its own organization.
The headline numbers are impressive. Anthropic reports that approximately 95% of business analytics queries can be automated through Claude with roughly 95% aggregate accuracy.
But the most interesting part of the story isn't Claude.
It's everything Anthropic had to build around Claude to make those results possible over a period of many months.
Anthropic reached a conclusion that should matter to every enterprise pursuing AI analytics: simply connecting a powerful AI model to a data warehouse or data lake isn't enough. In fact, doing so can create what Anthropic describes as a "false sense of precision."
The fundamental problem isn't whether an AI model can generate SQL.
Modern AI models are already remarkably good at that.
The harder problem is whether the AI understands the business well enough to know what SQL it should generate, which data it should use, and what the resulting numbers actually mean.
Anthropic characterizes analytics accuracy primarily as a context and verification problem rather than a code-generation problem.
That distinction changes the architecture required for enterprise AI analytics.
And it raises an important question:
If one of the world's leading AI companies needed to build an extensive semantic and knowledge foundation around Claude to make analytics trustworthy, should every enterprise have to build that foundation themselves?
The Hard Part Isn't Generating SQL
Consider a seemingly straightforward question:
"What was revenue growth in the Western Region last quarter?"
Generating SQL for that question might be relatively simple.
Understanding the question isn't.
- What exactly constitutes revenue?
- Is it bookings, recognized revenue, invoiced revenue or collected revenue?
- What constitutes the Western Region?
- Which date determines the quarter?
- Are returns included?
- Are intercompany transactions excluded?
- Which customer hierarchy should be used?
- Which source system is authoritative?
- Which tables should be joined?
These aren't SQL questions.
They are business-context questions.
Anthropic describes a similar challenge as concept-to-entity ambiguity. An enterprise may have thousands of tables, datasets and analytical artifacts that could plausibly relate to a question.
Once an AI system maps the user's question to the correct, current business entities and understands how those entities should be used, generating the SQL becomes comparatively straightforward.
That's an important realization.
For years, much of the conversation around AI analytics has focused on improving text-to-SQL.
But increasingly, SQL generation isn't the bottleneck.
Business meaning is.
More Context Doesn't Necessarily Solve the Problem
A natural response is to give the AI access to more information.
More schemas. More documentation. More historical SQL. More metadata. More dashboards. More context.
Anthropic's experience suggests this isn't sufficient either.
In one experiment, Anthropic gave its analytics agent access to thousands of historical SQL files. The additional information improved accuracy by less than a percentage point, even though the information necessary to resolve many failed questions was reportedly somewhere in those files.
The problem wasn't simply whether information existed.
The problem was whether the AI could reliably identify which information was authoritative and relevant to the question being asked.
This distinction becomes critical for enterprise AI.
There is an enormous difference between giving AI access to context and giving AI access to governed context.
The first gives AI more information to reason about.
The second tells AI what the organization has determined to be trustworthy.
What Anthropic Actually Built Around Claude
Anthropic's architecture reflects this realization.
Its analytics environment includes canonical data foundations, sources of truth, semantic definitions, business context, skills, validation and evaluation mechanisms.
Source: Anthropic
Perhaps most significantly, Anthropic instructs its analytics agents to use the semantic layer as the default path for answering data questions, rather than simply allowing Claude to independently navigate raw warehouse structures.
Think about the implication.
One of the companies building the world's most sophisticated AI models concluded that the model itself wasn't sufficient for reliable enterprise analytics.
It needed a governed semantic foundation.
That should be an important signal for every organization building AI analytics.
But it also raises another question.
Anthropic has exceptional AI, data engineering and data science resources.
Most enterprises aren't trying to become AI infrastructure companies.
They want trusted AI analytics.
Should they really have to assemble all of this infrastructure themselves?
Before You Can Govern Business Knowledge, You Have to Find It
There's another problem that semantic-layer architecture diagrams tend to make look deceptively easy.
They show:
Enterprise Data → Semantic Layer → AI
But where does everything inside the semantic layer come from?
Technical metadata is relatively straightforward. Software can inspect a database or cloud data platform and discover schemas, tables, columns, data types, keys and relationships.
Business knowledge is much harder.
It is scattered throughout the enterprise.
- Some exists in databases and operational systems.
- Some is embedded in BI dashboards as calculations, measures, filters, groupings and derived fields.
- Some lives in PDFs, SharePoint, Confluence, data dictionaries, policies and operating procedures.
- And some of the most valuable business knowledge exists nowhere except in the heads of subject-matter experts.
Ask a database what an "active customer" means and it can show you tables and columns.
Ask a sales operations expert and you may hear:
"It depends. For enterprise accounts we use trailing 12-month revenue, but channel accounts are considered active if..."
That nuance is business knowledge.
And if it has never been systematically captured, an AI system can't reliably reason with it.
Knowledge Discovery Should Be a Product Capability
Historically, organizations have solved this problem manually.
Data architects interview business experts. Consultants conduct workshops. Analysts inspect dashboards. Teams review documentation. Someone creates a glossary. Someone else maps business definitions to physical data.
Eventually, the organization produces a semantic model.
The problem is that the business immediately starts changing.
- New products appear.
- New data sources are introduced.
- Reports change.
- Calculations evolve.
- Business rules are modified.
- Acquisitions introduce entirely new systems and terminology.
- Subject-matter experts discover better ways to measure the business.
The semantic model slowly begins to diverge from the organization it is supposed to represent.
That's why Codd AI approaches knowledge discovery differently.
Rather than treating discovery as a one-time implementation exercise, we believe it should become a repeatable product capability.
Codd AI's Discovery capabilities use specialized agents and scanners to systematically discover knowledge from multiple sources. That knowledge is then analyzed by AI to identify possible duplications or contradictions, and certified before it is used in the semantic layer.
- Database and system scanners can discover technical structures and relationships.
- BI scanners can inspect analytical assets to identify calculations, measures, filters and business logic that may never have been pushed back into the underlying warehouse.
- Document discovery can extract business definitions, policies and rules from enterprise knowledge sources.
- SME-driven discovery can capture the institutional knowledge that doesn't exist in any system at all.
Once certified, these provide a much richer representation of how the business actually operates.
Discovered Knowledge Is Not Automatically Useful
Discovering business knowledge doesn't automatically make that knowledge authoritative.
Imagine that discovery identifies four definitions of "active customer":
- A database implementation uses one definition.
- A Power BI report uses another.
- A business glossary contains a third.
- A sales operations SME describes a fourth.
That isn't necessarily a failure of discovery.
It's one of its most valuable outcomes.
The organization already had a semantic conflict. It simply couldn't see it.
AI can help identify these inconsistencies, propose relationships and surface candidate definitions.
But it shouldn't silently decide which definition becomes enterprise truth.
The other potential big issue with knowledge discovery is that there could simply be too much of it. As mentioned earlier, more knowledge is not always helpful. There is a critical role for analyzing, reconciling and certifying what is authoritative and should be used, and deciding what to discard.
Codd AI follows a simple model:
AI accelerates the process. Humans remain responsible for determining what becomes authoritative.
This creates an important middle ground between two extremes.
Manually building every semantic artifact doesn't scale.
Allowing AI to autonomously invent enterprise semantics isn't sufficiently governed.
The alternative is AI-generated, human-certified business context.
Metrics Should Be an Output of the Semantic Foundation
This also changes how we think about metrics.
Many semantic-layer implementations begin with a metric:
How do we define gross margin?
Then another:
How do we define customer retention?
Then another.
The risk is creating a metric-definition factory where context has to be repeatedly reconstructed for every new analytical requirement.
Codd AI approaches the problem one level higher.
First establish the business concepts: Customers. Products. Orders. Regions. Suppliers. Channels.
Then establish the relationships between those concepts and how they map to the physical data.
Add the relevant business rules, definitions, terminology and policies.
Review and certify that foundation.
Now metrics can be generated from a shared understanding of the business.
In other words:
Metrics aren't the semantic foundation. They are outputs of the semantic foundation.
That's an important distinction if enterprises expect AI analytics to scale from dozens of curated dashboards to potentially thousands of dynamically generated analytical questions.
The Semantic Foundation Can't Be Static
There's another consequence of productizing knowledge discovery.
You can repeat it.
Traditional semantic projects often follow a familiar lifecycle:
Discover → Model → Deploy → Done
But there is no "done."
The enterprise continues changing.
If the discovery process depends on consultants, workshops and manual documentation, continuously repeating it becomes prohibitively expensive.
Software-driven discovery changes the economics.
- A database scanner can run again.
- A Power BI environment can be reinspected.
- Documents can be reprocessed.
- Changes can be compared with the existing certified knowledge base.
- SMEs can be brought back into the process when the system identifies ambiguity, new concepts or conflicting definitions.
The lifecycle becomes:
Discover → Model → Certify → Monitor → Rediscover → Detect Change → Review → Recertify
This transforms the semantic layer from a static representation of the business into something much closer to a living knowledge foundation.
And that may ultimately be the bigger challenge.
Building a semantic layer is difficult. Keeping it synchronized with a business that never stops changing is harder.
Claude Should Use Your Business Context. It Shouldn't Own It.
Anthropic understandably designed its internal analytics architecture around Claude.
Enterprises face a different reality.
Their AI landscape will be heterogeneous.
- Claude may answer some questions.
- ChatGPT may power other experiences.
- Power BI may serve thousands of business users.
- Custom applications may access analytics through APIs or MCP.
- Autonomous agents may eventually use the same business knowledge to initiate actions.
The organization's semantic knowledge therefore shouldn't belong to any particular AI model.
Your business context should outlive your choice of AI.
This is another reason Codd AI separates the contextual semantic foundation from the reasoning engine consuming it.
Build the business context once. Certify it. Govern it. Keep it current.
Then make it available to Claude, ChatGPT, BI tools, AI agents and whatever comes next.
From Trusted Context to Trusted Reasoning
Even that isn't the end of the problem.
A governed semantic foundation can ensure that "Gross Margin" means the same thing every time.
But consider a more complex request:
"Analyze gross margin versus actual sales for the last three quarters. Identify the three best- and worst-performing product categories, explain the primary drivers, and recommend promotions based on what has worked in the strongest regions."
Now AI isn't simply retrieving a metric.
It is reasoning.
It may execute multiple analytical steps, investigate different dimensions, compare results and determine which evidence matters.
Ask the same question tomorrow and an unconstrained AI agent may choose a different reasoning path.
That introduces another layer of enterprise trust.
Codd AI's Playbooks provide a mechanism for capturing and reusing approved analytical reasoning patterns so that important analyses don't have to be reinvented every time.
The enterprise AI trust stack therefore begins to look something like this:
Trusted Data → Trusted Business Context → Trusted Metrics → Trusted Reasoning → Trusted Actions
AI models operate across this stack.
Anthropic Got the Architecture Right. Now Enterprises Need to Operationalize It.
Anthropic's experience provides an important lesson for enterprise AI.
Better models alone won't solve trusted analytics.
AI needs governed data, semantic context, business knowledge, skills and validation.
But enterprises face an additional challenge.
They need a systematic way to discover that knowledge, determine what is authoritative, keep it current, and make it reusable across every AI experience.
That's why the next generation of enterprise AI infrastructure needs to go beyond simply creating a semantic layer.
It needs a living knowledge foundation: one capable of continuously discovering how the business works, identifying what has changed, enabling humans to certify what is true, and delivering that trusted context to whatever AI system needs it.
Claude should be able to use that context.
So should every other AI system the organization adopts.
Because ultimately, the durable enterprise asset isn't the model.
It's the organization's understanding of its own business.
About Codd AI
At Codd AI, we believe enterprise AI should reason from a shared, trusted understanding of the business, not from isolated prompts or disconnected data sources. Our AI-powered contextual semantic layer combines technical metadata, business knowledge, governance, and human certification into a reusable enterprise foundation for conversational analytics, AI copilots, and agentic workflows.
By helping organizations capture and govern business context once, Codd AI enables every AI and BI application to deliver more consistent, explainable, and trusted insights, today and as the AI landscape continues to evolve. To learn more, visit us at www.codd.ai or schedule a conversation with one of our co-founders.