Skip to main content

Closing AI BI Chat Loops in Snowflake for Conversational Analytics

There are no shortcuts to building trust and momentum with AI BI. In this article I frame and explain the processes I built around Claude and Snowflake to enable production conversational analytics. Building an AI agent is easier when you already have a BI foundation to build on top. An existing Business Intelligence foundation already carries some context, lots of connections, and curated understanding that can take years to form for most companies. It also carries a lot of bloat, ambiguity, and bad habits that can carry over into your AI agents and produce the same traps for failure.

When successful in production setting, I found that 70% of the BI reporting and dashboard requests went away. The remaining 30% is a new class of reporting and dashboard request, where traditional BI tools fall apart at the seams. This is one of many “loops” with analytics builders and information consumers that wont reveal itself until you have real adoption.

Challenge 1: Cyphering “Good” Context

The hardest part to produce meaningful conversational analytics is cyphering and delivering “good” context from existing artifacts while adding more depth. That work is a careful balancing act where ambiguity lives. Some ambiguity is needed for human understanding and can poison AI in a real conversational analytics workflow. That is work that I have been obsessed with as part of traditional BI.

Challenge 2: Prioritization and not repeating business intelligence

Delivery and adoption has always been a challenge and a well known black eye for Business Intelligence. The dashboard backlash we see online is a function of technology offering digital hammer and nails to create descriptive statistics and narration for those statistics. There are many anecdote and stats, but the work I do at BIChart has taught me 30-50% of dashboards that sit inside of your platform are probably un-used. To get started, I selected a widely adopted and trusted BI dashboard as the grounding exercise for the first generations of agents. On average 30% of what existed in my dashboard didn’t need to exist in my semantic layer, which is why I abandoned importing BI assets into Snowflake (though it is a very cool feature).

Objectives

Agent Objective – My approach to AI agents is starting with individuals who make 6 and 7 figure decisions regularly. An agent that helps with creating understanding breadth and depth of topics that influence those decisions are more impactful. I don’t believe agents that save clicks and minutes or even hours require conversational analytics.

Agent Delivery Objective – The time and cost to build conversational analytics with that kind of adopgent lifecycle management is a CI/CD and governance exercise, not a BI delivery exercise, and that difference is what breaks me through the historically high BI project failure rate.

An Agile BI Foundation

BI architects build durable systems meant to answer a wide range of questions, including ones not yet asked. Semantic models give builders, and now LLMs, coverage, context, and a declarative path into governed data. All of that work is extremely important. A dimensional model should exist for foundational metrics for which an enterprise is built around.

From that foundation comes the need to understand business events and dynamics at the speed it occurs. That tension between a tightly governed structure and a continuously evolving business that operates on top is imperfect by design.

The data platform I have used for the last year is Snowflake. In small enterprise I setup a mono-repo that holds:

  • dbt transformation pipelines / process
  • dbt models (fact and dimension tables, business views / marts)
  • snowflake semantic models
  • tests / validation
  • artifacts for skills
  • a version controlled metrics glossary (managed from DataTools Pro)
  • docs
  • continous integration code

Framing Real Conversations in Conversational Analytics

The conversation between a user and an AI agent should stay a private, user-controlled space for exploration, ideation, and iteration. Users need room to ask questions, test ideas, bring in their own data, and work through half-formed or sensitive thinking, without assuming the full history becomes visible, or worse, becomes context for someone else’s session. For executive users this is a governance problem you know, especially at a public company. That conversation history can carry strategic initiatives, partnership terms, trade secrets, and other need-to-know risks.

That underling data and resulting analysis work still has to follow governance policy. Access to it matters as much as access to the underlying data itself. Too little attention goes to what sits inside “context” and the conversation logs it produces.

Participation and training users to make effective use of this powerful conversational analytics tool cannot be under-stated. To get access to Claude + Snowflake for me, requires a mandatory 1 hour lab session. The impact and influence on decisions drives the population who get access. This observation period is how everyone in the room learns and how I designed my feedback loops to scale this process.

Instead of treating the conversation itself as feedback, the Chat Feedback Skill closes these loops automatically. It helps the user build a deliberate representation of the session and submit it on purpose. The agent’s Chat Feedback Tool receives that submission and processes it as feedback. Keeping the private workspace separate from the intentional feedback artifact preserves psychological safety and governance. It still gives users a direct, structured way to help improve the agent.

Closing the Decision Loop: Embedded AI BI Where Conversations Occur and Work Happens

Adoption comes down to one thing: embed analytics where people already work. Logging into a BI portal is a vendor-prescribed experience, and at best I’d call it barely tolerable. At organizations that have adopted Claude for Business, I have watched the way of working actually shift. That will keep evolving, and Claude will likely end up a stepping stone toward whatever comes next, not the final destination.

Semantics over Semantics

No one can agree on what a semantic layer, agent, context layer, or what tools and standards to use. Plenty of prescribed arrangements apply semantics to data and context for interpretation and inference. I don’t address any of these things in this article. The perfect arrangement, right information to the right person, is still not enough. The minute your AI agent goes into the wild none of the semantic matter if the agent does not deliver value.

The Outer loop: Understanding to Action

The understanding to action loop looks something like this…

  1. Information seeking motion requires data and analysis of events, prior actions and outcomes.
  2. Data and analysis curated to create understanding.
  3. Understanding requires context take action.
  4. If consensus or authority is needed for action, an artifact explains the new understanding.
  5. Communication and authority carries the directive and action occurs.

An AI agent (I use agent generically) is an incredible tool to help decision makers move faster through this loop, with thin semantics and narrowly scoped data access. That’s the standard conversational analytics demo. The problem shows up after the demo ends: the action lives in memory, and the data platform stays disconnected from it. There are many approaches to help integrate these decision loops with descriptive statistics in a LLM powered experience. Vertical integration with embedding agents inside of Slack and Teams is one tactic that I think will play a big part to activate these decisions.

Vendors that are audacious to claim they have solved this loop with AI, pre-built knowhow packaged up a skills, and a slick UI are probably setting you up to fail. Building conversational analytics is an exercise of curating context, packaging the collective knowhow and continuously improving and refining that process along with your technology vendor’s own advancements.

Snowflake Semantic Layer

My early success didn’t require a semantic layer, mostly because I had built very strong context artifacts, specifically a highly detailed metrics glossary. A big part of my early success was my long standing obsession as a BI practitioner for documentation and removing myself from being an owner and knowledge gatekeeper. It turns out that natural way of working lends itslef well to delivering context to LLMs. Here is the natural evolution of my semantic model delivery to AI agents that starts 18 months ago.

Gen 1- Claude + CSV files (from Snowflake export) and metrics glossary and prompt
Gen 2 – Claude + CSV files (from Snowflake export) metric glossary, ontology (entities), information categories and analysis
Gen 3 – Claude + Agent Skill (industry summary) + CSV + (from Snowflake export)
Gen 4 – Claude + Agent Skill + Cortex Skill + Snowflake Semantic Layer + CI-CD + first evaluation
Gen 5 – This article covers where I landed in my Gen 5 configuration as I work on the next evolution.

My finding overall experience is the traditional BI and and semantic layers delivery model is not enough to deliver and evolve analytics at the speed business leaders want to move.

  1. Semantic layers offered across most platforms still don’t have the depth, nor the curation capabilities to scale conversational analytics agents beyond the simple and basic foundations.
  2. Understanding conversations require capturing the entire context of a conversation without storing the entire conversation itself. The reality is work happens in Claude, Chat GPT.
  3. Delivery and training of agents is not the same as apps and BI dashboards

Closing the BI on AI Data, Semantics, and Context Loop in Snowflake

Instead of framing every component in my process, here’s a schematic of 2 context loops I have built: This is the contextual shape of my AI BI delivery heading into Q4 2026. It will look different again by Q1 2027 as Snowflake, Clade. 100% of this can be built with Claude and Snowflake and no third party technology.

Conversational Analytics

Understanding Adoption and Utilization: The Data Loop with DataTools Radar

Snowflake ships a strong set of observability tools. Observability gives a structured, narrowly scoped replay of what happened inside Snowflake. That raw data carries real value, but not the direction needed to actually improve the conversational analytics experience. Snowflake’s foundation is flexible enough to build a bespoke layer on top, tuned and contextual. To turn that into actionable intelligence, I built DataTools Radar, which is a simple Streamlit app that runs inside of Snowflake. It is not a product or a service and the level of effort to build this tool was a couple hours via Claude Code. This first figure gives me an over-arching catalogue of my Snowflake estate based on questions I need answers to.

Automating Recommendations and Remediation

Understanding what happened is nice. Acting on it immediately is the objective function. I measure success by adoption and session utilization. Alongside Snowflake observability, a set of analyst skills pushes real conversational context back into Snowflake through a stored Snowflake stored procedure (added as a tool to my agent).

AI earns its keep here: sifting that context and surfacing recommendations is what lets the right decision makers work the right problems. The “Profiled” questions come straight from real conversations, grouped into 48 recurring topics. That is productized proactivity, something Business Intelligence rarely delivered.

Business Conversational Loop

In my multi-agent setup, the business conversation happens in Claude, because that’s where the work already happens. My job is protecting that flow: masking and filtering anything moving from Snowflake into Claude that shouldn’t leave Snowflake unmasked. I also need real context and knowledge artifacts captured as they’re created. For issues and continuous improvement, a Claude feedback skill redacts and structures the session into a clear feedback loop for remediation. That information gets fed directly into my Snowflake agent where it is committed as part of observability and fed as context into my DataTools Radar.

As you can see, the output gives the analytics engineer actionable guidance directly. So far, 8 out of 10 logs are fed into Claude Code and lead to immediate remediation with no adjustments before landing in my CI/CD process. I have been experimenting with full remediation loops but prefer to have direct contact with enough observations before automating.

What’s Next?

There are other skills listed that I will cover in additional articles that close other critical loops for delivering artifacts, expanding to new topics, routing requests to multiple semantic layers, and how I reconcile / manage metrics and solve the “many revenue” definitions conundrum. As I tell my end users…. This is the worst it’s ever going to be, which says a lot because these agents have been transformational!

author avatar
Ryan Goodman Founder
Ryan Goodman has been in the business of data and analytics for 20 years as a practitioner, executive, and technology entrepreneur. Ryan recently created DataTools Pro after 4 years working in small business lending as VP of Analytics and BI. There he implanted an analytics strategy and competency center for modern data stack, data sciences and governance. From his recent experiences as a customer and now running DataTools Pro full time, Ryan writes regularly for Salesforce Ben and Pact on the topics of Salesforce, Snowflake, analytics and AI.