Faster Code, Harder Incidents | Dreamforce 2026

Hello. Well, thank you all for coming. I am Jamie Lang, I'm Slack CPO, and I'm really excited to be sitting here with Spyros Xanthos from Resolve. And we're gonna talk a little bit about what we're seeing in the agentic coding space and how, you know, people are going beyond just single agents coding, prototyping up something faster, really revolutionizing the whole software development lifecycle, the whole resolution lifecycle, and what that really looks like in practice. So here at Slack, we just shipped code channels because we kept seeing this gap of really half of the context, or even more than half of the context that maybe the team needed to be able to move software forward now, it's actually sitting in your Claude conversation, right? Or it's sitting in your conversation with Codex or whatever coding agent you're working with. And a lot of teams are having trouble sort of managing the new PR creation lifecycle, the new way that the team is going to work together if so much activity is actually just happening with an agent in a silo. So that's what we were seeing with code channels and how people are sort of moving that into Slack. Spyros and I were actually just talking backstage about, you know, how there have been a lot of folks like him building into Slack, but without the tools they needed. And so, we wanted to make a change there. But you, Spyros, have been seeing this in a lot of different ways, and trying to help companies of all sizes sort of help move their resolution process into an agentic workflow. You know, not just the building, but, you know, when something breaks, when things don't go right, when something is wrong in production, how are teams actually working together to solve that in production today?

Yes. First of all, I'm glad to be here. We're big Slack users and big Salesforce users in general, so I'm excited to be on stage with you. You know, being a software engineer is a great job in many ways. The harder part of the job is actually, you know, running production or being on call when production breaks.

Yes.

And imagine, right, in the middle of the night, you know, your pager rings and you have to wake up, pick up your laptop, and, you know, frantically try to get to understand what's going wrong, right? And is it something serious? Is it something that maybe is impacting customers, and usually you have, you used to have at least very few signals from which you could essentially start. And then it was this process of essentially looking into, let's say, changes, code, looking into your logs, looking at your metrics, looking at dashboards, using a lot of your intuition and experience and understanding of code to try to decide what to do, right? Is this a serious problem? How do you solve it?

Right.

So obviously the way forward looks different. But I would say it is the hardest part of the job and it's only becoming worse because we now ship like 10x, 100x more code and we're much less familiar with all that code.

Right. Yeah, exactly. I find, you know, my fun fact, my husband is actually a software engineer. I've been around for many of those midnight pages. And what he's seen, and I think you're seeing this across companies, is the big difference is A lot of software engineers don't actually intimately understand the software that they're writing today. So how does Resolve show up in that situation to help that engineer who's trying to scramble through some generated code that they don't quite understand?

Yes. So first of all, production is very complex. In many ways, it's more complex than code, right?

Yes.

Usually when you're dealing with code, like you rightly pointed out, You have the code itself that maybe an agent or a human has to understand. And then maybe you have some context that oftentimes lives in a document or in Slack. In production, you practically have infinite data, right? Because you have all of this, but then you have logs that grow, let's say, every minute, every second, right? And all of that is a very hard problem for a human to understand. And it's a very hard problem for an agent or a model. So what Resolve did, we're a let's say an AI company, a full-stack AI company that builds models and agents to run production. The most common use case, which is also the most painful for humans, is on-call and incidents.

Yeah.

So Resolve has built agents that can be on-call. So going back to my previous example, instead of a human picking up the page in the middle of the night, a Resolve agent gets paged. It uses all the context it has about the environment, It has access to all the tools the same way a human does. So it will go through code, it will query Datadog, it will query Splunk or whatever the systems might be. And then, you know, decide if this is a real issue. And if it's a real issue, then it decides how to mitigate. And at some point, let's say if a decision is needed by a human, it will page a human, bring them into the discussion. Right. And oftentimes these things escalate to an incident. Right. Because it's a real customer impact. In which case now Resolve starts interacting with many other, let's say, agents, right? Oftentimes these agents can be human agents or other AI agents in trying to resolve an issue, right? So essentially, we're, you know, we call ourselves like an SRE, a generic SRE platform. And the goal is to essentially make the lives of developers, let's say, easier, but also improve reliability, security, velocity, and efficiency of production systems.

That's really incredible. That's a lot of trust that your customers are putting into the Resolve agents. How do you build trust in a system like that? I know a lot of us are maybe offloading parts of our jobs to AI, but I think, you know, it might be surprising to some folks here that you trust the AI enough to resolve some of those things on its own without necessarily having to page in the middle of the night.

It is a very hard problem because First of all, large-scale production systems are very difficult, very difficult for humans to reason when something goes wrong. And similarly, very difficult for agents, let's say, to reason about these problems. And at the same time, the stakes are very high as well. Maybe to contrast this with a coding problem, if you ask an agent to build a feature for you, the worst-case scenario is that maybe you ask it to do it again, or maybe you have to go through a PR and redo the work.

Yeah.

It's unlikely that there's going to be immediate impact if the agent does something wrong.

Right.

I mean, there is maybe long-term impact from some of the code the agent generates.

Serious.

Yes, but it's not something you pay the price for immediately. When you're dealing with production, the bar is very high, right? Like if the agent gives you the wrong answer or takes you down the wrong path, you might end up going from like a small issue to a serious, severe issue.

Exactly.

Yeah. Impacts customers. So to do that, essentially Resolve has to First of all, prove to itself, let's say, right, that every fact that it cites is actually true, right? And then it has to prove, let's say, to create a causal chain that explains the problem fully, right? And then it has to actually verify, another agent has to verify all of that, right? And then present all this evidence to a human and then present its confidence as well, right? So if you do this very well and you obviously have a high quality reasoning or high quality, let's say, of answers, Over time, what we've seen happening with customers is that actually they start trusting the system more and more, right? But trust is something you earn as an agent in production, right? It's not given to you by default. But once trust is there, actually the way people work changes, right? And changes in a dramatic way and makes actually the velocity of shipping software much higher, but also makes the lives of people who are dealing with this type of work much better.

Yeah, I mean, it's incredible. I think back to, you know, moments where I've been on an incident and people are trying to figure out what the root cause is. They're reading back through Slack channels, they're looking at support tickets, they're checking every dashboard, they're reading through the code, they're looking at PRs. Like, all of that takes so much time. And I can imagine being able to traverse that very large dataset with a— as a trusted agent, with a trusted agent by your side. I think that that would just be such a game changer for so many organizations.

And, you know, You're making a very good point, right? Because you have all this data and oftentimes in large-scale systems, you have many issues happening at the same time.

Yes.

Yeah. Not only you have to be able to understand what's going on, but you also have to understand what is maybe, let's say, background noise.

Yeah.

And what are maybe unrelated problems that may be real, but maybe one of them is what you care about, right? That may be causing, like, let's say, customer-impacting problems, right? Right.

I mean, I think about, like, the example of in Slack, Often, it will look like the typing lag is like, there's just like a typing lag issue. But most of the time when there's a typing lag issue, there's actually like a memory leak upstream, and that might be caused by a problem with the Electron app. Like, you end up having these like radical networks of failures. And if you have a smart friend to help you through that, I think that could be really incredible. One thing I wanted to get your take on, 'cause I know we are seeing at Slack, a huge breadth of AI sophistication or AI adoption depending on the companies. I wonder, you know, as you're working with companies to help them think about how to make AI a critical part of their production systems, what kind of differences are you seeing in orgs in terms of maybe their maturity or their AI readiness? If you could give, give some examples across, across different—

So Resolve is used by many, many like large-scale technology companies, let's say, and enterprise companies, right? Salesforce is a customer.

Yep.

DoorDash, Coinbase, Snowflake, Robinhood, some of the largest and most sophisticated, actually, honestly, engineering teams in the world are using us, right? And also we're working with many companies now, let's say, that maybe it's the next wave, right? That are, you know, they have more process usually, they're not the earliest adopters, and they're coming in using AI for production. So honestly, what I've seen happening is that These, let's say, more early adopters or the most advanced companies actually start trusting AI a lot more, right? Because they get the proof points, they see what's happening, and then they see the difference that that makes, right? So we've seen all of these companies obviously having universally adopted, let's say, coding agents for writing software. And I would say probably many of them, many companies that look like Resolve, let's say, right? Or maybe even like Slack, probably create 100% of their code at this point, right? I don't think it's being written anymore. And now as we do that, right, and as we produce 10x, 100x more code, the bottleneck moves to the next stage, which is how do I run this reliably in production without losing nines of reliability, right? And I think what I've seen with these more, let's say, early adopters of AI in production is that they trust the AI to do the work, right? So we have many customers now that have Resolve as the primary on-call, right? They start essentially having Resolve as the first, let's say, agent that picks up a problem when it happens. And why is that? It is because Resolve, an agent, let's say, can react a lot faster, right? And then you have the confidence that the answers are high quality. Then in fact, you improve your time to resolve issues, you improve your reliability. And like I said, you improve the quality of the lives of the people. And one thing I noticed is that, let's say 6 months ago, people would use Resolve to produce, let's say, an RCA, right? A root cause analysis report.

Yeah.

So that they could decide what to do next. But then when Resolve started actually holding the pager, let's say, right, and making the decision, it became so much better because the cognitive load is still very high even if an agent gives you an answer, right?

Absolutely, yeah.

Because we're dealing with very complex problems for which, let's say, even if an agent gives you the answer, you as a human have to spend a lot of time thinking to see if you agree or disagree, right? But the moment essentially the agent starts making the decision, assuming you trust the agent, your life and your job and the velocity becomes so much higher, right? It's almost like going from, let's say, lane assist in your car to FSD, let's say, right? Once you move to FSD, in some sense, your, let's say, cognitive load drops so much. And then you can spend your time or what you do thinking about other things, right?

Yeah, yeah. I think one of the things we've seen as AI has matured— and I think Boris from Anthropic talks about this sometimes— Building for, you wanna build for the capabilities that are going to exist in the next, you know, the next couple of model releases instead of thinking about how do I hem in this model or how do I build like exhaustive support around this model? How do you think about, like when you're thinking about, you know, you've gone from we're building the root cause analysis to we're now holding the pager. What do you think of as the next sort of job you wanna build for, you wanna give to Resolve?

Yes. So by the way, that's a very good way to think about it and that's how we think about the problem, right? Because, and we're training our own models, right? And we can talk about this if you want as well. But it's exactly that, right? Like I would say, Resolve was a very useful, let's say, RCA tool 3 months ago. But still, it wasn't, let's say, to the point that we would actually make the decision.

Right.

Today, it's at the point where it can at least make a decision and mitigate a simple problem. But that's really still at the, you know, early in the journey of running production, right? So the next stage for us is not only doing this, let's say, for simple problems, but really mitigating and remediating, you know, bigger issues, right? And by remediation, I mean not just like solving the immediate incident, but then going back and looking into the code, looking at the history of what has happened and suggesting improvements to the overall system, right? Not just solving the urgent problem, but improving the quality of quality, let's say cost, whatever might be the goal, security, right?

Right.

So that's step 2, right? But then eventually what the goal for Resolve is, is to be like a fully agentic SRE that can pick up any task as open-ended as it might be, right? Do the work, reason for as long as needed, and then get it done, right? And get it done, you know, with very high quality, confidence in the answers, and, you know, probably lower cost, let's say, right, than what it would cost you otherwise.

Yeah, that's so interesting. One of the things I'm just kind of curious about as you think about incident response and quality of life, I know so many engineers love writing code. A lot of engineers actually don't mind being in incidents because it's kind of fun, but they hate getting paged.

I'd love to meet, I'd love to meet this engineer.

No, no, I mean, I, so I, I, I've been alongside engineering teams in an incident. You get a lot of satisfaction from solving the problem.

I mean, in my 9 to 5 years.

Yeah, exactly. But you don't want the page at night, right? Nobody wants to get woken up in the middle of the night. Nobody wants to be putting their life on hold, uh, just in case something breaks. Um, I'm curious, uh, how the, the addition of Resolve as somebody holding the pager has kind of changed how people think about who gets to build software as well, if you're seeing any shift there in companies? Because, you know, with code channels, one of the questions we get asked a lot is, okay, but like if that breaks in production, then who gets the page if the lawyer wrote the code? If you have an agent helping you to fix all of that, does that sort of change who gets to build? And are you seeing that in any of your customers?

Yes. So I would say like Resolve is primarily a professional software engineering tool today, right? The same way that the coding agents, let's say, primarily—

Largely primarily.

But I would say, as the abilities of these, let's say, of our agents and our models improve, I do see like actually the, like when we move, let's say, from being an on-call and instant agent to being like a full SRE, right? That essentially you can hire for the job. Then actually, as you can extrapolate, that should enable somebody who's non-technical, let's say, right? To delegate the work to resolve. without they themselves being experts, right? Today, you still have to be an expert, let's say, to be able to judge the work of these types of agents, right? But I would say as the abilities of these agents move to that close to a human, let's say, expert ability, obviously then anybody, let's say, should be able to hire and delegate work to agents without themselves being experts. They can be the CEO, let's say.

Totally.

Like myself.

And just have a whole team. I mean, everybody could have more SREs, I have to say. I feel that way at Slack constantly. So much, everybody's always, you always want to innovate. Everybody wants to innovate, but nobody necessarily wants to hold the maintenance burden for all that code.

And by the way, this is an important point too, right? Because I would say, like I said, I think software engineering and engineering in general is a very interesting job in my opinion, right? It's very creative. And I would say like the, but there are parts of the job that are not actually, you know, that enjoyable, right? So having agents accelerate the creative part is desirable, but I would say it's even more desirable having the agents take the difficult parts of the job, right? And that's true obviously for any profession, right? But in our case, I would say like running production and especially when you're under stress in an incident, it is very desirable to have an agent help you.

Absolutely. I mean, I think you wanna be able to feel like you, there's nothing worse than working an incident and being the only person working the incident, right? So even if you have to get paged, having a trusted partner along the way who can carry a lot of that burden for you, I think that's, it's a real game changer. I think, you know, one thing people worry a lot about AI slop. We've talked about trust. I'm curious how you think about accuracy and really judging the quality of the work that Resolve is doing. You know, it's going to— you mentioned that the agent could make the incident even worse. It could break even more production systems. How do you engineer for that trust you were talking about earlier?

Yes. So like I said, because the stakes are usually high when you're dealing with production, you know, the mistakes are very costly, right? And, you know, you have to be able to essentially build a system that, you know, has proof that the output is very high quality, right? So that's why we also built a lab ourselves, right, at Resolve. And we're doing frontier research on, let's say, both the agents, the inference, but also what kind of models do you need to be able to improve the quality, right?

Right.

I mean, at the end of the day, I would say it comes down to being able to measure the output of the agent. And the way we do this is we have essentially thousands of cases where we'll let the agent go solve problems and then measure the output. And then compare that oftentimes to what a human would have done or has done in the same scenario.

Right.

And the goal we have for ourselves is that the agents produce, let's say, at least as high quality, let's say, answers They are right as, let's say, they're right as often as humans are, ideally more often. And they do that in a much less time than a human would take. And that at any given point, we know exactly which types of cases, let's say, that is true for. And we know where the agents are not yet able to do to solve the work. And that allows us also to provide, let's say, highly accurate and confident answers that we can back with this data. And also allows us to know where to develop AI next. What are the things that agents cannot do well today?

Right.

And that's where we put our effort in training our own models as well.

You mentioned before that like a lot of the very AI-forward companies are quick to adopt Resolve. I am curious how, you know, you thought maybe 100% of Slack code is written by an agent. I have to say, we have some people who are hesitant. Maybe they're still only thinking about agents as really being good at writing tests or taking like specific parts of the job. In fact, a lot of those folks are the folks that fit the SRE profile because they have a lot of ownership, you know, they have a lot of expertise in that area. How do you gain trust with that kind of engineer? And how do you think about that in that high-pressure moment of that first incident?

And by the way, I don't think there is anything wrong with what you're describing, right?

Absolutely.

I believe that, you know, as we, those of us who essentially try to build AI, you know, we, The burden of proof is on us and the bar is very high, right? I would say maybe to go back to my previous analogy, like, you know, we let cars drive on their own on the street after they have proven that they're more safe than human drivers are, right?

Yeah.

I think the same bar applies to agents in production, in my opinion, right? And that's the bar we hold ourselves on, right? So, and I get it when somebody is an expert and knows the system very well, you know, they probably don't want to give the trust, you know, upfront, right? I think it's a process. And honestly, I think a couple of observations I have. First of all, I think like in the past, let's say enterprise software might have been adopted by, let's say, tech companies. And then maybe a different version of that almost got created later on for like large enterprises. I think that's not going to happen anymore, right? I think like the velocity is so high that the same, let's say, technology that maybe a Slack or, you know, a Coinbase or a DoorDash uses, It's going to be the same that the large bank is going to use as well, right? You know, the adoption is going to follow in some sense.

Yeah.

But that's what we observe happening in the market, right? And again, I think that how much of that you adopt, it's up to you, right? Like maybe if you're working for a large organization where the, let's say there is either compliance issues or, you know, security is maybe more strict, you don't have to make Resolve make the decision, right? It can still be there, give you the answer. And then you as a human can be in the loop to decide. But, you know, obviously that's not going to last forever, right? And all these organizations are going to transform, in my opinion, so their SDLC looks more like that of maybe a Slack or a Resolve.

Yeah, yeah, yeah. I think that's definitely true. One thing I've said, you know, in other conversations, how do you have agents build trust? I think about it in a similar way to how working with any coworker builds trust. If you see the thing do a good job, you're going to give it more jobs to do, right? And I think having that sort of like human-in-the-loop graduation path to full autonomy makes so much sense, even if it at a company level, but also sometimes just at an individual user level to be able to inspect it and understand like, okay, I see what was happening here. That looks like pretty smart. I agree with this. Maybe I'll just let it do it on its own the next time around.

Correct, exactly. And then there's also what is the value of the trust I give to an AI, right?

Exactly.

'Cause if the upside is very high, I'm much probably more willing to work with the agent to give my trust, right? Because if I don't have to get paged, for example, in the middle of the night, I'm going to be much more motivated probably to work with the agent to ensure that the quality is high so that that work can be automated.

One thing I— we didn't talk about this beforehand, but one thing I've noticed with coding agents, and I wonder if you're seeing the same thing with Resolve, is expectations change very rapidly. So, you know, the first time you work with the agent, you're like, oh, wow, this is magical. The second time you work with the agent, you're like, okay, it's doing a thing. The third time you're like, why isn't it doing faster? The fourth time you're like, why, why did it get anything wrong? It should be perfect. How, how do you think about managing those expectations both in a, you know, build, continuing to build trust, but also, yeah, on the other side, as you're adding more functionality, how do you ensure that people aren't just going back to your, your agent for the exact same things over and over again when you've added More capabilities or it has more capabilities now that you should trust it for.

Yeah. And by the way, like I think the way we build software has changed, right? And, you know, in some sense we don't think of like features, we don't necessarily, I mean, these are important, right? Especially when it comes to enterprise controls and all that. But the way we think about Resolve, we think of it almost as a human agent, right? In the sense that what we want to optimize is how high quality the answers are. How many of the tasks that humans give it can complete very well. And how fast and costly it is, right? And we know every month we measure, or every day really, right? We measure all of these things. And the goal is to make progress forward in each one of these things, right? And as this happens, let's say, as the AI becomes better and better, you can see that it's being trusted more, it's being used more, and more work gets delegated to it, right?

Right.

And again, goes back, right? It creates more value for the users who are using it. You produce essentially more software, higher quality software, at higher velocity while people are not suffering, right? Humans are not suffering because they have to deal maybe with a lot of slop that AI creates.

Absolutely. Yeah, yeah, yeah. So I guess, I mean, you've touched on this a few times throughout, but I think like the bigger question everybody is kind of asking is we're sitting in this moment where we have so much innovation moving so quickly across so many different parts of the ecosystem. What do you really think is going to happen? In your mind, a year from now, we're sitting on the same stage. I'm not even, I'm not gonna very far future cast this. Let's just give us 12 months. What does building and maintaining production code look like for, let's say, like a Coinbase or Robinhood or one of your core customers?

You know, at the pace we're moving, I do believe like in a year from now, we're gonna have like essentially agents, SRE agents in our case, that are going to be, let's say, general purpose completely, right? They're going to be able to be on call. They should be able to actually resolve incidents on their own or be, let's say, indispensable in those scenarios. And you should be able to delegate any type of work you have, right? And what this should enable, it should enable us to move a lot faster, at least in those environments you're describing, right?

Yeah.

Move a lot faster, produce probably 10, 100x more software, right?

Right.

And I think, I don't think that means fewer engineers actually. In my opinion, means a lot more software. And that's great for the world in my opinion, right? It should allow us to solve problems that maybe were too expensive or solve problems that were too hard and generally create more economic value for, let's say, these organizations, but also the world in general, right? I think it's a very bright future. And I do think it's one where agents essentially are running soft— create and run software systems and us humans move at a level of abstraction above that.

Yeah, I think one thing we've always said at Slack is we want to make space for the humans to do the things that they're uniquely good at. and take the rest of the work out of the equation. So that feels incredibly aligned to, to how you're thinking about it. And I would say personally, as a product leader, I know that there is no end to the things that we would like to create. If you doubled my software team, I would have no problem, or say software capacity, I would have no problem coming up with more things for them to build. So I completely agree with that. Before we go, do you have any last things you want to—

I want to maybe touch on what you just said, right? I do think that, you know, so far the limit was essentially how quickly we could produce things, right? And some things were, you know, let's say maybe too difficult or maybe would take a lot of time, right? I think now as software production gets automated, right, the software factory gets placed, and that means both like the creation of software and the running of software, I think human creativity is unlimited in my opinion, right? The things that we can create, Probably it's probably the, you know, it's gonna be a lot more than we have done so far.

I think the other thing, the other thing you've touched on a ton, which I tell my teams all the time, is it doesn't have to be a trade-off between speed and quality. Like with like self-maintaining software, like you're saying, there's no reason for there to be bugs in production actually. Like if we could get to a place where we have sufficiently intelligent agents and great detection and monitoring, we should be able to fix any problem that we see. There's nothing that is too small to get on the backlog.

In fact, I argue if we do what we do well, let's say in a year from now, software quality should be improving actually.

Exactly.

Right? Because agents should be able to have a broad understanding of the entire system, right? Understand where the weak points are, right? Where all the quality issues come from. And, you know, let's say effectively learn and go improve the whole system, right? Not just what breaks.

Yeah, exactly. And then on the other side, one of our core product principles at Slack is that we like to prototype the path. So we like to try to build things to see if they're useful. And in this world, there's also no reason to not try anything. And so I think you're absolutely right. I think there will not only be more software, but there will be better software and more people will be able to build it.

So— Thanks. And, you know, maybe my closing statement, right? Like Resolve is— we're based in San Francisco. If any of you are interested to work in AI—

I was gonna say, give your pitch.

Yes, we have— no, I would just like a quick thing, right? Like we have Resolve. You know, is a very technical company. We have a lab as well. So folks who either do research or build software, we're very happy to talk to you. And of course, if anybody essentially wants to maybe help use agents for production, for on-call, for incidents, for reliability, or for automating production in general, I'd be happy to talk to you.

Yeah, it's really, really incredible what you guys are doing. And I think it's solving one of the most common downstream problems that people are concerned about as we're thinking about software proliferation. And I am really excited to have you as a partner and a customer, and I wanna thank you so much for your time.

Thank you. Thanks a lot for having me. Thank you.