It could be several hours or days before the situation is fully resolved.

Fundamentally, what we're doing is when we have large complex software systems, we help figure out-- and they break, we help figure out what happened.

Having a team of on-call engineers twenty-four/seven looking at all of your data.

So by the time an engineer comes on to a Slack channel, the root cause or candidate root cause is already given.

So rather than them spending so much time trying to figure out what happened or, you know, calling more and more teams, 'cause typically what happens is you'll have one team look at the, the, the data.

They're like, "Oh, it's not my fault." Then they'll call another team and another team and another team.

That's how you go from five people to, like, eighty people on a channel, right? And so then rather than fifty people over an hour, it's like five to ten people for a few minutes just verifying the answer.

See visible.com for details.

Anish, how has that affected what brought you to solve this problem? So

yeah, thanks for having me, Dan.

My background comes from a totally different space.

It comes from research.

So I've been a researcher for the last 10 years.

I'm a professor at Columbia University, and I met my co-founders at MIT where we did our PhDs together.

And so our research has been in AI, and we focused on two areas, one being causal AI.

So what did a real incident feel like then? How has this changed working an incident for the folks right there in the war room or on the front edge responsible to get it restored? Yeah.

Why did you start to think about this as a problem worth solving?

Yeah.

So, uh, I'm the CEO and co-founder of Traversal.

We're building an agentic SRE platform.

This category is called AI SRE.

So SRE is short for Site Reliability Engineer.

So SREs have been tasked with the job of building resilient systems and along with that, operating these systems.

What are your thoughts on, I guess, why they haven't thought about solving this problem? Maybe they are now, but why didn't they tackle this market, uh, initially? I've got some other questions about how your role has also evolved from being a professor and how you've seen this major growth in, in AI, but just going back to that, why haven't the incumbents tackled this problem early on?

Are you taking that approach?

For code in production, the, there's obviously this general feeling of, of if you build it, you fix it.

Certainly that's the case.

But at the same time, when you think about the performance of a large scale system, it's less about the one piece of code you wrote- But how the entire system is interacting.

And the way that entire system is interacting is not going to be understood through a static analysis of the code, but it's going to be understood through things like metrics and traces and, and SLAs, right? And those SLAs and those metrics might be defined not for a specific piece of code, but for how the entire system performs.

And that work engineers can do, but I think having people who are specialized in that and site reliability engineers are the right set of folks to have done that, and that's why it's become its own specialized field and a very important profession.

So that's one thing.

Do you think it'll be possible to do L5 SRE or even will it be desirable?

Yeah.

Um, but I think...

If I think of the role of an SRE, um, the way I think about it is like, it's, it, it's all about the health of software systems, and I, I think of it as like the master hierarchy of needs.

So on your level one, you, you know, if you have a heart attack, you gotta deal with it right now.

And I think that's what having a production incident feels like, and that's where SREs have to spend a lot of time, where everything else, nothing else matters.

Level two is when you have these, like, constant stream of alerts happening.

That's the equivalent of having, like, some sort of, like, chronic condition that you have to deal with all the time, and you can't think-

Yeah.