Markdown source

Transcript: Why Self-Driving Production Is the Future — Eric Schwartz, Traversal | AI Engineer World's Fair 2026

Source Video

Local Cache

Transcript

Hey everybody, we are back here at the AI Engineer World Fair 2026 in San Francisco and I'm thrilled to have Eric here from Traversal. >> Hey everybody, nice to meet you. >> All right, so Eric, uh to get started, tell us a little bit about you, the company, and what you guys do today. >> Yeah, so I'm a product manager at Traversal. Joined the company a little over a year ago. Uh we're building an AI site reliability engineer. So we're a series A company around 100 employees backed by Sequoia Kla and a bunch of others and we work with some of the largest companies in the world, Fortune 500, Fortune 100 enterprises to help their on call engineering teams. >> Awesome. Um my guess is this is a agentic system. It's you know it's a it's uses AI in that way. Talk a little bit about that like what the workflow is kind of and maybe how SR has changed over the last year or two. >> Yeah, for sure. So I guess like high level just taking a step back like everyone's using coding agents like to write more code. Our thesis is like if AI is writing your code it should be fixing it also like troubleshooting is still very manual requires a lot of toil and burden and so we're building AI agents to help SRRES with that part of the workflow. Um and so we first started with incident root cause analysis. So like SE 1, SE 2 incidents, um helping engineers get a very detailed root cause for those to reduce resolution time. We've expanded to other use cases like triaging high volumes of alerts, uh support channels, things like that. Uh and the product works in the web, it works in Slack, it works in your terminal or code editor just like other agents. But yeah. >> Cool. Awesome. Um what goes into making this actually work? you know, the models have gotten better and better, but feels like the models just by themselves can't necessarily solve the problems. >> Yeah, for sure. Um, this is something we get a lot like a lot of people, I think, gravitate towards these use cases for like a build-it-yourself type solution. A lot of people think they can just hook up like Claude to a data dog MCP and get an AIS surre. Um, there's a bunch that goes into it. Number one, like we've invested a lot in the integrations and data platform. So like we work with some of the biggest companies in the world that are emitting like billions of logs a day, pabytes of data. So actually having a very deep integration in a platform for analyzing, compressing, indexing that data uh continuously so that the agent doesn't need to do all these live queries at runtime is very important and something that sets us apart I think. And then in general the entire harness. So like once you have all this data, it's indexed like giving the agent the right set of tools, the right prompts, the overall harness to make sure that it's a really great experience for these SR use cases is a is a lot of work. >> How much of this is shared across companies like the same thing >> versus being unique in each organization? I'm I'm kind of curious if you have one of these uh the forward deployed engineer models where you go in and you you do a lot of work to tune it to their workflows or can you just plop in the robot surf to any company and it works? >> Yeah. Yeah. So, I mean it's it's evolved over time like uh obviously when you start you do things that don't scale. Uh over time we've standardized a lot. So I'll say where we are right now. Generally within a week of uh like a proof of value or an engagement starting it's up and running and in production. So very minimal tuning. Um that's because we've invested a lot in this like data platform. So the agent does a lot of the work on its own and the system does a lot of the work to index. Um there is always some last mile optimization. So we do have a forward deployed engineering team but as much as possible we're trying to reduce the burden. Um when I joined traversal like the initial deployment times were much much longer than than where we are right now. Can >> you talk a bit about cost? I know like cost has become a big thing. We're maybe ending the token maxing era, you know, into something else. And um a lot of people online have been talking about switching different models, fusion architectures of models, >> um you know, model routing depending on query. Um I'm I'm guessing you don't necessarily expose the model, you're exposing the agent that's doing the work. But how do you how do you think about that like as a as a company? And then maybe the end customers, what are they all using state-of-the-art, you know, frontier models? Are they are they using open models? What? >> Yeah. So that's a great question. There's a couple ways we think about it. Like one is for internal development and then also what we expose to the customer. So I'll start with the internal stuff. Like internally we're always evaling different models. Uh whether we should be going with the latest frontier model from anthropic or open AI uh or open source models and we we pick and choose the best models for the different tasks. So like some of our sub aents for example that are much more scoped can use maybe a lighter weight open source model uh the initial orchestrator might use the latest frontier model from one of the closed source labs. Uh and that's like an ongoing process uh that that we're always running. Um I'd say also we put a lot of thought into like tokens and cost for certain use cases. So for example um alerts is a use case that I've spent a lot of time on. We have a product we call alert intelligence. Basically like you can plop traversal into an alert channel. You might be getting like a thousand alerts a day and we'll triage and prioritize all those alerts. That's like one end of the spectrum. The other is like a sev one incident. Like the way you handle those should be very different. We're not going to do a really deep expensive investigation a thousand times in a day. Like it's kind of ridiculous. So we think a lot about giving the agent different tools and models so that it can reuse its work or maybe do lighter work for lower severity things. Um but it's not totally solved. Like I think there's a lot a lot of work we can do. I think companies like cognition and factory some of the coding agents that are not anthropic and open AI seem to be doing a lot of really cool stuff that that I'm definitely noticing and want to take inspiration from. seems like there's a kind of this blurry line between what you might use an SR agent for for doing um you know detective detection of issues or outages or bugs versus what you might use a coding agent for like we we've actually found that our we built an internal coding agent system called called we call it horizon and we've actually found that it's kind of similar to Devon and ramp inspect and all these things we actually found it's really good at debugging >> um we often use it to triage issues and kind of do sur like workflows do these converge over time I what or are they distinct you know agents because they have different workflows and different outcomes. >> So I think that I think it really depends on the use case and who you are. So like and this is this is I think a big reason why most of our customers are some of the biggest companies in the world. I think these coding agents are are great, but when you're ingesting like pabytes of data in a day or like 200 billion logs across 500 log indexes in open search, like I I I might be biased. I just think that unless you're really really focused on S sur and building the data platform to support that scale, it's going to be a challenge. But if you're like a if you have like a monor repo and all your logs are in a single index and maybe you're not such a big company, I think there is going to be some overlap and it's part of the reason why we're focused on like the big companies that really that have like a thousands of people on their engineering team. It's like very hard to get cursor or cognition or whoever to to get this to work at least from what we've seen. >> Um tell me a little bit more about the post analysis step. So if an S sur is doing, you know, an investigation and then it comes up with a resolution that it it wants to perform an action, do you let the the agent do that? You know, if it said, "Hey, uh, the database is slow because this new feature is launched. It's missing an index. >> I'm just going to go add the index." Um, I'm curious about giving the agents permissions or capabilities to go do stuff. >> Um, what that looks like and how how these companies are thinking about it because it does feel like the holy grail is what I've heard. It's kind of the tight loop self the self-driving infrastructure, you know, the idea of that. Um, how do you approach that today? What what do you think about that? >> Yeah, for sure. It's a great question. I actually gave a talk yesterday called self-driving production. >> Oh my god, I have no idea. Okay. Wow. Okay. >> So, uh, the short answer is like we we have that capability. It really depends on how comfortable the customer is. So, like internally, traversal has been like a closed loop system for most of this year. uh it'll diagnose the issue like put up the fix, check its PR and everything. It just needs a human review. Uh but but it happens without asking for permission. Um a lot of customers when we start like it's there there's like a tr a level of trust you have to build and so to start like when we start with a customer we we might not let traversal we might not enable any of those tools. So traversal won't even put up a PR. The next step would be um it will ask a user for permission then it'll put up the PR then the human will review and then as customers get more comfortable we can go to more towards that self-driving piece. Um another great example is alerts again like a lot of our customers really like it when traversal can just be constantly putting up PRs to tune or modify alerting rules and code to reduce volume and noise uh in their channels. Uh, and that's like a great example of something that you don't want traversal to be asking for permission because people are hardly looking at these channels in the first place. Um, so yeah, it's just it's kind of like a journey we go on with our customers. >> Similar around that security stuff, uh, can you talk quickly about these customers, the big ones, you know, Fortune 10. Um, how they actually use and deploy this. Are they running it in their own cloud on prem? Are they are you deploying to a VPC? What's the kind of current state-of-the-art of how these companies want to use AI services? >> Yeah, so we have two deployment models. We had a third, but now now we're focused on two. When I started, we did have some on-prem deployments. That was like what we needed to do to get our foot in the door. >> And that meant describe what onrem is >> like I was a onboarded contractor with a company issued laptop at some of our customers. We're fully deployed like on their servers like like air gap. no data is leaving their environment. It was a lot of work and we had a few of these which made it very hard like different deployments every single time. Now we're we're at a maturity and stage where we just have two models. One is just normal SAS. The second is bring your own cloud. So we'll deploy into a customer's VPC. Um and so it's not as much of a burden as the on-prem option, but still gives customers the peace of mind that they >> Do you do multicloud or were you able to just kind of pick? >> Right now it's just AWS. >> Okay. Yeah. Yeah. Yeah, >> I think a lot of people are thinking about this and trying to figure out what to do to serve these customers. That's >> Yeah, from what we've seen like the like the the enterprises we work with, um the bring your own cloud for AWS has been enough for now. I'm sure at some point we'll have to cross that bridge, but that in and of itself is is a lot of work. So, >> yeah. Yeah. Awesome. Well, Eric, thanks so much for coming by. It's great to chat with you, learn a lot more about this company and product. Um how I guess last question, how can people try it or sign up? uh go to traversal uh and then on there you'll find some contact information. Reach out to us. Our team can get in touch, give you a demo and and see if it's a good fit. >> Great. Thanks. Cool.