From DevOps ‘Heart Attacks’ to AI-Powered Diagnostics With Traversal’s AI Agents

Anish Agarwal and Raj Agrawal, co-founders of Traversal, are transforming how enterprises handle critical system failures. Their AI agents can perform root cause analysis in 2-4 minutes instead of the hours typically spent by teams of engineers scrambling in Slack channels. Drawing from their academic research in causal inference and gene regulatory networks, they’ve built agents that systematically traverse complex dependency maps to identify the smoking gun logs and problematic code changes. As AI-generated code becomes more prevalent, Traversal addresses a growing challenge: debugging systems where humans didn’t write the original code, making AI-powered troubleshooting essential for maintaining reliable software at scale. Hosted by Sonya Huang and Bogomil Balkansky, Sequoia Capital Mentioned in this episode: SRE: Site reliability engineering. The function within engineering teams that monitors and improves the availability and performance of software systems and services. Golden signals: four key metrics used by Site Reliability Engineers (SREs) to monitor the health and performance of IT systems: latency, traffic, errors and saturation. MELT data: Metrics, events, log, and traces. A framework for observability. The Bitter Lesson: Another mention of Nobel Prize winner Rich Sutton’s influential post.

• 0:00Speaker 00

  If you're in product, if you're in design, if you're in core engineering, you constantly have to make bets as to where AI is going to be six months from now. And then you're willing to reevaluate everything six months from now. And the good news is that it's only going to get better. So it's not like your product's going to get worse six months from now. And so, for example, one really interesting thing, bet that has paid off is Raj and Raj were very prescient about the fact that reasoning models are going to get better. They'd made this bet in September, just seeing where the world was going. And we architected our system such that the reasoning models would get to shine. And that has really paid our dividends right now in the way our entire architecture is set up.

• 0:57Speaker 01

  Today, we're excited to welcome Anish and Raj, co-founders of Traversal. Traversal is building AI agents to transform the world of DevOps and site reliability engineering. Today, companies have war rooms and armies of DevOps and SREs, troubleshooting their production failures and fixing them in the codebase. Every minute of production downtime is costly, and sometimes life or death. Keeping a company's application running is very hard and valuable work, and it's a problem that is only getting worse with the advent of AI-generated code and vibe coding. Traversal believes that agents are the scalable solution to the problem and has seen exciting results already from the troubleshooter agents that they've deployed into production. We're excited to have them share more about that vision and their results so far.

• 1:39Speaker 02

  Anish and Raj, welcome to Training Data. So wonderful to have you today. We have been working together for a year, and we can't wait to share with our audience how AI and AI agents can transform the worlds of site reliability, engineering, and DevOps. And somehow, we need to weave Negronis in the conversation someplace later on, but we'll get to that. Let's start with some quick hot takes. Will DevOps or SRE, as we know them today, even exist five years from now?

• 2:11Speaker 00

  Yeah, it's a great question. I think it will, but I think it'll look fundamentally different from the way it looks now.

• 2:16Speaker 02

  How so?

• 2:19Speaker 00

  In this world of DevOps and SRE, I think healthcare analogies generally fall quite naturally, I find. And in this world, if you think about healthcare and the Maslow hierarchy of needs there, imagine the stage one is where, let's say, you're having a heart attack. You have to solve that right now. Nothing else matters. Nothing matters five minutes from now, other than solving the heart attack that you're having, right? And to me, that's analogous to dealing with a high severity incident.

• 2:46Speaker 00

  And then stage two is where, let's say, you're dealing with some sort of chronic issue that you face, you know, you have sprained ankle, or whatever the, whatever illness that might be affecting you. And it's very hard to plan three months in advance, because that's something that's just affecting you every day, right? And I think that's the analogous thing you do in DevOps, is dealing with streams of alerts, streams of checking whether a deployment was safe or not safe, right? And then stage three is where, you know, I think of it as like life hacking, where you're thinking about, how do I optimize my sleep and my nutrients, so that I have a high-quality life that's, you know, and fulfilling life, right? And I think that's the equivalent of like, planning out what your next five

• 3:28Speaker 00

  years of infrastructure look like, and how you'd invest in the right places. Now, if I think of what, unfortunately, people in the DevOps, SRE, or on-call engineering space live, like, right now, it's like having a heart attack twice a week, and dealing with a debilitating chronic condition that you have to handle every day.

• 3:46Speaker 02

  As I'm listening to you, I'm just trying to picture all the people who I know in DevOps and SRE in scrubs, or wearing CGI monitors to life hack, like, you know, their infrastructure.

• 3:58Speaker 00

  And I think people don't realize it, but when you make this connection to healthcare, you really should realize how, what we've gotten used to and what life really should be like in this world, as we think about the healthcare of large scale software systems. And so I think if traversal does its job right, then that first stage and second stage of needs, which is there's really high severity incidents and that constant pain by death by a thousand cuts, should be something that AI and AI agents take care of. And DevOps necessarily get to deal with the creative fun parts of what is it my infrastructure should look like for the next year, for the next five years, and it becomes a much more fulfilling job.

• 4:33Speaker 02

  And many engineering teams are nowadays adopting autonomous coding, things like Cursor, Winserve. Do you think that's going to have profound impact on how people maintain the reliability of their infrastructure? Or will it be the case that AI will have a major role to play in fulfilling that vision, moving people away from like being the intensive care unit surgeons to being more thoughtful planners?

• 5:03Speaker 00

  So I think it's going to be, there's a short term answer and there's a long term answer. And I think it becomes, in the short term at least, it's a tale of two worlds, I think. So there's this, because of everything happening in the world of Cursor and Winserve and so on and so forth, I think the idea of vibe coding obviously has become very popular, right? And we can write a prompt or a few prompts and have something stood up that people can use and play with. But I think the analogy here is of fast fashion, where you try something on, you like it, you don't like it, you discard it, you know, start the next, wear the next thing, right? And I think in that world, actually, reliability doesn't really matter, because you don't really need to take care of what you've created, there's no craft to it, you created it, you throw it away.

• 5:48Speaker 00

  Right, and I think, but there's another world, which is where you start applying these AI-powered software engineering techniques to mission-critical systems in payments, in financial institutions, in security, infrastructure, streaming. And in that world, I think it's going to lead to a major issue. It probably already is, and it's only going to get worse, in my opinion. Because everyone, we've seen this with the enterprises we work with, everyone is using AI-powered software engineering tools to guide them as they write code. And what you actually find is that it actually even passes their local unit tests. So in that local piece of code, everything looks perfect, right? The problem is that in large-scale enterprises, things break when different pieces of your system interact in a way you just didn't realize,

• 6:32Speaker 00

  or you couldn't foresee. And when that happens, because all of this code is being written by an AI system, it's very hard to debug it, because you just don't have the context anymore. You didn't write it anymore. And I think in that world, unless we find ways of using AI systems to do software maintenance, we're going to be throttled. And either people will disallow AI software engineering tools to be used because there's too much downtime, or something of that form, right? And I think in that world, we're going to need new tools and new software to help maintenance of such systems. And I think that's where Trivose can play a part.

• 7:06Speaker 02

  You definitely have your way with words and analogy, so I love the tale of two worlds. You either have Louis Vuitton, high fashion, or you have fast fashion machine, or something like that. But I think we jumped into the deep end, maybe like a bit too quickly. Let's go back a few steps and maybe explain for our audience, like what actually root cause analysis stand for? Like, what does it do? Tell us a bit more about this wonderful world of troubleshooting and root cause analysis.

• 7:40Speaker 00

  Yeah, so I think, if I just think about the tale of the life cycle of an incident, right, the story of an incident, it always, surprisingly, looks the same across companies. A customer will log on to a platform. Things not working exactly right. Either it's already been recorded or they make a complaint to customer support. Customer support looks at it and says, okay, it's not a user error, it's an actual issue. It escalates in this game of telephone up like five ladders of of different sophistication of engineering organizations within an enterprise. At some point, it hits the DevOps SRE team who look at the issue and decide, is this is this worthy of an incident? Based on the impact of it, based on the severity of it, the immediacy of it? And if they decide it is worthy of an incident, then suddenly chaos ensues, right?

• 8:25Speaker 00

  You'll have a Slack incident channel that's created. There's thirty to fifty people in the channel. Everyone's kind of implicitly blaming each other for what happened. And a bit of a whodunit type thing. And almost without fail, it's the same thing that happens, which is there'll be this ten ex-engineer who's been at the company for-

• 8:43Speaker 02

  Who's the Agatha Christie-

• 8:44Speaker 00

  Yeah, Agatha Christie. Or Sherlock Holmes of the situation. And like, aha, like they'll figure out exactly what happened, right? And not clear how they got there, but they got there. You roll back the the you come up with some sort of hot fix and then everyone kind of it looks for a longer term fix over time, right? And that's typically how it all plays out. And that whole flow is what we call the lifecycle of an incident and root cause analysis in particular, right? And I think what I find incredible is that all of observability, right? There's these incredible companies that have been created. They're the second largest software spend typically companies have after your cloud

• 9:26Speaker 00

  spend, and yet we still at this state of root cause analysis. But anyways, that's my take on what RCA looks like nowadays.

• 9:33Speaker 02

  And tell us maybe like a bit more color on where does root cause analysis live with relations to the plethora of observability tools that companies use today? Why is it that if it's still the case, if this is the number two spend in technology, why is it that you have, you know, fifty people like in a Slack channel with a whodunit kind of plot?

• 9:58Speaker 00

  It speaks to the the importance of the problem, right? And what observability has done is the best they could have done, given the technology that was available to even like six months ago, right? Which is, so I think what observability is, it's fundamentally about the creation of telemetry data. It's called MELT data, so like metrics and events and logs and traces. So MELT for short. And it's about the creation of this data, storing it, and then providing a nice visualization layer on top of it. So people can create the right slices to create little eyeballs in different parts of their system. And I think that's what observability ends at, which is a storage and visualization layer. Because that's all that could have been done. And the complex workflow of troubleshooting remains super manual.

• 10:40Speaker 00

  And that's just because that's all we could have done so far. And I think the promise of what these AI agent companies can do is that they automate complex workflows that we do on top of software. And to me, this problem of troubleshooting with cause analysis is one of the most complex workflows that any study humans do on software. I think now there's an opportunity to kind of move up in terms of sophistication where we use AI systems to actually automate this workflow versus just stopping at the storage and visualization layer.

• 11:11Speaker 01

  Can you talk about your product? What is the agent or the agents that you're building to kind of take on this problem? And how does it work?

• 11:17Speaker 03

  Yeah.

• 11:18Speaker 00

  And are they double agents?

• 11:21Speaker 03

  So maybe stepping back, what is an agent? And it's really an LLM orchestration of tools. And in our world, those tools might be data fetching tools, how to get logs, how to get metrics back, data processing, how to format it in a way that the agent can really process, or statistical tools like running anomaly detection. And I think really what we're trying to look for here is you need to define the tools rich enough so that an RCA can be expressed as some combination or some sequence of these tool calls. And that's really where a lot of the complexities and the multi-agents come in, is how do you piece together these tools to solve these complex tasks?

• 12:04Speaker 03

  And I think, at least in our world, the data is so big that it needs to be sequential because a single trace might not even fit in LLM context. So you need to know how to slowly just build this context of the LLM to get to the root cause. And that's why it's really challenging of a problem.

• 12:23Speaker 01

  Are you mirroring the cognitive architecture of a human troubleshooter? Is it, you know, is the map of operations very similar to what a human would be doing? Or is it very different for an agent?

• 12:33Speaker 03

  Yeah, I think that's where, at least when we were first thinking of the problem, we tried to mimic how an SRE would debug. And it was very manual, very sequential, where an SRE typically might look at a piece of evidence and then, okay, figure out what's the next piece of evidence to look. But a lot of times, they make these hops with system knowledge, which the agent might not know. And that's really where we used a lot more scale to figure out how to bypass some of this issue of system knowledge. So this agent will basically look in a more systematic fashion of, there's this Google SRE handbook, which tells you, here's the key golden signals, you should be looking at latency, error rate.

• 13:17Speaker 03

  So it looks at this way of kind of health monitoring to piece together how to sequentially search this rich space. And it's less about having holes in the reasoning where a human can just immediately get maybe to that hop. The agent is making these sequential flows that get to the answer.

• 13:38Speaker 02

  Are there particular conditions or environments where this agentic approach works better or worse?

• 13:45Speaker 00

  Yeah, I think fundamentally, it's about data access. So what we have found, and surprisingly, that's what we have found, is that we sometimes can add less value in like a series A startup versus a large enterprise. Because when you become a large enterprise, your observability is quite mature. So everything is being instrumented in a way where the fundamental data is in place, but your teams are very fragmented. So no one team or no one person has enough context to piece together whatever, everything about how to debug, right? And that's why you have these 30 or 50 people in a Slack incident room. And so what we fundamentally found is that the place where we add the most value is when

• 14:26Speaker 00

  the reasoning steps for this agent to go from a high-level trigger to the root cause, those steps can be found in the data, right? It's just, it's too much data for any one human to keep in their head. When that data is fundamentally not there, then it's when the agent suffers. And that tends to not be the case of the enterprise, is what we've found.

• 14:45Speaker 02

  Very interesting and really like somewhat counterintuitive, because it's usually the case with startups that the way you choose your design partners or customers, you start at smaller companies or mid-market and then you try to graduate your way up to enterprise.

• 15:02Speaker 02

  And if we're going to use like the L one to L five, like analogy from self-driving cars, how close are you with having agents correctly get to the root cause of incidents? Or maybe more broadly, like what what counts as success? Like, are we trying to get to 100% correct resolution? Or what even counts as as correct resolution like in this context?

• 15:31Speaker 03

  Yeah, that's a great question. So I think there's really two cases here. There's the first case where the root cause fundamentally belongs in the data. So it's in some log, it's in some PR. And in that case, I would say with traversal, we're at L four. And I won't say L five, because for us, we might be able to flag that problematic PR or that smoking gun log. But then there's still that last mile of the fix and the remediation. And in cases where the fix is not so localized to a specific file or code change, where you need to do basically a bigger system-wide change, that's we haven't gotten there. But I think that's where it's really exciting to see all the developments with code agents, because that's where we can get to that L five.

• 16:17Speaker 03

  I think for places where the root cause isn't in the data, that's where we're more at an L two. I think traversal finds a lot of the important symptoms that really help people debug. But sometimes it's just not in that data. And this human kind of needs to make those additional hops to get to the actual root cause. But still, the symptoms really help figure out how to make those additional hops. And sometimes, right for us, when we notice that, we can tell customers, well, maybe you should instrument in this way to make the system more observable.

• 16:51Speaker 01

  Across the AI landscape right now, there's really interesting kind of AI-native companies being formed like yourselves. There's also the incumbents that are, you know, in many cases, not asleep at the at the wheel. How do you think about the incumbent risk here and and why your customers are choosing to go with you?

• 17:07Speaker 00

  Yeah, I think it's a great question. I think the heart of it is observability is expensive, right? It's such an expensive product that people pay for. As a result, it's extremely fragmented, right? You go to any big enterprise, they're using Datadog, they're using Splunk, they're using Dynatrace, they're using Elastic, they're using Grafana, they're using ServiceNow. I mean, they're using everything, right? And all of them are like encroaching in this game of attrition, right? And the problem is that if you just think about the pricing models in this world, it's all based on the amount of data that's stored, right? And so as a result, Company A is not incentivized to give you better insights from anything that's stored in Company B, right? And to debug something, if you just look at any of the SRA or on-call engineers, they're calling upon all five, six tools they have access to.

• 17:52Speaker 00

  And it's that fragmentation of this historical industry, I think, which is going to ideally lead to companies such as ourselves that are somewhat agnostic to where the data is stored, at least for now, it gives us a chance.

• 18:04Speaker 01

  Do you have customers deployed on traversal today? And what have you found is the difference between what you kind of expected, even coming from an academic background versus what you're actually finding in real-world environments?

• 18:14Speaker 00

  Yeah, it's been, it's been quite a journey. I think when we started, as one should typically do, we started with like very small companies and, and built something that worked for them. And that typically took the form of we went through the last hundred incidents that they had, right, in their Slack channels and kind of try to use our brains to figure out what is the meta workflow of how they always debug an incident in that particular company, right? And in that situation, a very popular framework for agents is something called the React framework, right? And that, as a general idea, worked. We could somehow imbue the meta workflow into a React agent system, and it was able to do a really, a really good job. And then at some point, we started, you know, working towards larger companies

• 18:58Speaker 00

  that had an actual, like large-scale observability system, thousands of microservices, that kind of situation. And I think, I remember very clearly this one week where it was the first time we dealt with that kind of scale. And

• 19:13Speaker 00

  The second we tried to apply our system on just some historical incident that happened, our accuracy was at zero percent and we just, it would not move. Whatever we did to the prompts, whatever we did to anything, it was stubbornly at zero percent. And that was a rude awakening. I remember Raj and I had a negroni.

• 19:36Speaker 00

  And I think at that point, we kind of had to think through ways of, we made some interesting decisions which played out in our favor, which is we said, okay, nothing about a specific company will be hardcoded into the prompts, right? And nothing about a workflow that humans do there will be hardcoded into the agentic like workflow. And that complexity has to go somewhere, right? And eventually where it went to is computation, which in the form, in our world, takes the form of spending tokens in the problem, like using it at inference time. And once we were able to kind of find an architecture that exploited inference time compute, which is something now everyone is finding to be important, accuracy starts shooting up.

• 20:21Speaker 00

  And what we found then is for, if the fundamental answer lies in the data, we get to the answer more than ninety percent of the time and we get in within two to four minutes, right? And which is amazing because now you just look at these Slack channels, humans are spending most of their time just verifying the answer to what we find versus actually root causing it. And just the time, the month to month time resolution has dropped, I'd say, as is the number of people on average in the Slack channel, which is two things that I think any enterprise cares about.

• 20:48Speaker 02

  And how do you measure accuracy like in this context? Like, for example, there are a lot of companies that focus on L L M evals, like, does such a thing exist in the world of like S R E and root cause analysis? Or like, you know, how do you, how do you know that you're correctly identifying a root cause?

• 21:06Speaker 03

  The gold standards, honestly. Trying it on live incidents. I think when you onboard to a customer, oftentimes incidents can happen like two to three times a week. And in those scenarios, you get the best feedback. Maybe it takes a couple of hours for that incident to complete. You look at the postmortem and you can really evaluate it. So I think that's one definitive source. There's other subtasks we do for evaluation, such as when people are trying to search for specific information from their observability. There's smaller chunks of tasks you need to do to do RCA. So we evaluate on those tasks as well, which are just higher volume. But ultimately, real live incidents are the best way for us to evaluate.

• 21:50Speaker 02

  Awesome. It sounds like you had this root awakening at some point where you deployed the product and it was stacked at 0% accuracy before you went back to the drawing board and really refought like the entire architecture. So maybe, can you give us a very quick tour under the covers of how the product works today? And what is the magic that enables precise root cause analysis?

• 22:15Speaker 03

  Well, one important decision we made was we only require read-only access to the data. And I think that was a decision basically based on enterprises not wanting to just have yet another tool to generate more data. So how do we actually do it? Well, I think there's two phases. There's an offline phase and an online phase. So during this offline phase, we're really trying to learn this rich dependency map. How do different functions, how do different logs relate to each other? And one way to do that is through LLMs. So LLMs go traverse, really understand semantically how these logs, different tags within the logs all relate to each other. And then we also use statistics.

• 22:58Speaker 03

  And statistics comes in when, for example, there's natural variation in time series. And that turns out to leave traces of causality, which basically Aneesh and I worked on in grad school of how do you pull causal relationships out of this data? And that's really key to build this rich map. We also use self-play to basically prioritize certain paths that are very promising for RCA.

• 23:24Speaker 03

  So now, once we've constructed this rich dependency map during the online phase, when an actual incident comes to us, what this agent is doing is it's using that realtime information and this dependency map to basically figure out what hops to make to do the root cause analysis.

• 23:42Speaker 02

  How long does it take for the offline part to become effective, such that, in other words, between deploying your solution and the first incident that you can actually troubleshoot, how long is that gestation period?

• 23:55Speaker 03

  It kind of depends on if they want to troubleshoot a live incident or a historical incident. In general, I would say we take about five to 10 hours to kind of look through all of their codebase, look through their observability, really have that system understanding. For larger customers, it can take a day, but generally, five to 10 hours.

• 24:20Speaker 01

  So you've mentioned reasoning and inference time compute a couple of times in there. Are you using kind of foundation models and, you know, fine tuning them for your purposes? Are you building a lot of that kind of architecture yourself? Maybe just talk a little bit about, you know, the architectural decisions you've made?

• 24:36Speaker 00

  Yeah, one really interesting thing we have learned is that if you work with enterprises, they typically have a existing relationship with a LLM provider. So they might have an enterprise contract with OpenAI, Anthropic. And if you try to bring your own model or your own fine-tuned model to them, you're going to be stuck in security hell for about a year. And so you have to kind of tie our hands where you say you have to be able to use whichever model they give you. Typically, OpenAI is a pretty safe bet, Anthropic as well. And so then most of the complexity is really about how do you get the right set of tools that this LLM has access to orchestrate the RCA itself. And the other thing you can

• 25:19Speaker 00

  do is fine tune within a company's environment. So, you know, let's say they point to their Azure OpenAI instance, then you can fine tune that by every time an incident happens, you see how far you got, you saw whatever the pinned root cause was, you can see how far away you were. And then the system can fine tune on making sure that gaps get small and small over time. Right? So that's generally how we've seen it's played out.

• 25:42Speaker 02

  And you also mentioned that you guys had, part of the architecture here is based on years of your academic research. Can you share a bit more about? Kind of this interplay between your PhD dissertations and translating that now into a company?

• 25:59Speaker 03

  Yeah, actually, so one thing that's kind of interesting is, at least during grad school, I worked closely with the Broad Institute to basically understand what these CRISPR interventions, you have these gene regulatory networks, you do a CRISPR intervention, and you're trying to understand what is the effect of this drug or this knockout experiment on how these genes express. And the techniques we developed there for learning that causal structure between genes turns out to be pretty related to this problem we're facing with production systems, where if you think of the nodes of swapping them with genes as microservices,

• 26:40Speaker 03

  and then you're learning, okay, what happens when I make a PR change, or I break this part of the system? How does that percolate? It becomes almost the identical problem. And I think that was, honestly, by sheer luck, we didn't know that was going to be the case. And only until we got into the weeds of the problem did we realize like, oh, wow, we got really lucky that our grad school research played out well here.

• 27:05Speaker 02

  Would have been some other surprises on this journey over the past year, year and a half?

• 27:13Speaker 00

  Well, for one, I think, which is part of why it's been such a joyous thing for us, is just how it's like the industrial age of AI. And so I think all of the most interesting innovation, I feel, is happening in small, research-focused startups, such as the ones that we are part of, or have the privilege to be a part of. And so I think just having seen the best of research in some of the best universities, and now actually seeing how it gets played out in a company, it just feels like this is where all the magical, special work is happening. And it's just, I think that was surprising to me, coming from a world of academia, becoming a professor. I thought that's where all the innovation will be. And so that's been quite surprising. Honestly, I think the other thing that's been quite surprising is just how hungry enterprises are for

• 27:58Speaker 00

  using generative AI to solve real problems. And you can show that the pace at which you can move with them, what typically would take a year or two years to close, can, you know, be rapidly done in a couple of months. And so I think the hunger of the market and also the pace of innovation in the industry has been, I think, quite surprising.

• 28:14Speaker 02

  Speaking of the pace of innovation,

• 28:17Speaker 02

  Things are moving like, you know, so quickly and you have been working on this product for slightly more than a year now. Have you been in situations where you have to go back and rework something? Oh, because now there's MCP or something new on the market that previously you had to engineer yourself, but now it's readily available, like off the shelf, so to speak. Or, or in some ways, like, how do you future-proof like your architecture and, and, and what you're working on?

• 28:45Speaker 00

  Honestly, I think that is going to be a constant challenge for companies of this generation. If you're in product, if you're in design, if you're in core engineering, you constantly have to make bets as to where AI is going to be six months from now. And then you're willing to reevaluate everything six months from now. And the good news is that it's only going to get better. So it's not like your product's going to get worse six months from now, right? And so, for example, one really interesting thing, bet that has paid off is, you know, Raj and Raz were very prescient about the fact that reasoning models are going to get better, right? They'd made this bet in September, right? Just seeing where the world was going. And we architected our system such that the reasoning models would get to shine.

• 29:28Speaker 00

  And that has really paid our dividends right now in the way our entire architecture is set up. And so I think you have to keep making these kinds of six-month bets about where AI is going to be and surf it just right. And I think the companies are able to string together a few of these bets just right. Other ones are going to win. I think that's why, in my opinion, if you asked me, would you rather be in AI team taking this problem or an observability team? I'm biased, but I'd say I'd rather be in an AI team because you just have to, you get more fluent at making these kinds of bets about where things are going.

• 30:01Speaker 01

  What is your team composition? Like, how many are researchers? How many come from the domain? Like, I'm curious how this, what the shape of an AI-native agent company will look like more broadly.

• 30:11Speaker 03

  Yeah, I mean, right now, I would say. We're ninety percent engineers. I mean, a lot of people, you know, there's a few of us with PhDs who have done PhDs in machine learning. A large fraction come from like traditional software engineering backgrounds who have been very interested in Gen AI and have used it in their own life. But I think for some of these things, at least the barrier, right, is lower and you can kind of get, everyone's trying to learn how to make an agent. And I think it's not like the old days where you might have needed a PhD to, you know, write out these gradient updates on this crazy LLM. I think it's a lot more democratized and that reflects in the way we've made the team

• 30:56Speaker 03

  composition. We also have people working with infrastructure. So how do we scale these agents? And I think that's a really interesting problem of, to Aneesh's point of inference time compute, is how do you really get this AI agent to just do a lot more work than a human can possibly do? And that involves, for us, we make thousands of network calls per investigation. So that's reflected in hiring the best infrastructure engineers. And then I think the other part is we have product managers and some of those folks are coming in the next month. So we're really excited just to bring all of these different peoples with different backgrounds together to solve this hard problem.

• 31:40Speaker 00

  Yeah, I think one thing that unifies everyone in the company is an excitement for generative AI. And I think because of that, they're willing to learn and adapt and throw away things that didn't work, versus kind of being stuck in your way. Because I think those are the people that are not, that's the type of culture that is not going to survive in this world, because it's just moving too quickly. And if I think about what, it's interesting, I think about an AI researcher versus an AI engineer versus an engineer, like, how do I organize that? I think it has nothing to do with whether you have a PhD or any sort of credential. It's about how experimental are you in the way you think? Like, how willing are you to make little bets and hypotheses about how things can be?

• 32:22Speaker 00

  And then quickly, you know, put that to the test, right? I think that mentality of quick iteration with AI and data is, I think, what makes someone a good AI researcher or an AI engineer. And so it's more a mindset than a credential.

• 32:37Speaker 02

  Speaking of the composition of your team, I find it very interesting that neither one of the two of you or your two other co-founders are actually observability industry insiders. And your entire company is very heavy on AI and engineering prowess and honestly, like, you know, quite short on observability, like, you know, domain knowledge. And yet, you are making waves, like, you know, in this domain and successfully resolving these very complex issues that otherwise take little armies of people scurrying around and dumpster diving to go figure out, like, what is the smoking gun log?

• 33:16Speaker 02

  It almost begs the question of, what do you think the future observability or SRE team at one of your customers might look like? Today, you mentioned that there are people who have all the insider knowledge, like all the tribal knowledge, the intuition, they can make these hoops, you know, from here to there without data. Is that still a valuable skill set, like, you know, five, 10 years from now? Or would the observability team look very, very different?

• 33:49Speaker 00

  A couple of answers. One is, I think there will be a lot of work to be done about the reliability of AI systems themselves. And I think the way you reason about reliability of AI systems will require, obviously, first principle, good SRE principles, but also some sort of fluency with AI as well, because they'll break in interesting, unique ways that we're just not used to. And so I think I think modern SRE teams will have to kind of be fluent in both in some ways, which is how do LLMs and AI systems break and also how regular systems break? And marrying those two things will what I think will make you really good DevOps and SRE engineer. And also even simple things like, I think one really interesting thing that's going to happen

• 34:32Speaker 00

  is that the data layer of observability is going to fundamentally change as well. Like the way a log looks like is going to look fundamentally different. And a part of being a good SRE or DevOps person is knowing how to write a good log, right? So that over time, when incident happens, you have the right instrumentation. There's an art to instrumenting your system the right way, where you're not flooding it with too many logs, but just the right amount, right? And I think the way we will write logs will look fundamentally different as well, because it's no longer meant to be scrolled by a human, but meant to be consumed by an AI system.

• 35:03Speaker 02

  That's a very interesting point. Like, how do you rate Cursor today on their ability to write good logs?

• 35:09Speaker 03

  I think it does a pretty good job, but I mean, I think it's

• 35:12Speaker 02

  Better than a human?

• 35:13Speaker 03

  I think the way it can format, like, humans just make typos and they don't, I mean, I make typos. I'm really bad at spelling. Like, I think Cursor does a great job there, but I think a lot of it is still mimicking how traditional logging looks. And I think to Aneesh's point, you need less of that and you really, for example, want to bury as much information in the message field, because that's the meat of what is going on. And now when the LLM sees that, it can kind of have a better understanding of how to make those hops. But a lot of times, people don't like to add so much content, because a human can't read such a long error stack trace in a log.

• 35:50Speaker 01

  We have shorter context windows than these LLMs.

• 35:54Speaker 00

  And I think also then connecting with the business logic, right? A lot of times, because typically, it may not be, your engineering system is fine, but well, it depends on what fine even means for an engineering system. It has to connect to some sort of business logic for it to be healthy or unhealthy. And I think logging in a way that it that connects these two things in the right way is is an art still. And I think that will be tough for Cursor or any other AI system to do, unless they have full understanding of your business logic, which might happen, I don't know.

• 36:21Speaker 01

  As you dream about the future of the software engineering market and the role that observability and traversal will play in that future. You know, you started this podcast episode talking about, you know, people aren't vibes coding a, you know, payment system or banking system today. Do you think that, you know, if everything that Traversal's building goes right, if observability changes in the way you think it might, that, you know, engineers at the largest banks and payments companies and healthcare institutions will be actually vibes coding their software programs?

• 36:52Speaker 00

  To some extent, yes. And I think what we will have is just a much better sense of, like, did it fulfill some function? And that will typically take the form of unit test in some form, right? And just much better testing. And so as long as it fulfills some test, that code is fine. And who cares what was written in that code? I think that was somehow, in my opinion, is how software engineering is going to evolve, which will be much more about, did it fulfill some function versus the way it was written? Which will be good, but as we talked about earlier, I think also bad. Because when systems fail, it's because they interact in ways you didn't expect, right? A lot of times, you are failing because a third party that you call upon is not in the SLA, right? And that's just going to happen a lot more, I think.

• 37:35Speaker 00

  And it's going to be a lot harder to debug because you don't actually know what was the content of a particular code file. And so I think that's the problem that we're going to face. And that's why I think products like Traversal will have a big part to play in solving those kinds of issues, which is a lot more subtle.

• 37:52Speaker 03

  Because I think that's where humans shine, right? Is right now, humans mostly write all of their code. So they have that rich system knowledge. So when they see an incident, they can short circuit a lot of paths because they already kind of have seen something in the past or they kind of already understand this error message they wrote. But if an AI generated that, they don't have that structural advantage. And then you really need a AI troubleshooter.

• 38:18Speaker 01

  Okay, we're going to close it out with some rapid fire questions. You guys ready?

• 38:21Speaker 00

  Yeah.

• 38:22Speaker 01

  One sentence or one word answers. Maybe first, what application category do you think will break out for AI in the next 12 months?

• 38:30Speaker 00

  I'm going to try to say this in two sentences.

• 38:33Speaker 00

  Which is, I think, anywhere where you're using reasoning models better are where applications are going to shine. And I think diagnostics is one of them, healthcare being, I think, a prime example of that.

• 38:44Speaker 02

  Another startup or founder that you admire?

• 38:46Speaker 03

  I would say Demis Hassabis. Hopefully, I didn't butcher the name. But I think just an amazing researcher, so much foundational work, and just always trying to solve the hardest problems.

• 38:58Speaker 02

  Recommended pieces of content, how to make yourself smart on AI?

• 39:03Speaker 00

  My favorite article, which you can read in five minutes, is The Better Lesson by Rich Sutton, who won the Nobel Prize last year for his work on reinforcement learning.

• 39:15Speaker 01

  Any other AI agent companies that you admire? You're one of this very first cohort of truly agent-native companies. Any others?

• 39:22Speaker 00

  Aside from the obvious, like, Glean and, I mean, I would say Perplexity is one for sure that I think is just doing a fantastic job.

• 39:32Speaker 02

  Favorite new AI applications that you're using in your personal life?

• 39:35Speaker 00

  I honestly don't use anything other than ChatGPT.

• 39:38Speaker 03

  Unfortunately, the same for me. It's already, it's my best friend at this point.

• 39:43Speaker 01

  Wow, I love it. Maybe one last question. Will we be vibes coding, banking apps, payment systems, healthcare systems in five years' time?

• 39:53Speaker 00

  To some extent, yes.

• 39:54Speaker 01

  Wonderful. Thank you so much for joining us today. We really love this conversation. And congratulations on what you've built so far at Traversal.

• 40:00Speaker 00

  Thank you.

• 40:00Speaker 03

  Thanks so much.