Snowflake Summit 2026 | Dwarak Rajagopal, Snowflake & Spiros Xanthos, Resolve AI

Clips
More from Snowflake Summit 2026

Dwarak Rajagopal

VP of AI Engineering and Research

Snowflake

Spiros Xanthos

Founder & CEO

Resolve AI

play_circle_outline Resolve AI SRE Agents: Faster Incident Resolution, Less Stress, Higher Developer Productivity

play_circle_outline Partnership with Snowflake to train custom models in governed enterprise environment

play_circle_outline Hybrid Model Selection and Verification with Continuous Evaluation, Nightly Testing, and Dynamic Configuration

play_circle_outline Business model: outcome-based credits pricing instead of traditional software licensing

Info
Transcript

Dwarak Rajagopal, Snowflake & Spiros Xanthos, Resolve AI

Dwarak Rajagopal

VP of AI Engineering and Research Snowflake

Spiros Xanthos

Founder & CEO Resolve AI

In this interview from Snowflake Summit 2026, Dwarak Rajagopal, vice president of AI engineering and research at Snowflake, joins Spiros Xanthos, founder and chief executive officer of Resolve AI, to talk with theCUBE's Dave Vellante and Rebecca Knight about how governed model training and purpose-built AI agents are closing the gap between AI experimentation and production-ready reliability. Xanthos describes Resolve AI as an SRE agent — an autonomous system that takes over on-call responsibilities by picking up production incidents, diagnosing root causes a... Read more

explore Keep Exploring

What does Resolve AI do, how do its agents and models help debug and run production software, and what role does its partnership with Snowflake play? add

How are you working with Snowflake to enable customers to build and train custom models? add

How does Resolve use and manage multiple AI models and agents (including frontier and custom models) to deliver solutions, choose which models to run, verify outputs, evaluate performance, and handle model performance changes? add

How does one transact business with Resolve AI — how is pricing structured (credits per outcome), do you forecast costs upfront, and how are change orders handled? add

bolt Powered by CUBE AI

Dwarak Rajagopal, Snowflake & Spiros Xanthos, Resolve AI

search

Rebecca Knight

>> Hello everyone, and welcome back to theCUBE's live coverage of the Snowflake Summit here in San Francisco, California. I'm your host, Rebecca Knight, alongside Dave Vellante. I would like to welcome our next guests to the show. They are Spiro Xanthos, Founder and CEO of Resolve AI ... Welcome.

Spiros Xanthos

>> Thank you.

Rebecca Knight

>> And Dwarak Rajagopal, VP of AI Engineering and Research at Snowflake. Thank you so much for coming on the show.

Dwarak Rajagopal

>> Great to be here, thank you.

Rebecca Knight

>> Yeah, we're excited to have you. So Spiros, I want to talk to you first. Tell our viewers a little bit about Resolve AI, and what was the problem you saw that needed to be solved?

Spiros Xanthos

>> Yeah. Resolve AI is building agents and models that can help you debug and run production software systems. The simplest way to think about us is we're the counterpart of coding agents for when software gets deployed and they become the defense. Our agents are on call, they can pick up any problem, whether it comes from a customer or automated alert, debug it, get the root cause analysis and what the solution should be. So that helps accelerate the time it takes to resolve issues, it creates productivity gains, and also relieves humans from this very stressful task. When something goes wrong, especially in the middle of the night, you have to resolve it before it impacts customers. So that's roughly what Resolve is. And to build this technology, of course we've got to build agents, but also now we're training our own models. And this is the partnership we have with Snowflake.

Dave Vellante

>> Does Resolve AI ... Somebody writes code. And then is one of the use cases you're checking the code, testing the code, or not necessarily?

Spiros Xanthos

>> I mean, there is some overlap in the middle when the code is about to be deployed. But the primary use case for Resolve is after the code has been deployed and is running in production. Resolve essentially understands code in the application, understands infrastructure. It can use, let's say AWS tools. It can use all the observability tools that you might have in place, like Datadog, Splunk, etc. So it's an agent that acts as a human engineer or site reliability engineer in essentially managing and debugging your production systems.

Dave Vellante

>> So a developer wrote the code with, say, Cowork or Coco and then maybe it was tested with Qodo something like that. Then you come in-

Spiros Xanthos

>> Yes....

Dave Vellante

>> because things change, right?

Spiros Xanthos

>> This has always been a problem. Traditionally, you always have to have humans who look after the production system in case something goes wrong. Why things go wrong? Because yes, it could be because of a code change or because it might be something that changed in the infrastructure or how users use the product. This has always been a difficult problem and engineers spend quite a bit of time in solving that. But now with AI and AI-generated code, it has become essential that we have AI as a defense because we produce a lot more code, and also I would say developers are probably a little less intimately familiar with the code that gets deployed. So Resolve essentially is the solution to essentially dealing with all of that, or an AI that helps you with production.

Dave Vellante

>> Should we think of it as an SRE agent?

Spiros Xanthos

>> Correct. It's an SRE agent.

Dave Vellante

>> Great. Awesome. Now, the SRE, obviously it frees her or him up to do other things.

Spiros Xanthos

>> Correct.

Dave Vellante

>> What have you seen in terms of their activities?

Spiros Xanthos

>> Yeah. First of all, delivering software reliably is the most important aspect of engineering, so there is a lot of value in ensuring that happens. It gives you confidence to move faster, to release code more frequently, etc. But then I would say this is also the stressful part of the job. Let's say if you can reduce the number of people that need to be involved in this, then they can go back to building. They can go back to essentially creating business value, which is the most important thing.

Dave Vellante

>> Yeah, yeah, good. Okay. You said you're working with Snowflake to build models, train models. Tell us about that.

Dwarak Rajagopal

>> Yeahs, so we are extending Cortex platform to actually train custom models in the safe governed environment. And one of the things that what we hear from a lot of our customers is, training customized models for their unique use cases, for their unique enterprise data is super critical. And one of the things that what we are making it easier for them to do is to basically enable them to just focus on that problem and not worry about infrastructure, not worry about distributed systems, not worry about GPU sourcing. All of that, we handle it, and so it makes it much more easier. They could now then start with open-weight models with like Qwen or Mistral, and then customize their models specifically for the use cases and then train that. So that's one of the big things that we've been building over there.

Dave Vellante

>> Why would a customer, Dwarak, come to Snowflake to do that? Maybe I should ask Spiros. Why would you go to Snowflake to do that versus going to, say, an AI cloud like a CoreWeave, or a hyperscaler? Why Snowflake?

Dwarak Rajagopal

>> I think the key element is two things. One is the enterprise data. Customers want to train where the data is already there. And when you take the data out, you lose some of the access control and all that stuff. So that's one of the key elements. The other one is some of the things that what we are doing at scale in a governed way. So you could enable training in a very safe way, but also you could govern what data is accessible and not. So that is one of the key elements and differentiation for Snowflake. Is that why you chose it?

Spiros Xanthos

>> Yeah, all these are valid. And from our perspective, we're an AI company. The domain we're in is very broad and wide. It's a very hard domain also.

Dave Vellante

>> Yeah.

Spiros Xanthos

>> And I would say it is already, let's say the state-of-the-art with what you can do with, let's say existing models. But what we found is, to go beyond that we have to actually start investing and training our own models. And of course, we want to spend our time as much as possible on the problem itself. We don't want to build infrastructure for model training if it doesn't count. And we found that Snowflake's, let's say abstraction for model training and the platform they're building, is the ideal for what we're trying to do. So it lets us scale, move quickly, but also focus on what's important to us, not just building infrastructure for model training.

Dave Vellante

>> So you don't want the bare metal infrastructure, you-

Spiros Xanthos

>> Correct.

Dave Vellante

>> That abstraction layer means you can focus on your higher level work.

Spiros Xanthos

>> That abstraction layer has to exist, so whether we built it or work with a partner, it has to be there, right?

Dave Vellante

>> It has to be there.

Spiros Xanthos

>> In our case, this is not what we're going to differentiate on, so it's better to obviously ... Given Snowflake provides this to us, it's a great win.

Rebecca Knight

>> Dwarak, your AI team built Cortex training. What was the customer problem that you kept hearing and why was it so hard to get it right?

Dwarak Rajagopal

>> Right. I think one of the key elements for AI training right now is, especially on the reinforcement learning, how do you do it in an optimized way, more efficient way? That's one of the big problems. The second one is, like Spiros mentioned, just the ability to scale GPUs that what you want in an elastic way for your training. Instead of customer needs to worry about actually, "I need this many GPUs for this many months," you basically have the ability to elastically scale. So those are the two big problems and that's one of the key elements that we are solving this with the Cortex training side.

Dave Vellante

>> How are you dealing with every earnings call I hear? "We're supply constrained, we're supply constrained." I guess that's not necessarily your problem, but it sort of is, it's second order effect. How are you dealing with that?

Dwarak Rajagopal

>> Definitely I think inference compute as well as training compute is a big currency right now. One of the things what our technology allows is to actually do some multi-tenant across different workloads within the same GPUs. So we could actually do much more efficiently and also give those savings back to our customers as well. So that's one of the things that we've been spending time to increase the efficiency for our systems as well.

Dave Vellante

>> Does it have a utilization impact as well ultimately?

Dwarak Rajagopal

>> Exactly. We dramatically improve the utilization through some of the technologies that we built recently. For example, ZoRRo, which is a Zero Redundancy Rollouts specifically for RL training. So things like that we mix a combination of these techniques to improve the efficiencies.

Dave Vellante

>> I hear a wide spectrum. The neoclouds tell me they get 90%-plus utilization, and I talk to the enterprise folks and they're like, "We're still trying to figure out how to use this stuff." What are you finding?

Dwarak Rajagopal

>> I think it really depends on the benchmark and the use cases that you want to use. And especially for very domain-specific custom training, I think utilization is something that is super critical for our customer to actually scale pretty well with better efficiency overall.

Dave Vellante

>> One of the big debates we're having in our community right now is, there's a camp that says the frontier model vendors, they're going to own everything. They're going to just gobble up. And these small, highly-specialized models are going to go away. The other campus says no. The small specialized models are just that. It's like specialized models. They're going to be much more efficient, much more cost-effective and more nimble. I know where you land, but defend your smaller model position.

Spiros Xanthos

>> I mean, it's not about the size of the model, by the way, because usually especially when you're doing post-training, you can start with an open-weight model, could be quite large. And I think maybe the debate even starts there. What is our belief? Is our belief that open source models are going to actually evolve at the same pace and be as good or close to as good as the closed models in the long-term? If we believe that, then it's easy from there to also extrapolate that training specialized models is also going to be something that's meaningful, because if you have data that's specific to your domain, you can do a better job. Now, also I would say philosophically, I don't believe it's easy to be the power plant and supply all the devices as well on top of it. And I think that because there is deep, deep expertise in every domain, and we see this with ourselves. I don't believe the labs possesses that expertise. Obviously we have great models, but I think at some point these domains are so deep and the end user wants a solution. They don't just want, let's say, a model to build on. So in that sense, I do believe that providing solutions makes sense, and for those solutions to be, let's say the state-of-the-art, it probably makes sense to have at least part of them started with custom models that you post-train for the domain.

Dave Vellante

>> So what are the domains that you're going after?

Spiros Xanthos

>> In our case, it's production. Obviously, we have seen that the models have evolved amazingly well in terms of coding, but production is a very different part. Yes, you still have code, but then you have many, many other tools, and the reasoning steps a human takes to solve the problem or to perform a task usually are very, very long. Also, production is very noisy. The data is practically infinite, doesn't fit in the context windows. So I think if you can manage to have models that do that reasoning better for this particular domain, you can have actually a big win compared to what frontier models can do.

Dave Vellante

>> Can you give us a sense of that win, just in terms of latency or other business value that you're seeing?

Spiros Xanthos

>> I think it comes down to two questions. Can you have state-of-the-art quality, outcome reasoning? And that is the big bet. But actually that matters, let's say for the hardest problems. The other thing that matters a lot, what is the performance-to-price ratio. And I would say for that, you can definitely do better than the frontier models by having your own custom models for many, many of the tasks that you're going to perform in production. We already see the tokenmaxxing probably is coming to an end and people are going to rationalize the investment. So in that world, I do think it matters to have a model that is great, but it's also more efficient for the problem you're solving.

Dave Vellante

>> The other debate that we have a lot, I'd love to pick your brains on this, is people say, "Well, you don't need the latest and greatest models." The other side of the camp says, "Well, the latest and greatest model is going to have the best price per token, the most efficient operations." I hear this all the time, that spectrum. I know it's a "it depends" answer, but what are you seeing out in the field?

Dwarak Rajagopal

>> I think the way from our experience, what we see, is that I think there is space for both, for sure. I see models as a way where intelligence is compressed within a model. Usually if you think about it, in a frontier model, the amount of compression it needs to put it in versus if you want to have a very specific business use case, where you could do a better compression with a domain-specific model. And so in that case, you could have both not just the speed and latency, but also actually accuracy in terms of how you get to that. For more generic care of use cases, frontier models are generally the best use case, best answers. But if you want to have very specific, like what Resolve is working on, that actually has a very good product market fit for a customized model to come and actually help.

Spiros Xanthos

>> And maybe I can give you a different perspective from how Resolve approaches this. Slightly different. I agree basically with what you said. But at the end of the day, Resolve delivers a solution. We have many, many agents that work together. Those agents are backed by different models. So even for the same task, you might have a frontier model which is ideal for part of the tasks, and then you have other models, sometimes custom models or sometimes actually a model from a different provider. So at the end of the day, you're thinking of a solution, you're not thinking of it's A or B. Typically, it's both of them working together in some formation.

Dave Vellante

>> So how do you use the frontier models? Do you use them all? Do you have a model chooser?

Spiros Xanthos

>> Yeah, we actually use pretty much at least from the three big providers' models. And oftentimes, because in the domain we're in, which problems are really hard to solve, sometimes we have agents have an adversarial approach with each other. One when agent makes a claim, we try to have another agent verify that. And even using different models to bug these two agents oftentimes helps with quality and the outcomes. So typically, generally speaking, the models we use change all the time. We run evaluations every night and it might change from day to day. And every time your model drops, the configuration probably changes. So that's the other part of building a sophisticated AI solution. It's not just about the model, it's how do you evaluate the models? When something doesn't work, what do you do about it? And that's, again, maybe where custom model training comes into play, because when you have gathered all this data and you know what works and what doesn't, you can probably produce something that works more effectively.

Dave Vellante

>> It's interesting, Rebecca, we're talking about training. People typically don't want to talk about training today, they just want to talk about inference. Training is expensive. That was yesterday's news. Now the news is all around inference. But what you just described, changes in the field, that requires inference. So explain how you go ... Trainings like they say while you're in college and an inference is when you actually go to work. So when you go to work, what is that transition like? How do you work with Snowflake in that regard?

Spiros Xanthos

>> Yeah, that's a good point. Actually, we're collaborating with Snowflake on inference as well, and inference in our case could be running on models, let's say, running inference on our models. But it's also frontier models, essentially using an API, whether it's on Anthropic API or an endpoint, whether it's on Snowflake or directly on Anthropic and OpenAI. But yeah, we're partnering with Snowflake on that as well, and obviously the closer, let's say, all your models are in one place, the more beneficial it is at the end.

Dave Vellante

>> And how do I transact business with Resolve AI?

Spiros Xanthos

>> Resolve, essentially we're not selling software, we're doing work. We're selling an outcome. The way Resolve works is that you can think of us as you can use the agents, let's say, to be on call, to do cost analysis of production incidents, or to perform other necessary tasks that a human would otherwise have to do. So you buy basically credits and then each one of these outcomes consumes a number of credits. If the agents do work, you get charged. If they're just sitting there, nothing happens. This is not a software subscription.

Dave Vellante

>> And you predict or forecast or propose upfront what my outcome is going to cost?

Spiros Xanthos

>> Yes.

Dave Vellante

>> And then if there's a change order, there's a change order?

Spiros Xanthos

>> At least for the use case of, let's say incidents and on call, typically you know how many of those you have in a typical month. So it's not that difficult to estimate how many you're going to need. Of course, as then the agents get deployed for more use cases, some of these use cases are less easy to predict, but then we'll provide daily, let's say report and analytics. So it's easy to extrapolate also.

Dave Vellante

>> And essentially, your economics are a function of token costs, right?

Spiros Xanthos

>> Correct.

Dave Vellante

>> And obviously you're humans, and then you add value on top of that-

Spiros Xanthos

>> Correct....

Dave Vellante

>> and it's got to be less expensive than humans doing it on the other side.

Spiros Xanthos

>> It is quite a bit less expensive. But also I think the problem we're dealing with is very, very hard and it's important. Delivering software reliably, especially for those who deliver their business through software, is the most important part of actually software. So if you solve this problem well, obviously you create a lot of economic value. That allows you to both spend on R&D, spend on inference, but also still have a very healthy market.

Dave Vellante

>> It's a quality play as much as it is a cost play. Yeah. Excellent.

Rebecca Knight

>> So where do we go from here? With everything that Cortex training has enabled now, what do you see as the future?

Dwarak Rajagopal

>> I think one of the key element here is what Spiros was saying, is that a combination of both using frontier models as well as the custom models as a solution, is going to be more and more abstracted away from the users, that some of these things would be handled across the things. And one of the key elements on the infrastructure challenges, for training we talked about inference being the hot thing, but not ... Like training is coming back in some sense. But a lot of the infrastructural challenges for training are actually related to inference. For example, RL actually requires a lot of inference happening at the rollout. So they are interrelated in terms of how the systems are actually being built, and so we do see both inference and training coming closer together the way the systems are being built as well.

Rebecca Knight

>> Excellent. Well, Dwarak and Spiros, thank you both so much for coming on the show.

Spiros Xanthos

>> Thank you.

Rebecca Knight

>> Really interesting conversation.

Dave Vellante

>> Thank you, yeah.

Dwarak Rajagopal

>> Thank you.

Rebecca Knight

>> I'm Rebecca Knight for Dave Vellante. Stay tuned for more of theCUBE's live coverage of the Snowflake Summit. You're watching theCUBE, the leader in enterprise tech news and analysis.