Traversal

Meet David. Before Traversal, David worked on OS engineering at Oracle and as an SRE on Google PubSub, then founded a startup of his own. That experience confirmed for him that he leans more engineering than sales, but taught him a lot about listening to customers and building around what they actually need. We live in a world of massive datasets, with more AI compute available to make sense of them than ever before. What excites David about Traversal is the architecture we’ve built to take that potential further. As he puts it: “We've got the right architecture, the right mix of research and development, the right business problems, the right connections, and the right team to execute.” David’s work sits directly at that intersection. He helped design and build our deployment systems, bringing BYOC deployment times down dramatically – from roughly two months to, soon, just two days. And beyond deployments, he’s working to make it even easier for our engineering team to turn what we learn from customers into projects that land smoothly in their environments. He also gets to see that work pay off. Big customer wins are a chance for the whole team to see what we’ve built working in the real world – and something everyone celebrates together. Whether it’s debating ideas, playing board games for 15 minutes each day, or watching Raj sweep everyone at poker during an offsite, David says he’s surrounded by people he wants to work with every day. Come be one of them! Open roles in the comments.

For the last 20 years, observability has been built around one assumption: A human is looking at the dashboard. What changes when the primary consumer becomes AI? In this clip, Traversal CEO & Cofounder Anish Agarwal explains what needs to change – shifting the observability stack from optimizing for visual dashboards to enabling AI to process, index, and query massive amounts of data in parallel. Check out the full episode of Inside the Silicon Mind, where host Firas Sozan and Anish discuss: – Why the 50-person incident war room shouldn’t exist anymore – Why petabytes of production data make incident response fundamentally a search problem – Why some of the most interesting AI research now happens in production Link in the comments.

One user at a Fortune 100 customer found a new use case for Traversal. It can save them $1M+ a year. They used Traversal to hunt down redundant production logging. After the recommended changes were shipped, log volume dropped 84%. Along the way, Traversal uncovered a live security exposure nobody was looking for. See how it unfolded below 👇

For many enterprise engineering teams, Microsoft Teams is the command center for incident response. The investigation shouldn't have to leave that conversation. Traversal is built to meet engineers where they already work. Whether that's Slack or Microsoft Teams, the experience is the same: – Start an investigation with an @Traversal mention, or let Traversal Workers investigate automatically – Get evidence-backed findings in a dedicated thread – Receive a draft postmortem when the incident is over Same AI SRE. Same Production World Model™. Now, right inside Microsoft Teams. Read more in the comments.

We built Traversal to solve one of the hardest reasoning problems in software: incident root cause analysis. The product quickly proved valuable well beyond that original use case. Today, more than half of Traversal usage comes from workflows we never explicitly built for, from infra resource management and release validation to CMDB validation and cost optimization. Once you can reason accurately about a production system, incident troubleshooting becomes just one application.

One of these could have your name on it. And many more where that came from: traversal.com/careers

A customer's service started silently failing. Requests would hang for minutes, then fail without ever creating a session. An engineer opened a Traversal investigation. Traversal traced the issue to an unapplied database migration when a recent deployment left the application expecting database columns that didn't exist in production. Within minutes, it had reconstructed the chain of events, identified the deployment responsible, and shared a complete investigation with supporting evidence, all within Slack. An on-call engineer shared Traversal's investigation in a broader Slack channel. The engineer whose deployment had caused the issue replied, "damn, that's right 🔥."

How ready are today's frontier coding agents for on-call? Traversal's AI Research team, in collaboration with Columbia University and Cornell Tech, built ORCA-bench, a new benchmark for evaluating AI agents on production root cause analysis. Public on arXiv now. Existing benchmarks hand agents static datasets with clean, well-defined context – missing what actually makes on-call hard: vague user reports, noisy telemetry, and real observability APIs. Their ground truth and evaluation methodology make it difficult to determine whether a model truly solved the underlying problem. ORCA-bench instead spins up a live, production-like environment where agents investigate incidents through the same observability interfaces they'd use in practice: 1,079 production-fidelity tasks, expert-SRE-validated ground truth, independently validated evaluation. It measures production reasoning, not pattern matching. We evaluated five frontier agents. Four findings: -- Even in a simple environment (public source and instrumentation, isolated incidents, 7GB/day of telemetry across 4 standard tools), the best model hit just 25.3% accuracy on medium-difficulty tasks. -- Vague prompts make it worse. If you go from a precise symptom to "users are reporting site issues," accuracy drops across the board – 10% on hard tasks for the best model. -- Code access helps. Strip it out and the best model falls from 25.3% to 19.3% on medium tasks. -- Hallucination is a real risk. The weakest model proposed a flat-out wrong root cause in 40.2% of incidents – and in incident response, confident but wrong can be worse than no answer at all. Bottom line: models are improving, open-source included, but that's not enough. Production RCA needs purpose-built data architecture, reasoning systems, and evaluation, which has been our focus at Traversal from the beginning. Stay tuned for more benchmarks soon! Paper, benchmark, dataset, leaderboard: https://lnkd.in/d_Syq-hX. Congrats to Albert Gong, Kyuseong Choi, Abhineet Agarwal, Jason S., Ryan Huang, Raj Agrawal, Anish Agarwal, and Raaz Dwivedi.

Why is there a photo of butter, you ask? A customer recently described Traversal Workers as a "buttery smooth process." They continued with, “we should do away with PIRs and just use Traversal.” That's it. That's the reason. Learn more about Workers in the comments. 

Every AI-generated service, dependency, deployment path, and abstraction increases the number of ways a production system can fail. AI has compressed the time it takes to create that complexity. It has not compressed the time it takes to understand it. Traversal CEO Anish Agarwal's article, published in InfoWorld, explores why engineering productivity increasingly depends on AI that can assemble production context, accelerate incident investigations, and free engineers to focus on building more resilient systems. Read on 👇