Over the last 3 months, we have had significant breakthroughs in terms of accuracy, adoption, and value using Snowflake AI BI Agents with Claude. Now, BI is grounding for AI, and AI helps work through the next wave of BI dashboards when new signals and initiatives are created.
For this article, we ignore developer/builder workstreams because the configuration, use cases, and success drivers are completely different. However, the work discussed in this article dramatically improves those workstreams.
Why Use Claude with Snowflake?
We have started deploying business/data analysts to support ad hoc analysis use cases with Claude as the end-user interface. The early observation is 50–70% fewer BI report, dashboard, and analysis requests.
Claude serves as a business-context-loaded layer that connects with Snowflake agents loaded with the same business context but scoped to deliver the right answer to the question. The magic of Claude for business delivery is:
- Memory and recall
- Connectivity from Claude out to other tools and services
- Delivering live insights where work happens in enterprises that have rolled out Claude for Business
- Claude’s multimodal experience
- End-user-produced artifacts
The results have been very good, so this article serves as a point-in-time retrospective to share what is working as of June 2026. What changed for us in Q1 and Q2 is our opinion and experience that Snowflake, as a foundation layer, is delivering the structure and confidence required to monitor and maintain production agents.
Most importantly, the process for end users and engineers to deliver, maintain, and enhance agents is becoming more structured, governed, and statistically evaluated as things evolve.
Why Use Snowflake Cowork?
We are constantly evaluating Snowflake Cowork (previously Snowflake Intelligence) for production readiness with our clients. Currently, we are testing Cowork for specialized work and sensitive areas where we do not want Claude accessing data.
Our vision for Snowflake-delivered agents is augmenting existing work where analytical, predictive, and data-intensive activities need to happen seamlessly. Snowflake’s vision of dropping end users into Cowork is something we still need to see work in production.
Snowflake Semantic Layer is the Foundational Layer for AI Analysts
That is not commentary on the state of the entire data, analytics, and AI market. It is a statement for enterprises that have selected Snowflake as a core data hub and platform.
The Snowflake Semantic Layer is a centerpiece of AI agent activation and where real work is required for refinement. AI’s role in the semantic layer is dangerously overstated.
If you get the semantic layer wrong, you will be perpetually “in development” while trust and patience for your new AI agents evaporate. If you get the semantic layer right, you have constructed a new foundation to manage and monitor AI analyst adoption.
Remove fact and metric naming and definition ambiguity –
Two facts labeled similarly in your semantic layer are a mistake waiting to happen. In particular, your fact tables should strip away as much ambiguity as possible.
For example, a field “Leads” and “All_Leads” should not exist within the same semantic model. Decide which fact or metric powers 80%+ of decisions and, if necessary, create a dimension that can break down the fact for the remaining 20%.
The same principle applies to dimensions. State and State_of_Incorporation are bound to get mixed up. You may need both in a dimension table for BI, but for AI agents today, we recommend focusing on what is most important until we can prove with 99% certainty that the agent is not going to mix these concepts up. If someone has figured this out, please share.
Provide clear business semantics and context – Definitions need enough depth to explain concepts to both people and agents. This is where AI-Inferred semantic views fall flat, and where you need to methodically organize and structure context within your semantic view.
Review and commit recommended queries/questions –
This function is the primary reason we have the ability and permission to run Snowflake Semantic Layer in production.
The telemetry Snowflake scans to surface recommendations, combined with our ability to review questions and execution within agents, is a great start. We now have visibility and the ability to demonstrate how usage can facilitate improvement.
That improvement is governed and deployed by analytics teams, analysts, and SMEs working alongside AI copilots.
Business Semantics Management This is the keystone to our success deploying agents. We have our own DataTools Pro application (not publicly available) that helps us manage and automate business semantics and semantic disconnects systemically. When we deploy a semantic view in Snowflake, we currently blend data semantics and business semantics.
OSI has helped us establish a standard to validate against as we connect our business semantics repository to Snowflake semantic views.
What’s Different with Snowflake Semantic Layers vs. BI Semantic Layers
This is one area where our DataTools team is highly opinionated. Data semantics do not originate from your data tables. They may originate from pre-existing semantic layers being migrated into Snowflake. They may originate from design documents created during the scoping process for your existing BI delivery framework. They may even be inferred directly from existing BI assets such as dashboards.
We do not recommend using AI inference on data tables to directly identify and label semantics. A semantic layer is intended to assign business context and meaning to data.
The objective is to reduce ambiguity, establish canonical definitions, and close alignment gaps with business semantics. AI can easily distort your semantic layer, so we recommend engaging the right teams and subject matter experts. A one-click semantic layer is a function designed to sell software, not deploy production-ready semantic models.
Migrating a BI semantic layer does not necessarily translate well into a Snowflake semantic layer. There are often artifacts within BI semantic layers that are riddled with problems and technology-specific dependencies. These are irrelevant and likely to introduce downstream issues. That said, migration can eliminate 50–80% of the work.
AI-Inferenced Data Semantics vs. SME-Led Semantics
This is one area where our DataTools team is highly opinionated. Data semantics do not originate from your data tables. They may originate from pre-existing semantic layers being migrated into Snowflake. They may originate from design documents created during the scoping process for your existing BI delivery framework. They may even be inferred directly from existing BI assets such as dashboards.
We do not recommend using AI inference on data tables to directly identify and label semantics. A semantic layer is intended to assign business context and meaning to data.
The objective is to reduce ambiguity, establish canonical definitions, and close alignment gaps with business semantics. AI can easily distort your semantic layer, so we recommend engaging the right teams and subject matter experts. A one-click semantic layer is a function designed to sell software, not deploy production-ready semantic models.
Migrating a BI semantic layer does not necessarily translate well into a Snowflake semantic layer. There are often artifacts within BI semantic layers that are riddled with problems and technology-specific dependencies. These are irrelevant and likely to introduce downstream issues. That said, migration can eliminate 50–80% of the work.
Activating Claude with Snowflake – Start Simple and Stay Simple
Every new technology solution starts simple and grows over time. Stating “start simple” is obvious. Staying simple, and designing for the future instead of prematurely trying to build it, is where teams encounter problems. Things are moving too quickly, and the future is not yet baked into the tools we use.
If you are trying to figure out how to connect Claude to Snowflake, start by building one analyst agent for one line of business. Ground everyone on understanding:
- Where are we?
- How did we get here?
- What should we do next?
Demonstrate that capability for one well-understood area of your business, and you have a foundation. We have found the best route is an agent grounded on pre-existing, trusted business intelligence assets.
Our Approach for Assembling Agents
Our approach to AI agents mimics building optimal team players.
It is one where:
- Business semantics are universally understood
- Overlap of experience is sufficient to allow seamless transitions of understanding
- Disciplines and problem-solving lenses are different enough to create valuable perspectives
- Groupthink among agents and users occurs around the objective function and measurements
- Analysts and builders are responsible for calibrating, refining, and facilitating semantic and context assignment
This article does not cover the specific arrangement of skills and context resources. That will be discussed in a future article because it is always a work in progress.
Building Success with Feedback Loops
We recommend conducting live labs with business users to observe and learn, but also to explain the best path to success for maximizing both Claude and Snowflake.
The structure and functions of Claude and Snowflake are not necessarily optimized for analyst work, so we have found the following practices helpful:
- Use Claude Projects to keep cross-conversation context in one place, even if it is a private project.
- Build good habits and processes to capture knowledge and experience.
- Create a skill that captures knowledge and conversation telemetry so information is retained and success can be measured over time.
Security and Access
When you connect Claude to Snowflake, you are treating Claude as a data processor for Snowflake. Many enterprise governance functions will not support this use case, and rightfully so. If you do not have tight governance and controls over your Snowflake instance, you can create significant risk for your organization by connecting Snowflake to Claude.
Before starting, we typically re-share the Claude for Business DPA along with a detailed security model. We recommend creating a dedicated Claude role and narrowing OAuth scope to that role. We also recommend limiting data and agent access to the same role. This approach introduces nuanced friction points that are beyond the scope of this article.
Measuring AI Adoption and Utility Success
Tracking adoption and usage patterns for AI is different than a traditional app. Here are a few ideal metrics.
Time of Analysis – How long is the session? If your users run out of context in a conversation using Sonnet, you are doing something right… We started tracking this for live-labs.
Time to First Redirect – How long does the user converse with the agent until an issue is discovered requiring a redirect? We have not been able to replicate this outside of a lab setting.
Number of Redirects – How many times in a session does the user not get their desired result?
Agent vs. SQL Requests – We configure Claude to interface with Snowflake agents as priority. A fallback is a direct connection to the underlying semantic view. I have found that missing data points, ambiguity, or semantic disconnects are the primary reason for the fallback.
What’s Next
There are many technology tools, platforms, blueprints, and anecdotes for how to successfully build and deploy effective agents for data analysis. We found that Snowflake and Claude together provide the right combination to introduce the first wave of AI analysts for multiple enterprises. As we find new techniques, tools, we will share here.
