Snowflake Intelligence: The End of Dashboards?

Your dashboards only answer the questions you thought of last quarter. Every new question is a ticket, a dependency, or a gut call. Snowflake Intelligence wants to fix that -- a chat interface on top of governed enterprise data that turns plain English into SQL, runs it, and gives you a chart back. No analysts involved.

Jelle builds the full setup live: semantic view, verified queries, Cortex Agent, access control. They get honest about what this actually requires -- data quality, governance, and whether Snowflake is worth the cost.

Resources:
- Snowflake Intelligence docs: https://docs.snowflake.com/en/user-guide/snowflake-intelligence
- Demo code: https://github.com/datamindedbe/demo-technology-exploration
---

Click here to watch a video of this episode.
Full playlist: https://www.youtube.com/playlist?list=PLJ_da7qdfL80rA7byzC_CmyrfJWjcCTnb

• (00:00) - Intro & meet Jelle
• (02:04) - What is Snowflake Intelligence?
• (02:54) - Demo: talking to your data
• (10:36) - Where it fits & how it works
• (15:14) - Build: the Semantic View
• (22:37) - Build: the Agent
• (29:20) - Challenges & data quality
• (34:26) - How ETL is evolving
• (40:33) - Will this replace engineers & analysts?
• (43:23) - Is Snowflake worth the cost?
• (45:14) - How do you get started?
• (50:06) - Summary & takeaways

---

Data & AI: Technology Explorations is a biweekly show from Dataminded. Each episode a Dataminded engineer demos a tool or technique worth knowing about -- working code, honest takes, no hype.

Music by Aleksandr Karabanov from Pixabay

Creators and Guests

Host

Jonny Daenen

Head of Knowledge at Dataminded

Guest

Jelle De Vleminck

Partner at Dataminded

What is Technology Explorations in Data & AI?

Deep dives and practical demos on the technologies shaping modern data and AI development. Join the Dataminded team as we explore, unbox, and critically review the latest tools, from building AI agents and RAG systems to optimizing cloud costs and accelerating data pipelines. We cut through the hype to show you what actually works in real data engineering practice, complete with demo code!

Jonny (Intro) (00:00)
Your business users want answers from data. Your data engineers are busy and your dashboards only cover the questions you thought of last quarter. That means every decision you want becomes either a ticket or a gut call. Snowflake Intelligence is Snowflake's answer to that. A chat interface sitting on governed enterprise data that turns plain English into SQL. It runs it, it gives you the data, a chart, and then a decision. No analysts involved.

In this episode, Jelle is going to show us how that works. He builds a live demo, a technical setup, a semantic view, and an agent. We also discuss what is still hard, governance, quality, and access control. My name is Jonny, knowledge lead here at Dataminded, and welcome to Technology Explorations.

Hi everyone, welcome to technology explorations and data minded. In this series, we give you an initial look into new or interesting technologies. And this week's topic is Snowflake Intelligence. And for this, I have invited Jelle. Welcome Jelle.

Jelle (01:09)
Hello, good afternoon, Jonny

Jonny Daenen (01:11)
Jelle, could you briefly introduce yourself? What is your role at Dataminded? What do you do day to day?

Jelle (01:17)
Yeah, so I'm a partner at Dataminded and I'm mainly leading clients building enterprise data platforms. What I tend to do is focus mostly on like the human part. So of course I like building, I'm an engineer, but in the end things only bring value when they're being adopted. So I try to talk to...

to engineers, to scientists, and to get the technical features adopted, but increasingly also more and more to like business users to get them to use data more and also work more on those business features, like giving them Excel access or like what we're going to look at today, which is talking to your data.

Jonny Daenen (01:56)
Yeah, Talking to your data, that's something that is quite hot today, I would say, with all the agentic and AI movements. And today we're going to focus on Snowflake. Could you tell us a bit more or maybe show us immediately what is Snowflake Intelligence?

Jelle (02:10)
Yeah, so Snowflake Intelligence is a quite recent feature they've built. It came out or it became GA, General Available, in November 2025. And the idea is to give your business users a way to ⁓ interact with data without having to write SQL and without needing to have a dependency on your data engineers. So they can ask ad hoc questions themselves, get answers, get visualizations.

Jonny Daenen (02:34)
Yep.

Jelle (02:39)
even share chats directly with colleagues or saving artifacts like a graph to share it. So the idea is to make them more independent from the data engineers and that they can do more than what they can do today.

Jonny Daenen (02:54)
Okay, I would say before we dive into the details, let's have a first look on what this tool can do.

Jelle (02:59)
Yes, so the demo I've prepared today is the data environment of a coffee shop.

So there's about 10 stores located in Belgium. And of course they sell coffees day to day. They also sell chocolates and cookies. So that's all captured in line items. So the data model is quite simple. It looks like this. So you have stores where you save the store name, city, region, when it was opened. It has orders, like what was the payment method, the total amount, the type of customers, and then like the order ⁓ item, which is

each item belonging to that order. So if we can go to Snowflake Intelligence, what you see is immediately like a familiar interface like ChatGPT or Cloud. It's a chat interface. And what you can see is that we have our bean and brew.

⁓ assistant here, which is our agent we have available. If you have multiple agents, you would see multiple of those here. And then you can just simply ask questions. For example, you can ask which product category sells the most or show me the revenue by region over time. So we can do that. And then Snowflake will start thinking, interpret that natural language question and turn that into a SQL statement. So it will turn text into ⁓ SQL.

and it will get that query result ⁓ back and then it will also answer in natural language and it will even create a visualization on the fly if

that is applicable ⁓ to the question. So here you see that we asked the monthly revenue by region. It recognized, hey, this is a nice question to have a visualization on. And there you see it. So it shows me for Brussels, Flanders, and Wallonia what the monthly revenue is. we apparently we have data from July 2024 up until March 2026. And then of course, it also gives you the textual conclusion of

question. So that's what Snowflake Intelligence allows you to do, ad hoc questions on the data you have available.

Jonny Daenen (05:04)
Yeah, so this seems to replace both the analytical part where you need to explore your data, a bit deeper into that, write SQL statements, but also the dashboarding part to visualize things.

Jelle (05:15)
Yes, if you don't have a dashboard available or it's really an ad-hoc question where there isn't something built yet, then this is a very nice way to do that. But I can imagine that if you are asking that question every day again, or this is something you want to look at every day at 9 a.m., then you still have that dashboard pre-setup available every day like you do today.

Jonny Daenen (05:41)
Yeah. And could you then also ask follow up questions here already? Like if you want to drill down on some things, for example, you have here data on Flanders, and Brussels. Could you then ask a follow up? Like, could you segment the Flanders data even more or could you aggregate it by a week? And does it remember the history then?

Jelle (05:55)
Yes.

Yeah, you can. So could you segment the Flunders data even more to get an overview or store, for example? And if you do that, it will take the previous context into account and it will break it down again. So again, you see that the SQL query is being generated. It also fully

Jonny Daenen (06:06)
Yeah.

Jelle (06:21)
captures like the traces. So you can always go back in case you would get the wrong answer and someone needs to debug that. You can see the thought process that happened there. And here you see it. So now you see we have Mechelen, Antwerp, Bruges, Gent and Leuven. And now you see the breakdown for those stores or locations individually, which pops one-on-one with a store in our case. And here you see some key observations like

Jonny Daenen (06:31)
No.

Yeah, I see also.

Jelle (06:49)
average monthly revenue. So we didn't even ask for that, but he said, look, these are some things we notice in the data.

Jonny Daenen (06:54)
Yeah.

So it already gives you some thinking points or some maybe outliers that it indicates in resulting data set.

And I also saw on the graph part, there were some options on those graphs. Are they interactive or can you share them easily?

Jelle (07:13)
Yes, so what you can do is you can download the raw data behind it. So there is this download as a CSV button. Also, when you want to import it into Excel, you can also download the chart as an image. But Snowflake recently also added a preview feature called Artifact. So what I can do is I can save it, meaning I think this is valuable.

Jonny Daenen (07:25)
Yeah.

Jelle (07:39)
and my colleagues, my other business colleagues would be interested in that. And then I can open the artifacts. And what you will see is that this graph that was just generated is here. And you can simply click copy link. And then any colleague that also has access to Snowflake Intelligence, I can now simply send this link to. And what you will see is that, yeah, it has its own ID and they will be able to see the exact same image.

So if I go to that, you'll see accepting shared artifact. And there you go. You have

Jonny Daenen (08:07)
Okay.

Jelle (08:12)
you can also have voice input if you like. You can also enable extended thinking if you think it's more difficult question. It will reason through it

And you can also easily upload ⁓ files. So if you have a local file like a markdown or even a PDF with more context that is relevant to the question you're going to ask, you can just drag and drop or just upload a file and it will also take that into account. So a bit of the default features you would expect nowadays from a chatbot, but I think it's nice to know that that snowflake also offers those out of the box.

Jonny Daenen (08:41)
Yeah.

When you press the plus button, there was this second option, the agent sources. What is this?

Jelle (08:52)
Yeah, so how this works, every Snowflake Cortex agent has tools So here we have an analyst tool that is for structured data and you also have like a search tool which is for unstructured data and the Snowflake agent will automatically, based on your question, route the request to the appropriate tools. So in this case,

We gave it two tools, one for structured data and one for unstructured data. So maybe if I open a new chat here and I ask the question, what is our loyalty program policy? Well, that is not structured data. That is a document that is somewhere sitting there that we upload in a knowledge base and Snowflake will say, hey,

Jonny Daenen (09:33)
Yeah.

Jelle (09:35)
This is basically what our policy looks like. say customers earn one point per euro spent, and if they have 100 points, they can get a free drink and the points expire after 12 months. Loyalty members get a 10 % discount. And it even tells you what the source is. And then you see here that it points basically to a record, a string record we put in a table. So there's different ways to get that unstructured data, but having just a long column in a table is one way. That's how it's done here.

Jonny Daenen (10:05)
And so basically this is sort of a RAG system that you then use, is like the default for non-structured data.

Jelle (10:12)
Exactly. Snowflake also has a way to do RAG, so it also makes vectors behind the scenes and then it does the same thing. So based on your question, it looks up a vector, it embeds it into question and then it retrieves the correct answer.

Jonny Daenen (10:29)
Yeah, all right, a very nice demo. Maybe this is a good time to zoom out a bit on what this whole snowflake offering means, what is their positioning.

Jelle (10:36)
Yeah, so.

If we look at the slides they have on Snowflake Intelligence, then you see that their goal is really to offer this natural language interface for business ⁓ users. The idea is really that they can have true self-service. It was promised already for many years in the past with self-service, dashboards and last-mile analytics. But we saw that these tools didn't really work or they used it, but then it became really

Jonny Daenen (10:58)
Yep.

Jelle (11:08)
unmaintainable for engineers. So I think this is a nice way now that the whole GenAI capabilities arrived and they've become very powerful that they can finally do that without having that strong dependency on data teams. So I think that's a bit their promise. You don't need a dashboard for every question. There will still be dashboards, but you don't need one for every question. And they don't have to write custom SQL. They can just write a natural language.

question. I think that's the promise of Snowflake Intelligence and it builds upon other features that Snowflake has been introducing over the last couple of months. So first had Cortex Analyst, then the agents came around and then Snowflake Intelligence is the layer that builds on top of that.

Jonny Daenen (11:56)
Okay, very nice.

Jelle (11:57)
Yeah, so if I go to this next slide, it's a slide from Snowflake of how this all works. So you see that the big box is Snowflake Intelligence. That's where an end user interacts with. And then you see a couple of layers of data that it needs to get to that end result. The first part is an agent. So Snowflake Intelligence can have multiple agents.

So in our case, we built one. Then an agent itself takes care of the planning, tracks the details and also thinks, did I answer the question of the user or do I need to think more or use more tools? So that's a bit what the agent does. But then the most important thing that the agent does is it has tools. There's three different kind of tools. You have Cortex Search.

which is for ⁓ unstructured data. It's a bit of the manage reg for Snowflake. You have Cortex Analyst, which is for structured data. For that, it does text to SQL using a semantic view. And then finally, you have custom tools, is like custom SQL or Python code defined in a user defined function or ⁓ stored procedure. So those are all the layers you need to get to that final layer. I have this same image on the next

slide but then

technical version of it, of what it means. So the same thing, you have Snowflake Intelligence, it has access to multiple agents and each agent has those three kind of tools and then there's a fourth one, a bit of a special one, which is another agent. So if you want to say I want to do multi-agent or I want to combine them in one approach, then you can say I have an agent as a tool for my agent. But I think the most important part is this here.

which is if you have, for example, a cortex analyst, then that means that it needs to have exactly one semantic view. And a semantic view exists out of one or many tables. So what you need to do is you need to select which tables logically belong together.

And then expose those as a semantic view. And it needs quite a bit of metadata, knowledge embedded in that semantic view to do that correct text to SQL resolution. If you don't give it examples, if you don't give it synonyms, if you don't give it metrics, column descriptions, it will be very bad at that. And it will lead to wrong SQL statements, leading to wrong conclusions. So it's very important that you get this part ⁓ right and that you iterate quite a

also with business users to test the most asked questions to get to the right ⁓ answer.

the Cortex search tool is similar. also there, one search tool links exactly to one search service and that can index one or many unstructured documents, so text documents, and then it does the chunking. So I think this one-on-one mapping is quite ⁓ interesting. So you have the tools for each kind of views that you want the agent to do, but then behind the scenes, it means exactly one search or exactly one semantic view.

So maybe let's go to Snowflake and let's try to build this up from bottom to top. let's just recreate the whole demo from scratch. The tables will already be there, because I think most companies will have tables if they use And then we can build a semantic view, Cortex Analyst tool, and then add that to an agent again.

those things are available as SQL statements, but Snowflake also has quite a good UI that can help you with this. Also with lot of AI assistance. So if you already have table comments and column comments, then it will help to build that semantic view.

Jonny Daenen (15:43)
Okay.

So that means if

you have invested in metadata already, this is a big advantage in creating these semantic views.

Jelle (16:01)
Yes, exactly. And we haven't talked about access control yet, but also there. If you have properly set up role-based access control on Snowflake, you will benefit from that because also in Snowflake Intelligence, it will go all the way through, apply role-based access control. So the user logged in to Snowflake Intelligence also needs to have access to the underlying tables. Having access to the agent alone is not enough.

Jonny Daenen (16:04)
Yeah.

Okay.

Jelle (16:27)
So if you open Snowflake and you end up in this UI in the Snowsight,

So what you can do is, for example, you first take a look at your data. So in the Horizon catalog, you can go to the database explorer. And there you see I have a database called Coffee Demo. And then in the analytics schema, I have four tables. Three of them we can use for a semantic view. So I have my stores. Also here you can say data preview.

And then you will see that I have my 10 stores here. I have the orders. Also here, I can click data preview. You'll see I have 15k orders. And then I have the order items. All right, so that's our starting point. That's what I assume most companies have. Then what you can do is you can go to the AI & ML tab and you can go to...

analyst. And there what you immediately see is you come in a section called semantic views and there's a big blue button on the right here called create with autopilot. So if we click that then the first thing it will ask me is do you have extra context that can help with creating a good semantic view. So if you already have a tableau dashboard and you have a tableau file or you have SQL queries

that you know people already execute against those tables, you can upload those. And that will really help with getting to a good semantic view. In this case, we don't have that, so we can skip this part. Next up, you have to name your semantic view. So let's call it a crew shop recreate, meaning we make it again. You say, okay, we will store it in this schema. We will store it as semantic view.

Next, and then you can select your table. So here we say I want the orders table, the order items, the stores. We go next again, and then we can select all the columns of all those tables.

Jonny Daenen (18:29)
Why would you not select all columns?

Jelle (18:31)
Well, let's say that some columns are sensitive or you explicitly do not want them in your talk to your data, then this is a way to exclude them. It's not the only way. You could also say, let's always include all columns and yet let's use column masking policies or row policies instead to hide data. But if you haven't done that yet, or you haven't invested in that as an enterprise, this is another easy way to just leave certain columns out and then it will simply not

Jonny Daenen (18:50)
Yeah.

Jelle (19:01)
not show them.

Jonny Daenen (19:03)
It

will also not be accessible to the agent in that case or will it just not know about the columns?

Jelle (19:09)
It will not select them in its select part of Yeah. Exactly, because it uses SQL directly on the semantic view and that translates into like the physical table query. So if the semantic view doesn't even know about it, then it will also not translate back into that physical table.

Jonny Daenen (19:12)
Okay, it will never do select star, it will only use the columns that are listed.

So the semantic view is really like

an intermediate layer that it passes through and it only exposes whatever you select here then Okay

Jelle (19:36)
Yeah, exactly. So it has its

own thing you can query. All right, so let's create it.

And then what you will see is that AI will start working and it will start figuring out how to set up that semantic view. So if I hide the menu a little bit, you see this is bit better, then you see that first it added my tables. It took over the table description I already had, but then it will start proposing

metrics. So that's the thing you see loading here. It will also start proposing relationships. So here you see, I saw you have a relationship from your store ID table to your orders table. So you can review that. And then if you think, hey, this looks right, it's a many to one relationship, you can click add.

So they use the Cortex AI also here to edit automatically. Also here, they added a bunch of metrics like total orders, so you can accept them all if you want. So let's do that. Imagine in a real scenario that we review them properly. But in this case, I think they're all correct. Also here, effects like...

Jonny Daenen (20:46)
Yeah.

Jelle (20:50)
The line total, which is the quantity time, the unit price, and it seems about right. So also there we can accept it. And then also here, quite important, verified queries.

Since a Cortex analyst will translate a natural language question into a SQL statement, it's important that the most commonly asked questions you already embed and you verify the SQL yourself to make sure that at least that question is correct and that that question gets answered right. So also here it's proposing a question that it thinks would benefit from a verified query. So if I click review here,

Jonny Daenen (21:26)
Yeah, and it also says

like this query ran two times the last 14 days. That means you leverage the power of the unified snowflake ecosystem. It knows that this query was run before, it knows it's real, it's useful.

Jelle (21:42)
Exactly, so it can use the query history to know this is a commonly used query. That's probably what you should include as a verified query. So that's quite powerful. And also here, so now I clicked on the screen to review a verified query. And here you see that it will say this is the logical query.

And then here you see the physical query that came out. So you see those are two separate things. So it uses SQL on a more abstract level than the physical query. You can run it. And then you see here what came out. And you see, does it look about right? Yes or no. You can modify the query a little bit to see if it matches that SQL statement. And you can even highlight it as an onboarding question.

Jonny Daenen (22:02)
and is

Jelle (22:27)
We save this. And now we have our...

semantic view ready and also our Cortex ⁓ Analyst tool. and we can...

Jonny Daenen (22:37)
Yeah, one more question.

You said we have our semantic view ready and the analyst. What does that mean?

Jelle (22:43)
Yeah, so what we saw on this slide here is that a semantic view maps one-on-one to Cortex Analyst. So in this case, even in the Snowflake UI, we had to go to the tab Cortex Analyst. And when we clicked on that, it immediately gave us like a tab semantic view. So it's a bit the same thing.

Jonny Daenen (23:03)
Yeah.

Jelle (23:05)
It's only when we start defining the agent that we'll start adding them as tools.

So let's create a new agent. And also here, you can say, okay, where do I want to save it? So let's save it again in our analytics schema. Let's call it the Brew Agent.

and this is where you can configure everything. And then here you have to provide the description of how it will be visible to users that log into Snowflake Intelligence. So let's say I am the Brew agent and I can answer questions about the sales in all stores. And then here you have those example questions.

questions that we saw when you go to the homepage of Snowflake Intelligence. This here, those are the example questions.

Jonny Daenen (23:51)
Yeah.

Jelle (23:53)
So if we go to the verified questions, we can, for example, take it.

and then put that here. There you go. It's an example question. And the most important section is this tools section here. And here you saw exactly what we saw on that slide I showed. You can add as many tools as you want, but they have to be one of the three main types. It's either an analyst for structured data,

a search service for unstructured data, so RAG behind the scenes, or it's a custom tool. So it maps a bit to this, so you can select one of those tools. So in our case, we just create the Cortex Analyst. So what I can do is I can say, hey, let me add a semantic view here. And then you can search for it. So in Analytics Schema, you say the one we just created, user-friendly name. So we say, Brew Shop.

Let's give it the same name. And also here, Snowflake embeds AI to help you with a description that can be used for the agent. So now I click this button. Now it's generating the description.

they optimize basically for themselves, for the agent to discover. So here you see quite lengthy. So it says basically the tables that are available and what kind of data is in there. So the Snowflake intelligence object, the agent,

Jonny Daenen (25:07)
Yeah.

Jelle (25:18)
will play the role of the orchestration and look between all the tools it has available based on this description. it's the orchestration part that is really important, so you need to get this description right.

Jonny Daenen (25:25)
Listen.

Yeah, so it needs to know when to call the tool. And this is essentially the metadata or the summary of the semantic model to know like, okay, this is when I need to call the tool.

Jelle (25:40)
Yes, because you could say I put that responsibility in the hands of the user using Snowflake Intelligence to switch agents when you have multiple ones. But in case you say we go for an approach where we only have one agent and that agent has 10 tools, well then it needs to know which of those 10 is able to answer the question. And that's why this description is so important.

Jonny Daenen (26:02)
Yeah, neat.

Jelle (26:04)
All right, warehouse, we can say use the default one of the user. You can also enter a timeout. So if the query takes longer than that amount, yeah, then it will be timed out. So let's, for example, take two minutes. We add that. And now you see that we added one tool.

Then let's go to orchestration. So here you can select which model do you want to use for this agent. You can put it to auto. And here you see, for example, that some models are grayed out.

Jonny Daenen (26:39)
Yeah.

Jelle (26:39)
The reason is because in Snowflake you can enable regions. You can say where do you want those models to be hosted? And in my case, I put a configuration to say only in the European Union. meaning that the Anthropic models are available, but the Gemini and GPT are not. If I would say allow all regions, then I would also be able to select those models. So let's leave it to Auto.

Jonny Daenen (27:03)
Yeah, okay.

Jelle (27:06)
So you have the orchestration instructions, you have a system prompt from Snowflake itself, and then you have the response instructions, what gets looked at right before returning to the user. Then budget configuration, also here when it stops, token limit you can set. And then finally, access.

So you can say which role has access. You can very easily, in our case, say public role, meaning that everyone will get access. So if we save this, what we can now do is we can test this out. So here you get some kind of inline chat interface to see what happens with that agent before having it available in Snowflake Intelligence.

Jonny Daenen (27:32)
everybody.

Jelle (27:48)
So it's now thinking, planning the next steps and then it will generate a table.

key takeaways and then even generate the chart And you see coffee is by far our most popular product as expected in a coffee bar.

Jonny Daenen (27:59)
nice

Yes.

Jelle (28:05)
So here you see when I go to the agents tab and then I go to Snowflake Intelligence, here you can say add an existing agent. And then I hit then say brew agent. I add the agent. Now it's permanently available in Snowflake Intelligence. So if I now refresh this.

Jonny Daenen (28:19)
And that's

Jelle (28:23)
There you see the new one is here. I can make a new chat. I can put it here and then I can ask that same question again we just did. And then it says, hey, this looks like a verified query. Let me use that one. So it doesn't need to think.

Jonny Daenen (28:24)
nice.

Jelle (28:39)
about the text to SQL, but it just knows that that is the same question. So it will take that predefined SQL and of course it will generate the same data, generate the same bar again.

Jonny Daenen (28:53)
So the steps you followed were essentially you had the table, you make the semantic view on top of that. This you coupled to the agent. There is actually the thing in between the cortex analyst. You didn't need to do anything special. That's just the way you expose it to the agent seemingly. That's no object or anything.

Jelle (29:08)
Yeah, you just need

to add it as a tool in the agent and every semantic view you created you can select as a tool if you have access.

Jonny Daenen (29:12)
Yeah.

Yeah, very nice. How do you do the unstructured part? Is that just like an S3 bucket where you dump all your files in?

Jelle (29:27)
That's one option. So if I go to the ⁓ search, Cortex search, so there's this one tab again with all the Cortex feature. We just looked at the agents and analysts and then you also have search. And here, for example, I already created that knowledge base in the first agent I demoed. And there you see that I just use a normal ⁓ table. So here,

I have a table called coffee knowledge base and there is one column in there if I do this that has the content.

you see the unstructured text that you can also use to do the RAG on. So here you see that it generated the embeddings in Snowflake. So that's one way. What you can also do is if you click Create here. Let's create it here.

No

There we go. And then I can select a table or a view. But what I can also do is select a stage. And a stage in Snowflake, I don't have one set up, but essentially what you have is you have internal stages, which is a bit like a file system.

you connect to, so it's a place you set up behind the scenes, it will create like an internal snowflake place in your snowflake account and then you can connect to it and upload files to that stage. And it can be PDFs, can be markdown files and then you can query them from here. But what most companies do is they use what they call external stages, meaning you point it to one of your own S3 buckets or one of your own clouds, Azure cloud blob storage.

Jonny Daenen (30:53)
Yeah.

Jelle (31:11)
meaning that you can use normal processes in your AWS account to get those files in there. And then Snowflake will automatically monitor that stage basically. And every time new documents get dropped, it will do the chunking automatically and you have to define a target lag. So you say do this every one hour, for example, and it will weigh those chunks and make sure that search services is up to date.

Jonny Daenen (31:25)
Okay.

Yeah.

Okay, but this is actually really convenient if you want to generate your own RAG, you just set this up and you dump your files in an S3 bucket and then you get search on top of your files, semantic search.

Jelle (31:44)
Exactly.

Jonny Daenen (31:44)
And so if you stay in the Snowflake ecosystem, everything you showed us quite easy to set up. What are the hard parts of this? Because now everybody could set this up. You did it via UI. It's also possible to do via SQL, of course. Do you see any restrictions or any hard components in setting this up?

Jelle (32:03)
Not sure how much time it took, but I it won't be more than 20 minutes to set this up end to end via the UI. Probably in an enterprise context you want it a bit more managed as code, but still it won't take you long. I think the hard part here...

is making sure that you have all the context and that you have all that business knowledge. The example here of a coffee shop, it's very tangible, everybody understands it, but when you're working in a complex industry and your engineers did not have the practice yet of adding column comments, table comments, setting up that semantic view will be quite a challenge. So I believe that ideally that semantic view

is not an engineering object. It's not something that an engineer defines in code, but given the capabilities that Snowflake has and the UI it has built in with Snowflake Cortex, you should, I think, put this in the hands of your business users and let them iterate over it so that they can...

themselves at metrics, facts, synonyms, ⁓ and that they can iterate together with engineers. So I think that that iteration loop is a challenge. And something we did not even talk about today is that ⁓ knowledge, adding knowledge to your data is only a small part of the puzzle. That assumes that your data quality,

Jonny Daenen (33:12)
Yeah.

Jelle (33:33)
is already in order. If the underlying data in the table is wrong or you have data quality issues duplicates in there, it will also just simply return that in the UI and also your business users will see the wrong result. focusing on knowledge and getting that knowledge component right.

Jonny Daenen (33:35)
Yeah.

Jelle (33:49)
doesn't mean your excuse from doing all the other things. You still need metadata, you still need ownership and someone to talk to when things go wrong. You still need to focus on lineage, you still need to focus on definitions and then decide what does it mean of what a data product is, what does it mean of what a customer is in this domain. All those things do not go away by having this capability available.

But if you have your foundations right, it won't be that hard to add this layer on top. think doing it the other way around and starting from this and then realizing our quality is not that good, that's a bigger issue.

Jonny Daenen (34:26)
Do you see there a difference between how we used to work before? Like what we normally do is you have an operational system, we have ETL to copy over the data to the analytical side, I imagine...

a naive way of thinking about it is like now I just expose an MCP server on my operational database and I plug it into Claude code and I can start querying my data.

Jelle (34:46)
Yeah, think that one of the reasons why we did this ETL process was to not put loads on the operational system for analytical use. think that reason is still valid. I still don't think you want those two worlds to interfere. But what has changed is the need to do the copy ETL as we used to know it. Zero ETL is something that is coming around, meaning that

Jonny Daenen (34:53)
No.

Jelle (35:11)
behind the scenes actually, there's still ETL happening, there's still a copy happening behind the scenes, but it just reflects the data in the operational system almost in real time into the analytical system. And Snowflake also has a very good support for this in combination with partners that offer this, like Salesforce, like SAP, meaning that operational data almost in real time is available in iceberg format. So read

optimized columnar storage. And also that data can be used directly in Snowflake Intelligence. So you can build semantic views directly on that iceberg two...

do not exclude each other. But then you still have another part of the equation, which is do you want to expose your operational structures directly to your analytical landscape? And also there you see a shift happening where

those operational systems like SAP, they start offering their ⁓ engineers or the developers working on SAP a way to also offer interfaces, to offer data products. So the exact operational structures is not necessarily what gets copied with that series zero ETL, but also there they can do the modeling already directly on SAP and then that data gets zero ETL into Snowflake.

Jonny Daenen (36:25)
Yep.

Jelle (36:39)
So you see the ownership shifting actually to where it belongs in the source system. And that data first thinking is something that all vendors are embracing. they all also, they all talk about data products now. So I think it's a good thing. think that the source line data products, I think the copying we did.

The ETL, I think that's something necessarily we had to do to make analytics work, but ideally that doesn't sit in our ownership.

Jonny Daenen (37:11)
And so that means, while we used to export raw data and the raw formats and models from the operational systems, we're shifting more towards redefining that already at the source, putting ownership there, and then exposing that for analytical use cases. So you cut out the whole ETL part.

Jelle (37:27)
Yes, and even the effort of building the pipeline is cut out because of that zero ETL approach. So the data is simply there, meaning that we can immediately focus on the valuable parts, which is building consumer-aligned data products, use cases, combining data from multiple sources to get insights and do AI on and do predictions and integrations on and so on.

Jonny Daenen (37:47)
Yeah.

Jelle (37:49)
many companies are focusing right now is on one hand they want to make sure that

They are doing the innovative part that they're staying up to date with AI. On the other hand, they don't want incident accidents. They want to focus on governance also in the EU with NIST 2, the AI Act all coming along. You want to balance those. And in Snowflake, there was a whole bunch of enterprise guardrails built in.

meaning that it's quite easy to do full traceability, set cost controls also per user and that also models are hosted in the EU if you have that as a requirement.

Jonny Daenen (38:33)
I maybe want to cycle back to one of the first slides you had the last statement there is like you don't need dashboard or SQL. Does this then for you replace dashboards or is there still a place for dashboards in the ecosystem of analytics?

Jelle (38:49)
me, it partly replaces dashboards, but not fully.

And I think the recurring questions, the ones that you want to check every day or every week and that multiple people want to check. I think that for that you will still need a dashboard, but there can be much more ad hoc questions and on the fly generations of visualizations that where you don't need that dashboard for. So I expect more people to self-serve analytics.

Jonny Daenen (39:08)
Yeah.

Jelle (39:17)
I expect more people to be enabled. I think finally you can say as an enterprise, the value I'm getting from my data team is too low. Please enable me more with this kind of tools. I have a visual.

visualization here that I got from a colleague. So here you see these two axes and how many people want to know about those insights. Is it everybody or a few people? And what is the perceived value of the insight? Is it low or is it high? And you see where it's both high and everybody wants it, then yeah, then still probably it makes sense to have a dashboard there. But then what you see here is that

when a lot of people want to have an insight, but the perceived value is lower or the other way around, that the talk to your data will really, really help.

Also here, for example for the CEO, it only wants a few people, only insights for the CEO. And the value can be low or high, also there for ad hoc questions. and the CEO can now just open a tool like this and let me verify that. Let me fact check you.

Jonny Daenen (40:26)
Yeah, and ask. Yeah. Yeah, and the...

So, but I do think this could change the way we do reporting quite fundamentally because now in many companies I see when there is any question it needs to go through this whole cycle of analysts, dashboard builders, data engineers to answer sometimes a seemingly simple question. This is a huge shift, I think, right?

Jelle (40:54)
Yes it is, but I think the prerequisites are also not that easy.

Because imagine you now have 5,000 tables in your company. You probably do not want to enable talk to your data on those 5,000 tables. You still want to make a distinction between what are my intermediate tables and what are the interfaces, the public interfaces that I'm willing to take ownership on to guarantee that knowledge, that context that is needed and also data quality. So in a way, data product thinking, I think, is still

needed and someone needs to define the boundary of a data product. What is something valuable? And then make sure to apply all the principles on that. If you have that foundation in place, enabling this will be quite easy. But if you haven't done that yet and you still have 5,000 tables in Snowflake, you don't have proper role-based access control and you still give everyone a system admin to use this, then you will have a hard time to scale this

Jonny Daenen (41:51)
Yeah.

Jelle (41:58)
in an efficient way.

Jonny Daenen (42:00)
And so you still believe that data product thinking, designing your data product landscape, dealing with permissions, dealing with quality that that is still needed, right?

Jelle (42:09)
Yes, I believe that access control role-based access control is really a foundation for having data enterprise ready and having knowledge on your data is something new for.

for most enterprises, but making sure that ownership is in place, that lineage is in place, metadata is in place, it will all help. there is still something needed to make sure that enterprise data is enterprise ready.

Jonny Daenen (42:39)
Yeah, exactly. And that's the hard part, I think, right?

Jelle (42:42)
Yes, exactly. what we talked about today was ad hoc questions in talk to your data. But the next step or another step is having agents communicate effectively, agents talking to agents. So also for that to work effectively, you need all those things in place. If you don't have good context, if you don't have data quality, if they make wrong decisions because you didn't focus on those foundations, if they have overly

Jonny Daenen (43:07)
Yeah.

Jelle (43:10)
permissive access rights and they can write to tables, they can delete tables and you did not invest in role-based access control, then that is a recipe for disaster. ⁓

Jonny Daenen (43:21)
Yeah, I agree.

So what I hear often is like snowflake is expensive and you've shown that this is like an ecosystem. This is not just a data warehouse. There's many tools being added on top of that. What if I would

Build my own stack if I would want to build it myself like do you think it's worthwhile to pay for it and not build it yourself?

Jelle (43:42)
I think it's, if you're using Snowflake already, I think it's a very good starting point because Snowflake's edge is convenience, is how easy it is to set up. mean, it's in 15 minutes today.

So the faster you can get people used to it and experiment with it and get that feedback loop going to see what really works, what is it really that my users want. So you don't want to build for a year and then come to the conclusion no one wants this or I built the wrong thing, I took wrong assumptions. So by using Snowflake you can test things fast, get that feedback and then still later you can decide

Am I willing at scale to pay Snowflake to do this or is this really something I want to build myself and it is true Snowflake

Is an expensive product. think our CEO once called it a Porsche and they buy the Porsche and then later they complain that it costs a lot. Well, yes, it is a Porsche. And they do ask a time stream markup on token usage. So if you look at the raw and Tropic pricing, you pay three times as much. Every text to SQL query generates till uses normal compute credits as if you do a normal query in Snowflake.

Jonny Daenen (44:40)
Yeah.

Jelle (44:57)
So yeah, I think that's a trade-off here. So definitely start using it. And then If you say this is massively used, it is successful. Can we now keep the good foundations, everything you've learned, but then reduce the cost? If you don't want to make that expensive investment before you know that it brings value.

Jonny Daenen (45:13)
Yeah. And how would you recommend organizations get started with this?

Jelle (45:19)
I would select a focus group. If you're working with multiple departments on your data platform, go to each department and ask them, give me one or two data products if you have them or use cases where you think this is valuable, where you think business people will want to ask a of questions and talk to your data. And then...

Just build those semantic views with them, involve them, make sure you get that right and get it as fast as possible in their hands. And then learn and iterate on that. then even when building it for the first time, take some shortcuts and do it in the Snowflake UI. Don't industrialize it yet. Just get that feedback loop going. And if it brings value, then say, okay, now we do infrastructure as code. Now we make sure that our setup can scale and that we don't do it for five data products, but we

Jonny Daenen (46:02)
Yeah.

Jelle (46:14)
can do it for 300 data products in an industrialized way.

Jonny Daenen (46:20)
Yeah. You mentioned data products lot. This seems like a natural fit to extend the data product landscape with agents.

Jelle (46:26)
Yes, yes, I think it naturally fits and I think what I can recommend to start is just build one semantic model per data product because that's already, you already decided that that is a granularity that makes sense, that that is something on itself that brings value. And probably if this is success, what you will notice is that people will want insights over data products.

You make a new data product that has input ports to others and then that in itself becomes a thing you query. Or you could say, yeah, but that requires a new data product for every time that someone wants to ask natural language questions. You could make it bit more virtual and say that semantic layer itself, that connects to multiple data products. But then the challenge of course becomes if those data products are from different teams,

Jonny Daenen (47:15)
Yeah.

Jelle (47:20)
then what organization structure do you need to define that and collaborate to come to a good semantic view and what if those have relations to each other? So does that live in the stream aligned use case teams or does it live somewhere else?

Jonny Daenen (47:29)
Yeah, I see.

Yeah, indeed. But based on what you've shown, like you make a semantic ⁓ view, I imagine like I have multiple teams, they all supply me with data products with semantic views, and I can just combine them in a new agent.

Jelle (47:49)
Yeah, you could merge them in an agent, but I think typically when you want to combine them, there is some kind of relationship between the data. And it can be an obvious relationship like order and order lines. But it can also be, I have my customers from my marketing department. I have my customers from my engineering department. Yeah. And now I want to combine those and it might not be that clear.

Jonny Daenen (47:57)
Yeah.

from sales or yeah.

Jelle (48:17)
how they link. It can be simple for a key, but it can also be much more complex where you don't have different keys and you still want to get some insights over them and create like a global customer again, which is probably something you wanted to avoid in the first place by going to data products to avoid having that discussion of talking for one year about the definition of what a customer is. So you say you can have your own definition within this department, but then now for this talk to your data, you might decide how we bring them back.

Jonny Daenen (48:26)
Yeah.

Yes.

Jelle (48:46)
together again. So I think that that's the right order to do it. Split it up, have your own flight or customer per department and then maybe later say okay but how do those connect again.

Jonny Daenen (48:48)
Yeah, did.

Yeah. And an agent, can it actually run queries across different semantic views? Or is it always inside a semantic view that it queries?

Jelle (49:09)
Well, it's inside a semantic view. So it will never generate a SQL statement that goes over semantic views. So if your agent has two tools of the type Cortex Analyst, meaning two semantic views, it will still try to think through it and try to get to the right answer if it requires a combination of the two, but not by generating a single SQL query. It will put the output in the context window.

Jonny Daenen (49:16)
okay, okay.

Yeah.

you

Yes,

Jelle (49:35)
And then

Jonny Daenen (49:36)
yes.

Jelle (49:36)
it will do the other query and then it will try to combine it. So it's not super efficient, might be wrong. But the orchestration layer, the snowflake agent, Cortex agents will still try to achieve it. Which is why this discussion of granularity is so important. What do you put together in semantic view and whatnot, depending on what gets queried together.

Jonny Daenen (49:39)
Okay.

Yeah.

Exactly.

Yeah,

I see.

All right, this was very useful. Maybe you can do a quick wrap up of what is now your thoughts on Snowflake Intelligence

Jelle (50:06)
Yeah, so I think Snowflake Intelligence gives business users an effective way to use data themselves without having a dependency on the data teams. I think it's especially useful for ad hoc questions and discovering use cases.

Now what you often notice is that data teams, they get fed with feature intakes and in the PI planning. That is what we need to do. think having something like this available will feed the machine and it will feed the thinking of people because they can play with it. They can already verify business impact.

Jonny Daenen (50:33)
Yeah.

Jelle (50:44)
And it will lead to, I want this more or I want this automated or I want this insight every day. So I hope it leads to better business focus and that people really get value from it. Where I see this going is that it becomes a bit the default way for business to interact with it. And then even they set up their own flows.

If you think a bit about Claude and Claude skills and Claude co-work, that they will want to combine doing custom workflows ⁓ with asking questions about data and then basically almost programming themselves in a non-

in a non-technical way, a workflow that combines your talk to your data with whatever they find valuable. And then probably at some point, they also want to want to share that workflow or tool they built locally with a colleague. it also brings some challenges with it.

Jonny Daenen (51:26)
Yeah.

Yep.

Yeah, then again, industrialization and also access management, these kind of things become important again, but on a different level.

Jelle (51:49)
Exactly, So your data access control is almost the foundation for doing everything else, at least if you want to use your custom data in your workflows, which I think is almost always the case.

Jonny Daenen (51:51)
Yeah, very nice.

Yeah,

yeah, true. All right. Well, what I take from this is I think it's a really nice demo you gave us, Jelle, so thanks a lot for that. I see this as a democratization step towards business and also giving people access to data. And I think indeed this unlocks new potential and will create more focus on what we actually need to industrialize and what we need to build as data engineers. All right. I think we can wrap it up, Jelle.

Jelle (52:25)
Yes.

Jonny Daenen (52:27)
Thanks a lot for the demo. If anybody still has questions on this, please reach out to Jelle on more on Snowflake AI. We will do some follow up on other videos on talk to your data and some Databricks AI features as well to compare a bit. So thanks a lot everybody for watching and we'll see you next time. Bye bye.

Jelle (52:46)
See you, bye bye.