Snowflake AI副总裁 Baris Gultekin：让AI进入数据、智能体设计、Text-2-SQL、RAG及更多

Baris Gultekin, vice president of AI at Snowflake, welcome.

Thank you, Nathan. Thanks for having me. I'm excited for this conversation.

I think there's going to be a lot to learn. We have a very diverse audience. The number-one profile is an AI engineer, and within that profile, people work at a lot of different kinds of organizations, from solo entrepreneurs and consultants to startups to enterprises. Some people will certainly know Snowflake and will work at organizations that are customers of Snowflake. Others have probably heard of it and don't really know too much of the backstory. So, maybe for starters, just give us the real quick Snowflake 101, and then I'd love to go into how AGI-pilled Snowflake is today.

Sure. Snowflake is a data platform. We call ourselves an AI data cloud. What that means is that our customers bring a lot of their data onto Snowflake so that they can secure it, govern it, and analyze large amounts of data for various insights, dashboards, and the like. From an AI perspective, because there's a lot of gravity to data, our customers do not want to replicate data in multiple places. Instead, they want to bring AI to run next to data. That's a very high-level overview of Snowflake.

The AGI-pilled phrase is interesting. For us, we're quite practical. We serve large enterprises, and the goal is to get to high-quality AI agents that create positive ROI for customers quickly. That can happen today, and it is happening today. I'm super excited about where things are.

I definitely want to come back to the bring-AI-to-data strategy that you guys have in a few minutes, but to double-click a little bit on the before and after, Snowflake had been around for a while before anything like the AIs we have now was available. What were people doing before with Snowflake, and what are the new AI use cases that have been unlocked over, say, the last—I don't know when you would start the clock. Would you start the clock at ChatGPT, or was that not quite strong enough to actually make things work? There are a lot of different dimensions. Maybe let's start with before and after.

Sure. I'll start with the before. A lot of our customers have been using Snowflake mostly for structured data initially. This is where they'll bring the data in, and then they'll run large-scale analysis, either to have insights to power BI dashboards, for instance, or to do various analytics to understand their business. The value of the platform is to be able to bring data from all the different places—the data silos—so that you can run analysis across large amounts of data.

What is happening with AI is that there is a big unlock, of course, of unstructured data. If you have thousands or hundreds of thousands of documents, for instance, you can now extract structure from these documents, and then you can analyze them. If you have contracts, for instance, and you want to say, “What are the contracts that talk about this specific thing? How many of them do I have?” or “What are the contracts that are expiring soon in this category?” being able to run these analyses super easily is now very feasible.

Then there's, of course, being able to do a lot of large-scale analytics work, but with a lot of ease. A lot of the pipelines that used to be built around “I'm going to go classify my data. I'll extract information from it” are now very simple to do. The way we've done it is, again, to bring AI to work directly with the engine for analytics. You can do things like classification and extraction of that data very easily. Increasingly, there is a lot of interest in bringing a natural-language interface to all a company's data, so that you can just talk to your data. You can democratize access to all that data for the organization.

Could you give us a sense of the balance of structured and unstructured data? Then I guess you're also saying that structured data is getting structured through the process of basically AI retro-annotation.

My sense is that—and there are so many vector databases—the exact name of the one where the founder told me this is slipping my mind, but one of the interesting things that I've understood to be happening in general with business data is that structured data was kind of like the tip of the iceberg in many organizations. It was the most usable kind, but it was actually a relatively small amount of the data. It was Chroma. It was Anton from ChromaDB who said that most of the data that was going into ChromaDB had never been in a database before at all. It was just lying around in various places.

So, have you seen a sort of great unlocking of people dumping more and more data into Snowflake because now they have ways to make it useful, where previously it just wasn't even worth it?

Yeah, we're absolutely seeing this. Eighty to 90% of all data is unstructured data. Because there weren't a lot of easy ways to process this, it was not necessarily seen as the most usable data, and it is now very usable, both from an extract-and-bring-structure-to-it perspective, as well as just being able to talk to all of that data, find the right information using vector databases, for instance, and then build agents and chat experiences out of it.

We're seeing this play out in both ways: more and more data is getting structured so that you can run analytics on it down the road, as well as just use all of this data in conjunction with the structured data that you have. For instance, if you want to build, let's say, a wealth management agent, you still need to be able to look up what the stocks are doing in a structured way, but you also have all of the equity research that's in PDFs that you'd like to be able to use. Being able to combine both structured and unstructured data is incredibly important for real-world use cases.

Where would you say we are on text-to-SQL today? It's been a while since I've done a show on text-to-SQL. There have probably been 2 episodes on this theme historically. The last time I checked, there was a range of opinions. Some people were like, “Yeah, it's just not really there.” Other people said, “It is there, but you have to do a lot of work to make sure that you have a good semantic understanding,” because a lot of the SQL databases that people have contain multiple columns, and there is tribal knowledge on teams: “We don't use that column anymore. We haven't deleted it, but we don't use it anymore, and it's superseded by this one.”

There are all these little nuances that live in people's heads. Some people have said, “The models can't do it.” Others have said, “The models can do it if they have enough of that kind of context.” What does the process look like today, and how good does it get if a new customer says, “I want to start to enable this talk-to-my-data experience with a sort of text-to-SQL strategy”? What does that look like now?

Yeah, you called that out, right?

It's been traditionally very difficult for models to get text-to-SQL right, and there are various reasons for that. First of all, if you ask, “What’s my revenue?” there’s only one answer, so the margin of error is very low and the expectations for quality are incredibly high. The reason it’s been really difficult for these models is that you need a lot of semantics to figure out where to get the data from. First of all, what is the definition of revenue? What is the definition of profit? Those can change, and how they’re modeled on the data side can be tricky and can change.

When we’re talking about real-world scenarios, we’re talking about thousands and thousands of tables that have hundreds or thousands of columns in them to be able to reason about. So it’s been traditionally very difficult. What I’ll say has happened in the last 6 months to a year is that, with the reasoning models getting substantially better and increasingly being able to bring the semantics relatively easily onto the platform, we’ve had pretty substantial gains in quality. We now have a product to do this, for instance, called Snowflake Intelligence, and we’re seeing demand for doing text-to-SQL. The quality is at a place where you can now deploy them very broadly—very high quality and very useful, because structured data is quite useful.

And when you say “deploy broadly,” you mean to users who are not data analysts?

That’s right. For us, for instance, this product I mentioned, Snowflake Intelligence, is our agent platform. It’s been used by business users, and it is the fastest-growing product that we have at Snowflake because we’re now making large amounts of data easily accessible to business users to ask questions and get insights very quickly. In the past, they would have to go to an analyst who’s familiar with the data for the analyst to build some analysis and then get back to them a week later. Now they can just directly ask questions.

What does that process of bringing semantics onto the platform look like? I can imagine a big setup one time where you go out and interview the people who have set these things up and should know. I can imagine that, at runtime, you might have to come back with questions and say, “Hey, I’ve got multiple columns that are ambiguous here.”

I did one episode also with a company you may know called Illumex, where they had a really interesting strategy around basically building what they consider to be the canonical, abstract, ideal form of an enterprise in each major vertical that they served. Then they built their query engine off of that ideal, and the mapping process was like, “Okay, now how does your actual real-world enterprise deviate from this ideal? Let’s map all that out, but then we know that once we’ve done that mapping, the logic on top of it will be trusted.” What mix of strategies are you using? What do you find to be effective?

First of all, reasoning models are now at a point where AI can help substantially in building out a semantic model. The inputs to that are both the data that’s in the system and all of the metadata that’s in the system: the names of the tables and columns, as well as the data underneath them.

We’ve also built a series of connectors to things like BI dashboards that have a lot of semantics in them. That’s super useful in building out semantic understanding for the organization. Also, things like queries people have been running in the past—these are all hints for these agents to help our customers build semantic models.

Snowflake has recently also announced what we’re calling Open Semantic Interchange, which is an attempt to create an open standard for sharing that semantic model across different platforms, so we can more easily create these common semantic understandings for AI to act on.

Okay, that’s interesting. How does that work? Can you unpack that for me a little bit? What do I do as an enterprise if I want to adopt that standard?

It’s still early. We’re working with BI platforms like Tableau and Omni, as well as other technology providers, to create an exchange format so that if you create a semantic model in one platform, you could just use it in a different platform. There’s active development now with all the parties in the Open Semantic Interchange to define what that interface is, so we can support an open interchange of the semantic model, essentially.

What that would look like is that a customer can go to Snowflake, for instance. They can go build out their semantic model, and then they could reuse that semantic model in another place that supports the open interchange.

For one thing, I wish that would come to electronic medical records sooner rather than later. I feel like “yikes” has been my recent experience there. Going back to the first question about how AGI-pilled various organizations are, I wonder how you see that from a competitive-dynamic standpoint.

I think one of the things that’s most interesting, where the dice are in the air, so to speak, is that the pace of software development is increasing dramatically right now in the software market. People are—I think mostly it’s outliers or just plain bluster at this point—saying that they’re deleting systems of record and rolling their own in-house, but you’ve at least got that talk out there.

If I can already see a major acceleration in my software development, or if I can project 1 or 2 years into the future and see a clear path to a major acceleration—and I vibe-coded 3 AI apps for family members as Christmas presents this year, and that acceleration at that level is certainly very real—then presumably everybody is going to be incentivized to try to take some conceptual territory from companies that maybe used to be partners, used to be complements. It seems like it’s headed more toward competition.

So all these companies that you named, right? Historically, you specialized in one thing, they did a little different thing, they worked nicely together, and you got a lot of customers in common. Great. But if I’m them—or maybe if I’m you—I might start to worry at this point. If I’m Tableau, should I be afraid of Snowflake? Are they going to come after me with something that sort of replaces what we do? Do I want to be partnering with them on these standards, or do I have to fear that whoever has their hooks deepest into the customer can box out and colonize these additional niches? Now, that’s a pretty AGI-pilled point of view. Maybe you think that’s just where I’m getting ahead of myself, but what do you think?

Not at all. I really love what’s happening. What’s happening is that the silos are coming down. This is all great for customers, for consumers, right? With all these open standards, essentially, the beneficiaries are our customers. There is no lock-in anymore. That’s great for competition. That’s great for innovation. That’s great for customers.

We’re seeing this play out across the board, right? Anywhere in AI, the differentiation is coming down. That means everyone is doing more and more things to create more and more value, which ultimately is great for the industry and great for consumers and customers. So I’m loving what’s happening. As you called out, the walls are coming down. The lock-in is no longer there. That makes product development really important. That makes the speed of execution really important. Ultimately, it’s all about creating more and more value.

But does that take us to a place where companies that used to be friends are trending toward frenemies? It seems like there are only so many ideas. It just seems so obvious to me in so many places that a big platform like Snowflake would be like, “Sure, we could do what Tableau does,” especially now that we can get so much more stuff shipped on a quarterly basis.

I would say the pie is growing. So I don’t think it’s a fixed pie that people are trying to protect. The types of things you can do are growing, and that is super exciting. I also don’t think that everyone can do everything. Ultimately, where each company focuses is closer to their area of expertise, to their differentiation. I don’t necessarily see that everyone is going to do everything, but I do believe there is a lot of competition. But there’s also a growing pie, which is exciting.

Let's go back more toward the technical side for a minute. We kind of went deep on text-to-SQL. Let's do the same thing for RAG. So we've got all these vast amounts of unstructured data out there.

Yep.

They're getting loaded into platforms. They're getting metadata synthetically created by AIs coming through and just processing them sweep by sweep. How well is that working, and what is actually key to making it work? We've been through eras where chunking strategy is really important. I've done episodes on graph databases and entity recognition, and figuring out various ways to traverse the entity graph. Obviously, it's going to be quite distinct for each enterprise, with all the different entities that they're going to have that nobody else has. What is really driving results in that RAG paradigm today?

Yeah. At Snowflake, we've actually been very fortunate. We acquired a company that I came with called Neeva, which was a web-scale search engine. And I was a user.

All right, awesome.

So we brought that technology into Snowflake to build out our search and RAG solutions. There, basically, what determines quality is the quality of the embedding model that you're using. Of course, there are more and more sophisticated chunking strategies for what you're indexing. Then there are other layers, like the hybrid search and the reranker that you build on top of it, and so forth. Increasingly, a core part of it is also being able to understand complex documents.

PDFs are messy. You have images, you have tables, you have multiple columns in a page, and so forth. Being able to handle all of this, extract information really accurately, and figure out which embedding model to use—whether you should use a multimodal embedding model or a text embedding model, and so forth—all of those are incredibly important. Increasingly, we're getting to a point where you can automate many of these things and reduce the complexity, so that a lot of what we used to require practitioners to do can be relatively automated at this point.

Now you're getting to a point where more interesting opportunities get unlocked. For a company like Snowflake, for instance, being able to do what we're calling analytical agentic document analytics is possible. What I mean by that is, let's say that you have thousands of PDFs and there's information in them. Let's say you have quarterly results over the last 10 years. Being able to say, "What's the average revenue over the last 10 years?"—and if that is in multiple different documents, being able to extract all of that and then do analytics on it—is now possible.

Overall, I think RAG is getting increasingly higher in quality and also simpler to build, and is increasingly more powerful for handling some of the new agentic use cases.

Would it be a fair distillation of what you've said there that you're trending more toward more powerful models? A project that I've been involved with recently is built around understanding forms that are often scanned on a physical scanner, forms associated with the sale of a car from either a dealership or person to person. These things, of course, have to get filed with the state and reviewed, and they're super messy.

So, working a little bit with a company that's using AI to automate that, I've really seen a pretty substantial simplification. Eighteen months ago, it was like you might need your specialist embedding model here and your table extractor model there, and all this kind of deep specialization. Often, they're not super-large models, but they're really dialed in on these use cases. Today, I would say Claude 4.5 Opus or Gemini 3 mostly just solve the problem off the shelf in terms of understanding those documents.

Certainly. At a higher cost, certainly inference-wise, but definitely at a much lower cost in terms of AI engineering time.

Am I right to say you're seeing the same trend of less specialized models?

There are different use cases. If you're going to process, in some cases, hundreds of millions of documents, you're not going to use Claude to do that. Instead, you want to use a specific embedding model to embed certain aspects. You want to extract the information so that you can reuse it later, and so forth.

But if you're talking about 1 or 2 documents, of course these large language models can handle them really well right now. So I still do believe there are different use cases, and those use cases call for different tactics and different models.

In terms of why you wouldn't send millions of documents through Claude, is it just about inference cost, or is there some other—

It's cost and throughput.

Oh, what?

So, just to give you an example, how long would it take for you to process that many documents? That's a challenge. At Snowflake, we have a document extraction model that we've built and fine-tuned. It is multiple orders of magnitude smaller than these large language models. That means it's substantially cheaper and much faster to go and process.

If the task is specific—I'm going to extract information and extract these specific fields—it's faster and cheaper to do that versus using these very large models, which are super capable but, again, will be limited in terms of how fast they can do this. And, of course, the cost is another issue.

So that's interesting. You're sketching out a little bit of a Pareto frontier, so to speak. At the simplest but potentially most expensive end at inference time, with possible rate-limit issues, we have our Claudes and other frontier models. You're in the middle with a Snowflake specialist model that's much smaller and does just what it does, but it's still something that's amortized over a whole bunch of enterprise customers that you have.

What are you seeing in terms of the other end of that spectrum? Is there still value in an individual enterprise trying to create its own super-specialized model for some of these tasks, or does that curve stop at the Snowflake-scale model?

Yeah, it's a good question. First of all, we partner very closely with all the large language model labs out there, and they have incredibly capable models that we use every day. There are some cases where our customers would want something very specific.

This is a case when a customer has large amounts of data and the use case is something that the model has not seen before. Then they have either strict throughput requirements or cost requirements. Those are the cases where a custom model, usually based on some of the other large language models out there, makes sense.

So we work with these customers to build custom models for them. But in most cases, a well-tuned RAG solution or text-to-SQL solution with the data that they already have and a frontier large language model is usually the go-to scenario.

I'm halfway through doing an AMA episode. One of the questions I got was, "Is fine-tuning really dead?" What do you think? So it sounds like you're saying it's not quite dead, but it's specialized and on the decline.

I wouldn't say it's on the decline. I think it is really well-suited for certain types of things. The best example is actually what Cursor recently did, right? At their scale, it does make a lot of sense for them to have a custom model that's doing their autocomplete.

Being able to figure out in which situations you need a custom model versus not is something that's evolving. Starting with the large language models makes a lot of sense, and then over time, as you have more and more data and if you have specific needs—either specific needs because of data or because of cost or throughput—that's when specialized models come into the picture.

You mentioned these partnerships that you have with the frontier companies. Before getting to that, would you like to shout out or highlight any particular open-source models that are your go-tos? We hear a lot about, obviously, the Chinese ecosystem continuing to open-source a lot more than the American ecosystem at this point. I don't know if you guys feel comfortable using Chinese models in your stack. I get very different answers on that when I ask that question.

What are the models that you guys go to today when you're thinking, "Okay, we're going to explore some new custom direction," either for all of our customers or even just for one customer? What are the handful of models that you go to as starting points to begin that journey?

Yes. For Snowflake, we have a platform where we offer a series of models, and then our customers choose which model they'd like to use. There are certain products where the model is part of the product and not necessarily a specific choice.

For the models that we offer, there's, of course, all the frontier models: OpenAI, Anthropic, and Gemini, as well as models from Meta, Mistral, and others.

Some of these models are open source; others are proprietary. We also have DeepSeek as a model that we provide for customers. In certain arrangements where our customers are looking to build custom models, some of them are open to using the model weights from these models from China. Others aren't, but it really depends on the customer.

Does that break down along industry lines, or is it more of an idiosyncratic gut feel on the part of the customer as to what they're comfortable with?

I think it's the latter, actually. It's not necessarily an industry-specific thing. We have customers in technology, for instance, who will say yes sometimes, or who will absolutely not touch some of these models. It varies for other customers.

Do you have a sense of how much they're leaving on the table? Are they leaving much on the table by cutting off the Chinese model option?

Models like Kwai are incredibly powerful. If they'd like to start with models like that and then fine-tune them, you can get very capable models. But you also have other alternatives. So it really depends on the internal policies of these customers to decide which route to go.

I'd say it's such a competitive space that I don't think there's 1 model that dominates it all, whether that's in the proprietary world or the open-source world. So there are a lot of choices out there.

On these partnerships, we've got announcements recently of partnerships with Anthropic and also with Google for the Gemini models. I believe there's also one, although I think it wasn't announced as recently, with OpenAI. I didn't catch anything with respect to xAI and Grok. Providing all the latest and greatest stuff to customers is at the heart of that strategy. But tell me more about some of the nuances of the partnerships. Is there an xAI relationship? If not, why not? And does it have anything to do with them putting women in bikinis all over the place?

I definitely want to get into how we're bringing these models to data, because that sort of is a bit of a narrative violation relative to what you typically hear: We can't use that because we'd have to send the data to them, and we're not comfortable with that. So I'm very interested in unpacking how you are reversing that and bringing the models to the data on the Snowflake platform.

Yeah, absolutely. Actually, let me start there because that's incredibly important for us. When we started the journey 2.5 years ago or so, we heard loud and clear that our customers do not want to move their data out of the Snowflake security boundary. Instead, AI needs to come next to data. And that gives them a lot of advantages. You can respect all of the security that you've established. You respect a lot of the governance on the data so that you're not replicating this data. The attack vectors shrink in terms of securing all of this information.

So what we have done, thanks to our relationships, is bring inference inside the Snowflake security boundary. That's accomplished through these partnerships, through the connections, as well as a lot of the legal guarantees around the data. Essentially, these models become subprocessors. There is no state saved in any of these models. That's super helpful for our customers, who are very sensitive, many of them in regulated industries. So when they're using any of these models, they know that the data still stays inside the Snowflake security boundary.

Does that mean, then, that the model weights have to come inside that boundary? And how is that happening?

Yes, absolutely. The IP still belongs to and is owned by the model providers. The inference is run by the cloud providers in their stack. The difference is, we have a series of guarantees to ensure data residency and to ensure there's no state left. All of those are through the relationships and deals we're doing with these model providers, as well as the cloud providers.

The cloud providers are key in this because they are certainly able to provide the inference. They're also providing the underlying physical infrastructure that Snowflake is built on top of. It's because both of those things are true that we can draw the right dotted-line boundary.

Is there more that I should understand about this? Of course, I don't know what I don't know, but it seems like the more you move weights around to different clouds and stuff, the more risk there is for you as a frontier model developer. I'm thinking of OpenAI and Anthropic. Google obviously runs its own cloud to a very large extent, although everything's showing up everywhere.

One of the fascinating things about this whole moment has been how many alliances, or at least partnerships, we've seen between big tech companies that previously were very much at odds with each other. With all the models showing up everywhere, I'm like, how has it been that none of these have really leaked? There seem to be so many people who work at these platform companies that if access isn't really well figured out, I don't know. It just seems like something would leak at some point, but we haven't really seen that.

We haven't seen the weights of a frontier model leak at all, as far as I know. And then people will speculate: Maybe some state actor might have stolen them and not told anybody about it. But we haven't seen fundamental breakdowns. So how should we understand how that is happening to seemingly such a high degree?

What role do trusted execution environments play? What role do other kinds of measures play? My general working heuristic is, like, everybody's hacked, everybody's pwned, like nothing is secure, and yet at the same time we seem to not be having catastrophic leaks. So how can you help a simple person like me understand how we're achieving that?

Yeah, I mean, as you called out, these are very sensitive, important IPs that belong to the model providers and are then secured by the cloud providers. They have a very strict series of requirements and setup to ensure that access is limited. Because they are the ones running the inference and setting up the environment, they've set it up in a way that is airtight.

I don't have a lot to say beyond that. I think they absolutely take security very seriously. We work with them. We understand how important it is. You talked about all the different risks that are out there that they need to protect against. This is something that both cloud providers and model providers, as far as I can see, are taking very seriously. And as we work closely with them, for Snowflake, of course, security is at the heart of what we do.

So we set up our own environment in a way that has all of the security considerations in mind. I'll just say this is an incredibly important area, and there is definitely a lot of focus in this area across all the parties.

How much would you say of this kind of security has reached the level of provable guarantees or cryptographic security, as opposed to more roles and access controls and things where there's still a more fundamental human element? I just did an episode not long ago with a couple of experts in formal methods, including a guy who's a VP at Amazon who's pioneered a lot of their use of formal methods to derive these security guarantees. But I'm not clear on how much of this is resting on “We have proven that this is secure” versus “We have a process that we feel good about and we want you to trust.”

This is not my area of expertise, so I don't have a lot of depth, but purely from talking to both the cloud providers and the model providers, when you start looking at all of the attack vectors and what is possible, it doesn't seem like the human factor is an issue. The way the systems are set up is inherently very secure. That said, in security, of course, you can never say, “Hey, this is completely airtight and it can never be penetrated.” But, as I said, security is taken very seriously, and I don't think it's necessarily a human factor.

The way the systems are set up is such that the execution environment doesn't have access to the weights. You cannot do a lot with it other than just run inference through it. So, by design, access to the weights is limited.

Okay, cool. Thank you. I'm always trying to get a little bit better read on that particular corner of the world, and it's not one that's as freely and openly available as some of us curious minds might like.

Going back to the models themselves, what's your read right now? This is another thing where I think people have very different intuitions. Are the models going to be commoditized, or are they going to be sufficiently differentiated as to maintain pricing power as we continue into the future?

There's also how you help customers decide which model to use for a given use case. Do you have an evals platform built in, or do you help them do evals? How do you help them think about staying agile so they can switch? Obviously, new models are coming out all the time, so if there could be something better, faster, or cheaper that you could upgrade to, you have to know with some confidence that you're upgrading for good reason. There's a whole ball of wax there. Take your time in melting it.

As you mentioned, the differences between these models are not large. Each model keeps getting better, and there is great, healthy competition out there between the model providers, which benefits companies like ours, our customers, and so forth. For us, because we're providing choice to customers, the second part of the question is also really important: How do we help our customers choose which model is the best fit for their needs? There are a couple of considerations.

For many customers, they do not want their data to leave, again because of data residency requirements. If they are, for instance, an Amazon shop, and today OpenAI is available through Azure or directly through OpenAI, that becomes a consideration. Some customers are okay with their data leaving that Amazon cloud boundary; others aren't. So that's one decision point.

The second one is, of course, from a quality perspective. Many customers will run evals side by side to decide which model is best suited for their needs. What's interesting is that some of these models are cheaper and faster, but when you add reasoning on top of them, the equation changes, right? Certain models are very good at certain things. Again, just to call out, Claude is incredibly good at coding and continues to be a great model for that. So we help our customers assess which models to use for their needs.

Does that extend to how much of that is a service, a consultancy-type relationship, and how much is productized at this point? Or do you plan to do more productization?

It is more productized than a service. On our product, you can easily choose models, do side-by-side comparisons, and run evals. For many customers, actually, it's not necessarily for the first reason: not all the models are available in their environment anyway, because as a company they've decided that only these models are approved, or only this environment is approved for them.

How often do you see people switching? This is even at my company. I started a company that I used to be the CEO of; I'm no longer. We're only 40 people, doing about $10 million a year in revenue. So we're not an enterprise. We can fly a little faster and looser, and we're also not in a regulated industry. We basically do video content creation for local and increasingly mid-size businesses.

I feel like we should be changing models more often than we do. Honestly, I feel like the leapfrog effect is happening so often. If I were to grade our own performance, I'd be like, “Eh, B.” We're definitely better than most, but I wish we were even a little more on top of eking out the latest and greatest performance from the latest and greatest models. But it's hard. It is hard to resolve sometimes. Even just human inter-rater disagreement is tough to overcome.

How does that play out at a larger scale? Do you see people saying, “Oh, we got a new Claude when Claude 4.6 hits”? How many people move to it in a week, a month, or a quarter?

I think it really depends on the use case. In most cases, we don't really see a lot of switching happening because the prompts get optimized for a certain model, and you get high quality because you've optimized them for that model. It's not as easy to switch without further optimization. And because the deltas between the models aren't large, and they keep improving on a regular basis, the need for switching isn't that great.

As you were describing this, I was actually thinking about Google versus Bing. At some point, Bing got to good enough quality, but there was the habit of continuing to use Google, the familiarity of the interface, and so forth, so switching wasn't as necessary. I don't think we're necessarily there yet for models. There's still a lot happening—a lot of innovation happening.

Also, for certain use cases, if this is a one-off, I'm going to run something and then do a side-by-side comparison, then you go pick the model that works best for you. But if you've already been investing in an application and have thousands of lines of systems and prompts that you've built, then there's a cost to switching. In that case, the gains have to be large enough to justify that cost.

I'm no Ben Thompson, but it seems like from your perspective, you would want to commoditize your complements and would want to do everything you could to reduce those switching costs, right? One of the virtues of being on the Snowflake platform would be that you've got all the things. But not only, ideally, do you have all the things, you can also have a much more unified interface than you would if you were going directly to the model providers.

I imagine there's a bunch of different things you could do over time. You've got things like DSPy out there, where you can say, “Sure, this is my one prompt with this model, but maybe if I throw it into DSPy, I can auto-evolve my prompt to be more optimized for some other model,” or whatever. Is this a goal? Would you think of it as a success metric to help people be very fluid in switching from model to model as you go into the future?

That's not how we think about it. For us, it really boils down to how we bring the most value to customers quickly. Choice is an important factor there, so we'd like to offer it, and customers make model choices for a variety of reasons. As I said, some of them have only approved a certain model. They have their own AI governance boards where they decide which model to use and so forth.

But for us, we start with the data at the core. Ultimately, anything that you do is as good as the data that you provide to it. A lot of the optimizations for us are about whether we can do a phenomenal job at the retrieval layer. Then, can we make sure that all of these models are optimized to the fullest extent, so that any customer choosing one or the other, for the variety of reasons I called out, gets the best-quality data agent, if you will, that they're building with us.

Okay, that's really interesting. What do you think that implies for the competitive dynamics between model providers? One takeaway you might have from that is that whoever has the best model at any given time wins. Of course, there are these other constraints, but leaving those aside for the moment, if I'm a customer with no binding constraints and I can pick whatever frontier model I want, it seems like whoever has the best model at any given moment wins that business and actually stands to keep that business, even if that business might not represent the whole enterprise's business—it's that particular use case that, you're saying, is stickier than you might think. Switching costs are higher than they intuitively seem. Having the best performance at the time it's initially evaluated is actually pretty important.

So I think model quality is incredibly important, but increasingly we're moving up the stack so that the product also becomes incredibly important. From a consumer perspective, ChatGPT as a product starts having its own kind of stickiness because you start using it and get accustomed to using it.

Similarly, on the coding side, Claude Code has its own benefits. You'll start writing your instructions and prompts to optimize for that workflow. So I think we're just moving up the stack. Model quality is absolutely central, but as quality keeps up across model providers, the next level of differentiation happens at the application layer.

So that's a perfect transition to talk about agents and what you guys are doing with agents. The way I structure my own thinking about agents is on a spectrum. On one end is the Claude Code-style choose-your-own-adventure approach, where I just give you the goal, essentially, and the agent breaks it down, searches around, greps around, and figures out how to get there. On the other extreme is potentially a totally linear, structured workflow where we're going to run a series of prompts one after another.

Claude Code is undeniably an awesome interface. But I often feel like people are a little bit too drawn to that, and I sometimes say that's a “don't try this at home” sort of project. By all means, go use Claude Code, but don't think that at your business you should be spinning up a Claude Code choose-your-own-adventure system. Probably, for most cases, I advise people that even still today, something more structured is probably going to get you more of what you want faster, in a way that everybody feels good about at the end of the project. What distribution are you seeing across that spectrum?

Yeah, I think it really depends on the persona using these tools. I'm a huge fan of Claude Code, and the coding assistance makes a big difference, unlocking great capabilities and clearly being very helpful for AI developers and builders.

If you're a business user who's just asking questions like, “What was my usage of this product over the last week?” as a product manager, for instance, I want a structured way to do this. I want an agent that's already optimized for that use case and has access to the underlying data. I do not want a Claude Code interface for this. I want something that I know will be high quality and optimized. That's kind of how I think about it. It really depends on the persona you're building for.

So for the talk-to-data product surfaces that you guys expose, where would you say you tend to fall on that spectrum? Is it that you're going to use these tools in this order, or is the model kind of choosing which tools to use at any given time?

We have a product that we built for business users. This is Snowflake Intelligence, where you can build a series of assistants for the whole company. For instance, we built a sales assistant and deployed it to 5,000 sellers. Think of it as a ChatGPT interface on top of all of the company's data, so that you can ask questions like, “What are my upcoming renewals?” or “How is my book of business doing?” and so forth, and you can get answers.

For that, clearly you want a highly optimized set of agents for those use cases. These are business users using it, and they need to trust the answers that they're getting. Then we have a set of products that we're building for data engineers and analysts to build data pipelines and analyze data. That is more of a coding assistant, if you will.

We have our own coding agent that's integrated into that platform, where they're either analyzing data or writing code. That is, of course, a lot more flexible, and it's also not tuned for a very specific set of use cases.

How do you think about the question of one big agent that might be long-running versus the other big pattern, which is your initial agent that then routes tasks to sub-agents? Back when OpenAI came out with its Agents SDK, it had this notion of the handoff as a really central idea. I was never quite clear on whether they were doing that because they thought it was the best way to maximize performance, or whether it was more a nod to the idea that these enterprises are going to use this thing, there are going to be different teams responsible for different areas, and we want to be able to modularize the work for human reasons as opposed to AI performance reasons.

With Claude Code, on the other hand, you give it everything it needs, let it make all the choices, let it run for as long as it can run, and give it feedback. It's one long agent that kind of does it all in one long session. Of course, I'm sure you could say that different use cases deserve different paradigms, but what do you see working the most in practice today?

Yeah, even in the Claude Code case, you have skills that are being developed, right? So you're still modularizing the different kinds of things you want Claude to do and then giving it instructions to go do those things.

I think the way you called it out is what I'm seeing, which is that, especially in large enterprises, you have different teams building different agents. You also have different agent platforms that are being used. For instance, if I'm using Salesforce to manage all of my CRM, maybe I'm going to build my sales-related experiences with an agent there, but I still want that agent to talk to this other agent I'm building for something else. Being able to do that agent handoff and coordination is emerging.

I wouldn't say this is necessarily top of mind for everyone. I think customers are still focused on getting this one agent right and working well before they start thinking about multiple agents coordinating with one another. But that's starting to become increasingly important.

For customers, one of the biggest considerations is that they do not want to be locked into a certain platform. They still want to be able to make sure that open standards are supported, so that agents can talk to one another, agents can use the tools built for one agent by another agent, and so forth. MCP and A2A are important protocols that our customers expect to be supported.

I was just going to ask about A2A. Are you seeing traction with that?

It's still early. We don't yet support it. We're starting to hear from our customers that they don't necessarily ask for A2A specifically. They do ask for ensuring that some kind of agent-to-agent communication is possible.

Is there any standard, protocol, or platform that's bridging the Salesforce continent and the various other continents of agents?

Today we either see a bit of a hack, where these different solutions are used as tools through MCP. The orchestrator still uses them as tools and then manages them. From an agent-handoff perspective, other than A2A, I haven't really seen anything else.

Yeah, that's interesting. One of the things I find very funny about this whole thing is that it seems to me like a fundamental property of intelligence is that everything—this is an overstatement; I don't mean it literally—one of my refrains is that everything is isomorphic to everything else. Meaning, you can always squish and rearrange and play hide the intelligence, and you can have a smart MCP that's actually an agent.

How you actually classify these things seems to be much more of a choice and much less a requirement imposed on us by nature, because the nature of intelligence itself is so flexible, fungible, subdividable, whatever.

Exactly. No, couldn't agree more.

One of the big things—a huge theme, right?—of the communications that I've seen from Snowflake in preparing for this is the importance of trust. So I'd love to hear your thoughts on what the dimensions and levels are that we have to hit in order for an enterprise to trust an AI process.

Yeah, I mean, just to reiterate, for us, trust is incredibly important. If I were to call out 2 important tenets, one is super ease of use: how easy it is to build out these solutions and then to use them. And, of course, trust is at the core of everything.

Trust spans multiple different dimensions. You have trust from a security perspective, then from a governance perspective, then you have the quality layer on top of it, and then there are evaluations, monitoring, and so forth. So it's a full stack.

The way we think about this is by running AI next to data. A lot of the core governance that's put on the data is, by design, respected in our system. What that means is, let's say you have sensitive data that's only visible to the HR team. If you go build an agent, the person who asks the question can only get the answer that they're eligible to see and nothing else.

This is super obvious and important, but because we have these types of very granular access controls from the ground up as part of the core data platform, building agents that respect that becomes much easier to do. Then you have governance at various layers, and, of course, the next level is evaluations and these other aspects.

A lot of the trust is in whether you're able to build high-quality retrieval of context to pass to the agent. Is the agent orchestrator doing a great job figuring out which tool to use and which trajectory to use to answer the question?

So, evaluations are a core part of the platform, followed by ongoing monitoring, getting feedback, and that cycle of improving the quality. From a user perspective, the way that trust manifests is when a user asks a question and we have UI elements that say, “Hey, this question has an answer that was verified by an owner.” Again, bringing that trust element into the user experience is another tenet of our philosophy.

So, did I catch correctly that at the data governance level, the shorthand rule is that the agent can only access the same data that the user can access? In theory, that could mean multiple users could come to the same agent and have different experiences because the agent has different data access based on the user who’s using it at the time.

Exactly. This is exactly what our customers are asking for, and that’s relatively easy to build on our platform. For instance, with the example I gave of our own sales assistant, if a salesperson comes in and says, “What is my book of business? Summarize it,” you should get an answer that is only your list of customers assigned to you, versus another salesperson.

If I’m an HR person or a manager, for instance, using an HR bot, and I say, “What’s the salary of this person?” I should only be able to see the salary of the person I have access to seeing, versus somebody else. Underlying it is the same agent, and it’s the access controls that govern what I’m able to see.

Yeah, interesting. On the performance and reliability side, my experience has often been—and sometimes it’s for good reason, certainly in the self-driving car realm—that there’s a certain logic to saying, “We don’t just want these things to be roughly human-level; we want them to be clearly a step up before we’re going to adopt them society-wide.” Good news: it seems like we’re getting there.

What do people have in mind as the intuitive standard of performance? Is it that they want these agents to be perfect? Is it that they want them to be at the level of the human who used to do the job? Is there some heuristic in the middle that you think people often land on?

Yeah, that’s a super interesting concept, right? The more natural the interface is, the more human-like intelligence we expect intuitively. If I’m talking to the agent versus typing, I think talking has much higher expectations. If I’m just typing, I know I’m typing to a computer, so the expectations become a little less high.

I don’t think that adoption of this technology requires human-like intelligence, because even for the specific things that these models and applications do well, that is such high value that you’re seeing huge adoption of AI already. And it keeps getting better at a super rapid pace.

Yeah, I’m very excited about the way the technology is evolving. Before going into your expectations for the year ahead, what are you seeing in terms of guardrails?

Obviously, one big pattern that I think is very natural to RAG is sourcing answers back to the document or the authoritative place from which they came. Beyond that, though, we’ve got this whole constellation of different patterns, right? You can filter inputs for appropriateness, filter outputs, log things, and post-process logs.

AWS has a really interesting new service called Automated Reasoning checks, where you can put in a policy, they convert your natural-language policy into a set of rules and values with a language model, and then they use literal formal methods to ensure that at runtime, the agent—or whatever the system gave you back—actually passes those formal reasoning checks that were originally derived from a natural-language policy. That’s pretty interesting and pretty cutting-edge from what I’ve seen.

But I think in most places, my sense is that the frontier model companies are doing a ton of this stuff. Anthropic has pushed this probably farther than anyone when it comes to preventing you from using Claude to do certain things in the biosphere. But are people at the enterprise level actually doing much of it, or are they just saying, “This thing seems to work, we’ve got an eval set, it passes, and we’ll go with that”?

I think the sophistication is increasing. Usually, companies start with products that are more internally focused. While it’s important, the bar is a little lower than it is for something that’s externally focused.

At Snowflake, we offer products to check for guardrails. They do things like check for hate speech, violence, and other violations. You can detect them and flag them, and not have the model respond. But we also benefit from all of the great work that, as you called out, companies like Anthropic do on their own models as a baseline.

The other thing that’s also super interesting is that as the models keep getting better, their adherence to instructions keeps getting better, of course. Some of these things also get codified as instructions to the agent. So, not only “Do this and that,” but also, “Here’s a policy that you need to comply with.” That tends to work quite well as well.

Have you seen anything in the interpretability realm being used for practical guardrail-monitoring purposes in enterprise so far?

We’re seeing evaluations become really important. A lot of what companies tend to do is create their own eval sets, but also use LLMs as judges across various dimensions to score what’s happening and then continue to monitor it on an ongoing basis.

As agents become more and more complex, it’s a pretty new area to understand: Is the agent taking the right route? Should I be optimizing it? Understanding where things go wrong becomes really interesting. That’s what I see—not necessarily in the consumer experience, but in the developer experience, where you’re seeing what the model is doing and what the agent is doing through evaluations and monitoring.

Yeah. So, you mentioned being excited about the year ahead. You also mentioned voice experiences. It seems like we’re at a moment, literally right now, where—I don’t know if people just had extra time over the holiday break or whatever to get into Claude Code for the first time for many people—but it seems like the discourse and expectations have really shifted in just the last 30 days.

People have said, “Oh my God, the coding experience now—it’s not just vibe coding and eventually hitting a wall and giving up. You can actually really make this work.” The next big thing that people are saying over and over again is that the same thing that’s happened to coding over the last however many months is coming to a great many domains of knowledge work over the next year.

Do you buy that hype? What do you think that looks like? Are we all going to be agent managers, or are we all going to be talking verbally to agents while getting lots more exercise than we used to? What is the 2026-plus vision for success?

Yeah, I’d love to see the world where I don’t need to do anything and I can just go get more exercise. I actually see the opposite. We’re able to do a lot more, and we end up doing a lot more, especially in AI, where everyone is sprinting. There’s more work and more productivity out there.

What I’m seeing is that agents are absolutely getting more and more capable. Coding agents, I think, as you called out, have passed this threshold where they’re a lot more capable, so a lot more people are using them. I think it changes how products are developed. It changes jobs like product management, for instance. I’ve been in product management for 20 years, and the way we build products has to change given the coding assistants. How you deploy quickly and how you test things quickly is changing because of how capable these coding assistants are.

That’s a combination of different things, right? One is that the agent can do a lot of things. It can code well, but also the reasoning capability of the agent is increasing. Tool use becomes incredibly powerful, so you can apply that to other domains. If you have the ability to figure out which tool to use, use it effectively, and then reason and figure out the next steps, that allows you to build a very capable agent across the board.

I don’t know—this is not a 2026 projection or anything—but I’m absolutely seeing clearly increasing capabilities with agents and also increasing use of them for production work.

Do you have a sense of how the progress in AI coding assistants or agents has changed how work is happening at Snowflake? Are you instrumenting that or measuring it? Obviously, lines of code would be too primitive, but perhaps features shipped or burndown points per cycle. Is there a way that you can begin to quantify the impact?

There’s the impact piece, but there’s also the philosophy that is changing. How we build products is changing, and that requires a change in behavior.

Usually, my go-to is, let’s say there’s a feature to be built. I’ll think about the UI, go and build this UI, and then go make it happen. Whereas with a coding assistant, if my users are also living in coding assistants, maybe it’s as simple as, “Let me just go build a skill for this thing and quickly test it out.” I can just write the skill in a day, put it out in front of my customers, have them use it, and get their feedback. Only when I know exactly what the shape of the product is can I go and solidify it into more of a consumer experience.

So, I think, again, product management is changing, and product-building philosophy is changing because of these coding assistants.

Yeah, a working prototype is the coin of the realm these days, for sure.

Yeah. Yeah. One of the big predictions that I’ve heard a lot recently, sometimes with a remarkable level of specificity, including from some Anthropic people, is that we should see the first drop-in knowledge worker products offered this year. Specifically, folks have said Q2 of this year.

What that means to them is basically a new employee that, at heart, is an AI, but will have a very similar surface to a remote worker on your team. It’ll have a name, and it’ll have all the same accounts—or at least you’ll be able to give it all the same accounts that you can give to a human employee—which means it’ll be on Slack and accessible via email. It’ll be all over the place and can probably join calls.

The expectation is that this will be good enough in Q2 of this year for people to start getting value from it, and that this will be a new product category. First, do you buy that this can happen that soon? Second, how many of your customers do you think will be eager to try something like that when it drops?

I do see that as a natural progression. Today, the agents that are being built are either automating certain processes from a productivity perspective, or they’re more like copilots that I can ask questions of and then get responses from, versus these autonomous intelligence entities, if you will.

When exactly that will happen, I think, really depends on how scoped you can get them. I don’t think that we’re at a point where you can just create another colleague that can do anything and everything. But if you can very easily scope the task, then I think that absolutely is possible.

I don’t know whether this is Q2 or not, but I do see it happening. And, again, as a data platform company, I’ll call out the importance of data. Ultimately, all of these capabilities come down to, for any given company, the differentiation being its data, and then access to that data—being able to figure out and retrieve the right types of data to answer a question.

Increasingly, it also comes down to the tools that are given to these agents to take action. I think that changes industries. It changes how we think of data, how we think about making data AI-ready, as well as making the tools AI-ready so that more and more capable agents can be built.

Do you see changes to data itself? I guess one that we’ve talked about already is just retroactively going back and applying structure to unstructured data, creating metadata, and so on and so forth.

In the wild, one big change that we’re seeing to data is that the web itself increasingly comprises AI-generated data. That’s a weird feedback loop that we accidentally created. Are there any other perhaps surprising patterns in data within enterprises that you’re seeing as a result of AI coming onto the scene, or is it maybe still too early for something like that?

I am seeing 2 things. One is that access is getting a lot easier, so that democratization of access to data and access to insights is a big shift.

The other thing that I’m seeing is that the value our customers get from data is increasing because you’re able to very easily glean those insights by just describing what you want in natural language and then getting it. The value you get from data is increasing, which opens up new and new opportunities. You start using the data in ways that you haven’t thought of before.

One interesting study—one of our customers is S&P Global—they analyze earnings calls to understand when CEOs are responding to analyst questions either directly or indirectly, or if a question was already answered in the opening remarks. They use that as alpha to determine which stock to buy. Stuff like that becomes very easy to build, and then new use cases open up.

Yeah, that’s an interesting metric. I’ve seen a bunch of stuff recently, even just over the last week. It was really the Venezuela moment, where all of a sudden people were bragging about how they had created these AIs that monitor prediction-market platforms, were looking for early signals, and were trying to capitalize on them. That’s going to be a really interesting phenomenon.

How about in terms of just—actually, let me go in a slightly different direction, and I’ll do maybe a little lightning round to close this out. I have this sense that right now we’re in this kind of expansionary phase. I’m no astronomer, but my experience with platforms in the past—and I definitely experienced this with the Meta platform, formerly known as Facebook—is that they came on the scene, opened up a ton of stuff, and everybody could tap into all this data and these social connections.

For a moment, there was an incredible flourishing of a ton of different ideas. And then after that supernova came the black hole, and it was like, “Actually, we’re going to close all this stuff back down.” A lot of the value that entrepreneurs created on the edges by experimenting with different ideas—the things that really mattered—mostly ended up getting sucked back into the platform. There wasn’t nearly as much value created on the margins as it seemed like there was going to be.

I might be over-indexing on this experience of having lived through this pattern once before, but I feel like the AI moment is set up for that to happen to a lot of people again. For example, just this week, ChatGPT launched a medical version, which is great. I think that’s going to be awesome for a lot of people. The fact that I can now just connect ChatGPT to an EMR instead of having to laboriously copy and paste, or find some other third-party thing to do that connector work for me, means that the consumer surplus of that is going to be amazing.

That’s my strongest belief: We will see high consumer surplus. But for businesses, it seems like it creates a very tricky balance where you’re saying, “I want to go do a bunch of cool stuff, but how do I know which of these things will be durable over time? How do I know I’m not just doing R&D for the next generation of the mega-platforms that are ultimately going to eat my lunch?”

How do you think about where you want to place your bets? What is going to get absorbed into the models versus what only you can do over a longer period of time?

I think we’re in a fortunate place because, ultimately, data is an incredibly important asset for all companies. That’s what defines and differentiates them, and that is not getting commoditized anytime soon.

As a data platform, we sit in that layer between the application and the model, if you will. The way we think about this is: How do we help our customers build very high-quality products catered toward their use cases, all powered by their data?

As for whether any of that can be subsumed by these other platforms, I’m sure the shape of products will continue to evolve. I think we’re still in the very early innings of a huge transformation. But I also believe intelligence is a commodity. Once these models are out there and there’s enough competition—and we’re seeing enough competition—the dynamics seem to be playing out in such a way that it’s all pro-customers and consumers versus these mega-platforms.

I do believe the competition will keep things in check, and the opportunity is so massive that the growing pie will also create lots of new opportunities.

Obviously, people have to have some place to keep their data, wouldn’t they? Tell me what’s wrong with this theory if I were to be a skeptic, or if I took the perspective of the Snowflake bear for a second.

A recent experience I had was that my company had been a customer of Intercom for a number of years. I was trying to do some basic analysis of recent tickets, and they didn’t have the dashboard to do what I wanted to do. So I went to their docs, and the docs were 100 pages of documentation. It’s a full-featured platform at this point, so there are a lot of docs.

The first thing I did was tell a web agent, “Hey, go compile all these docs.” It literally went page by page and copied them all into a Google Doc in a browser. I ended up with some 600 pages of text.

Then I took that to Gemini and said, “Okay, there’s a lot of repetition in here, but can you streamline it down to what I really need to know?” It fit even 600 pages, or whatever it was, into the million tokens. Now I had a consolidated, single view of the docs.

Then I went to a coding agent and said, “Here’s what I really want to do: Export all my data from Intercom.” That also ended up being one prompt to get it to work. It exported all my data from Intercom and was able to do the analysis I wanted to do.

But then the eureka moment was, “Wow, it’s never been easier to unplug from Intercom if I want to take my data somewhere else.” They didn’t really anticipate it being that easy when they created all these APIs.

So what prevents the data platforms of today from running into trouble there? In the past, presumably, if somebody were to say, “Hey, I’m not happy with you,” or, “I want a better price,” you had some leverage: “What are you going to do? You’re going to pull out all your data.” I’m not saying that would be easy, because I know you guys handle vastly more data than I have in Intercom. But it does also strike me that it’s become a lot easier to move things around.

It's become a lot easier to understand what it is, especially once you've gone and done all this metadata layering. So, what are the moats? What are the sticking points? Has it changed, or will it change? Is it going in the direction that you're calling out, which is, I think, great for customers and consumers?

Today, Snowflake supports open file formats for storing data. We support Iceberg, which is an open file format. What that means is you don't have to have your data locked in somewhere. You can put it in a managed place that's managed by you or by us, and then you can use Snowflake as an engine to process your data.

We are absolutely embracing and supporting the ability for our customers to use all these open file formats and not necessarily feel like they're locked into one platform. I think that's great for customers and great for innovation. Ultimately, customers will end up using the product that's going to give them the best performance and best cost for the things they'd like to do. We're absolutely embracing that.

Does that translate to increased pressure on you and your team? It would seem like maybe one way to think about that would be that, in the past, if somebody wasn't happy for a year, maybe they would start to think about a switch. Whereas now, it might be if they're not happy for a quarter. Does it shrink the timeline in which you have to deliver?

I love it. It's great for product teams, right? Ultimately, we're all driven by creating value for customers, building great products, and doing that as fast as possible. Competition allows it. It's a great incentive in the system to keep things in check and have you deliver.

I don't think things change for my team. We already feel pressure, not necessarily because of competition, but because of the opportunity. The opportunity is massive. Also, there's never been a better time to be a product manager, right? You're easily able to build awesome products very, very quickly, and then you're sprinting. It's incredibly satisfying to build these great products, and then you also reap the benefits by seeing how they're getting used in the market. I love the competition. I also love the pace of innovation in the industry.

Does that lead you to a big-picture point of view on this? This is a classic question, and again, it's striking to me how very informed and technically sophisticated people have very different answers. Where does the value accrue? How do you think about the breakdown of where value accrues? Obviously, we've got infrastructure, whether that's chip creators or owners, models, or the application layer on top. If you had to assign those 3 layers relative value capture from the AI opportunity, how do you think that breaks down?

Yeah, I think maybe the way I think about it is that the middle will erode and the sides will continue expanding. So far, we've been seeing a lot of value accruing to chip makers, NVIDIA, as well as the model providers. Then increasingly, application developers are able to build very quickly unique businesses on top of these capabilities. Cursor comes to mind as an example.

I absolutely do see the value continuing to accrue at the infrastructure layer as well as at the application layer. Traditionally, there's always been this middle layer that's facilitating and connecting those 2 things. Because of the capabilities of these models, that middle layer may not be as valuable or as important anymore.

And that middle layer is the models. Is that right?

No, no, no. I do believe models, in my opinion, will continue to accrue a ton of value. The middle layer is all the companies that are creating custom business logic for certain applications.

That business logic, as you called out—for instance, if you want to build your own extractor, you can just code it over a weekend and go do it, versus a company that goes and builds it for you. That layer isn't as important.

So, to try to play that back to you, it sounds like you think all 3 of the layers that I described will do fine, but at the application layer—

Traditional businesses will change.

Yeah. You're going more toward horizontal platforms and relatively less excited about vertical ones because so many SaaS applications essentially exist to encode business logic or best practices or whatever. We probably just don't need dedicated teams building out those kinds of things when we can have agents do it on the fly as needed.

That's what I'm guessing over time, yeah.

Yeah. Okay, cool. One other big question that I've asked a lot of people a lot of times, and I think you're the perfect person to touch on it: You, of course, know that Databricks acquired this company called MosaicML not too long ago, maybe 2 years ago now. What Mosaic was doing, I thought, was really interesting: starting with open-source models and working with particular customers to do continued pretraining on data sets, which I assume were very often internal data sets, like the sort of data sets that might sit in a Snowflake.

I was really surprised. I spoke to Ali Ghodsi, the CEO of Databricks, at an event not too long ago, and he said, “We killed that product.” So, they basically turned Mosaic into an in-house research unit, but they don't offer that product anymore—the continued pretraining to try to create a model that really knows your business inside and out.

I was very surprised by this because, if I'm GE or 3M, or any number of 100-year-old companies with millions of employees over the generations, and they have this incredible history and so much data that's accrued that nobody really understands at the company these days, if I could have a model that had similar command of that information—which only exists in my company and nobody else outside has ever had access to—given that foundation models today generally have world knowledge, I would think that would be insanely valuable for a lot of enterprises.

And yet, to my knowledge, we don't seem to be seeing many instances of, say, 3M GPT, GE GPT, or Pfizer GPT. Why don't we see that? Do you have a point of view?

I do. This is kind of similar to how, up until recently, when you'd ask a question on ChatGPT, it would say, “My information cutoff is a year ago, and I can only answer questions up to that point.” Then web search as a tool came in, and now all of these platforms would use web search to give you the most up-to-date information.

Their world knowledge can be updated. It's more about the intelligence to figure out when to use the tool to retrieve the information, then make sense of it and give it back to you, versus having been pretrained with all that information up front. To me, that pattern is exactly what's playing out.

In the enterprise world, you have a lot of information, and then your text-to-SQL and RAG solutions can bring that information in for the agent or the platform to reason with and then give you the information. The nice thing about that is that it's substantially cheaper. The model keeps getting better as the underlying pretrained model keeps improving, and it's also relatively easily tunable. You can update it, change things, and so forth.

That means, for me, the majority of businesses would continue to benefit from this architecture. Rather than codifying all of that information in the weights of the model, they'll just use the information and then use tools to retrieve the parts of the information that are relevant. The exception to that is what we discussed earlier: if there are certain tasks that require either high throughput or low cost, or if you have a lot of data in an area that the model has not seen before, then it might make sense to create custom models for those specific tasks.

I do believe there's going to be an increasing need for task-specific small models in large corporations, or whenever you have that need. Still, the majority of the use cases will be more retrieval-oriented.

I think that's a great first-pass answer. If I think, though, even just about my own ability to search through my own stuff—my own Gmail, my own Google Docs—one of the intuitions I have pretty strongly is that, if I were to give you full access to my Gmail and full access to my Google Docs, you couldn't search through it nearly as well as I can. And that's despite the fact that you're clearly smarter than me.

There seems to be something about the fact that I've had this free training on this corpus that allows me to search through it a lot better. Because, if nothing else, I know when I've found what I'm looking for. You might not know. You could do 100 searches in my Google Drive and never be quite confident that you've got the absolute best document for whatever the question is.

Whereas, if it's my Google Drive and I created all those documents, when I hit the document that is the one, that's, “Yes, this is the one. Now I remember this. This is the one.” So, I have that sort of confidence that I've gotten to the answer, if nothing else, I think. That strikes me as really hard. I've seen this when I try to give Claude access to search my Drive; it also struggles in that way.

It doesn't know how many times to search, or if it's found the right thing, or if something is satisfied too easily. So I still feel like there's something there where you could expect that a model that really had more familiarity with the data in the weights could do a better job of navigating it. And then maybe it just comes down to upgrade cycles being terrible for this kind of thing. As you said, you want to keep taking advantage of better and better models. Potentially, Rakesh has obviously influenced the discourse recently with a focus on continual learning.

So maybe you need either a new architecture that's more suited to that, or some sort of new training paradigm that would be suited to it. I guess maybe one way to phrase this is: if that were to flip—if you imagine a world a year from now where it's no longer the case that the best approach is to pick the best models and leave them as they are, but tune them through the searches you described, and it instead becomes one of these things where they actually do have this deeper familiarity with all the enterprise data—what do you think would have changed to flip us from one paradigm to the other?

I was trying to think about how humans do this. We'd go into an environment that we don't know, and then we'll do a bunch of searches, and then we'll read to create some kind of knowledge. Then, as you build out that knowledge, there's intuition that comes with it, so you don't need to keep referring back to it, and then somehow that turns into intuition, right?

Right now, I think what these models are doing is the first part. I'll go pick the information, and as the context windows of these models also keep getting better, I can stuff more and more information into these models and then get an answer. What intuition is isn't really understood, so I don't really know how that changes the dynamic. What would change if a model is trained with your data? You clearly need much less data to steer it in a certain direction. You'll have much more consistency in the responses.

I don't think you'll ever get away from feeding it information, up-to-date information, and so forth. But what I would imagine happening is, first of all, the model that you want to use for a certain task doesn't have to write a poem in French. So you'll benefit from using the weights more efficiently for the task that you want to do, and therefore, perhaps, again, you may not need as large a model. So you get benefits from more optimizations to reduce the cost, increase the speed, and so forth.

Yeah, I think that many-small-models paradigm is also one that I'm pretty bullish on for quite a few reasons. One being, I think we stand a lot better chance of staying in control of the meta if we have a lot of narrow AIs doing their jobs, as opposed to a relatively smaller number of giant AIs running things for us. The pull of that is obviously pretty strong, but I do worry that we're racing into having such general AIs that can do sort of anything before we've really thought through what the ultimate consequences of that are going to be. And safety through narrowness, and maintaining control through narrowness, I think is an underdeveloped paradigm.

I fully agree. That's, again, going back to the human analogy. That's how we operate as well. There are certain parts of the brain that are specialized to do certain tasks. So I can absolutely see that.

This has been amazing. A couple of quick closing questions. What are you watching right now in terms of horizon scanning for surprises? Is there a capability threshold that's on your mind? Obviously, nobody can keep up with the AI news these days, right? So everybody has to pick and choose. What are the areas that you're watching?

Maybe another dimension of that is: what are the metrics that you're watching? Are you looking at ARC-AGI scores? Are you looking at GDPval? Are you looking at the MIRI task length chart? Are there other metrics you trust to give you the highest signal on what is actually important in the latest things that are coming out?

I actually don't watch the public benchmarks as closely. We do have an internal series of benchmarks that I watch very closely in terms of quality and latency for the tasks that we're optimizing for. It's, of course, built on top of the models that we get from the model providers. Whenever there's a new model that's about to be released, we'll run our tests, figure out what's improving, what the gaps are, and then I watch that very closely.

In terms of technology trends, one thing that is maybe unique to Snowflake, of course, is that we have a lot of tabular data. That technology so far has been all about text-to-SQL and semantic models, so I watch that space quite carefully. There are some new trends happening in that space. These tabular foundation models are interesting, and being able to quickly build forecasting models and so forth is now possible. So those are other trends that I watch as well.

Yeah, that's an interesting one. There are a few public forecasting benchmarks and competitions. I think those are really interesting, too. At the point where the models are better able to predict the future than our best superforecasters, or even aggregations of superforecasters, that will feel, I think, like a very meaningful shift in what's going on in the world.

Any contrarian takes? Anything you think the audience at large might be misled or misconceiving right now?

I mean, we touched upon the one that's very top of mind for me right now. I think the way we build products has changed. I don't think it's contrarian, but I don't think it's happening fast enough. We're at a point where how we build products needs to radically change. And that means a change of behavior, because we've been trained to build products one way. So to me, that's the biggest one.

In a world where these coding agents are such capable platforms, how do you build new products? In my mind, it is all about starting with that first and then validating things quickly before you build a product in the first place.

Yeah, I think that's—I’ve been doing that with my mom. I made her a custom travel-planning app for the holidays. It's inverting that process, right? I made a version, she has it, and now I sat down with her this morning over coffee, and I'm like, “What do you want this thing to do that it can't do?”

And she's like, “I don't want to ask you to do more on this.” I'm like, “Mom, it's honestly so easy at this point. If you can articulate what you're missing, there's a pretty good chance we can get Claude Code to just make it, and you can have it from one session to the next.”

My last question, then I'll give you the final word. What advice do you have for enterprise leaders in general? Obviously, you guys are much closer to the core. For all the executives and product owners at the companies that you serve, what do you think they should better appreciate, or what can they learn from your experience?

There are some enterprises that are still quite careful about adopting AI, and at this point it is so powerful that there is a race. The faster enterprises adopt AI, the more benefit they're going to get, and the more intuition they're going to get that changes the trajectories of these businesses. So, to me, it's incredibly important to intuitively understand and natively use AI, because it is going to change industries.

Underlying that, many of the hesitations tend to be about getting the data ready for AI. From our perspective, that means investing in that core foundation to essentially get the data AI-ready for AI to use. So that means breaking down silos, getting the data accessible, and locking it in for certain use cases. That becomes a core enabler to build on top of.

Makes sense. We've covered a lot of ground. I really appreciate your time and jumping into all these topics with me. Anything else that we didn't touch on that you would want to leave people with?

No. Maybe the thing to call out is that we talked about a lot of great capabilities as well as trends. One thing that is sometimes not necessarily appreciated is how easy it is to use AI, and how easy it needs to be to use AI for adoption. That's an area for Snowflake that's super core. So as we build products, making it very easy to deploy high-quality AI at scale is something that we strive toward. To me, from a design principle perspective, that is key as well.

Yeah, couldn't agree more. Baris Gultekin, Vice President of AI at Snowflake, thank you for being part of The Cognitive Revolution.

Thank you, Nathan. Thanks for having me.