Eric Schwartz, product manager at Traversal, explains how coding agents shift engineering time from building software to troubleshooting it. He argues that observability dashboards show what broke but not why, and that root cause analysis is fundamentally a causal, multi-hop problem that is hard for both humans and LLMs. He presents a five-level framework of 'self-driving production' autonomy, from war rooms to closed-loop fixes, and shares case studies on alert intelligence for a PepsiCo supply chain team and incident root cause analysis at American Express. The talk closes with five questions for evaluating an AI SRE. Recorded at the AI Engineer World's Fair 2026 in San Francisco. # Video Identity Observations **Video:** "The 5 Levels of Self-Driving Production — Eric Schwartz, Traversal" ## Creator Self-Description - **Role claim:** "my name is Eric. I'm a product manager at Traversal." - **Company framing:** Traversal is presented as an **AI for site reliability engineering (AI SRE)** vendor. The speaker frames the company's founding motivation: "that's kind of what motivated our founders to launch traversal," noting "our four founders, three of them come from academia. One comes from quant finance" with "decades of their lives towards causal machine learning." - **Core product thesis (creator claim):** "root cause analysis is not an observability problem. It's a causal problem." The company's technical pillars are named as the **production world model** and the **causal search engine**. - **Vision claim:** Building toward "a self-driving production environment... a closed loop system" — detect, diagnose, fix, verify "without ever having to page or disrupt any of your team members." ## Claimed Scope and Positioning - **Named "5 levels" framework:** The talk's signature claim — autonomy levels analogous to self-driving cars, from "level zero... fully manual" to "level five... the holy grail" (diagnose + fix + verify across an enterprise environment). - **Enterprise/fortune-500 scope claim:** Repeated positioning at "Fortune 500 companies," "Fortune 100 enterprise" scale, with stated data volumes ("trillions of logs... tens of billions of metrics and events") and a claimed result of "80% plus root cause" on high-severity incidents. - **Named customers:** American Express, Pepsi, Digital Ocean, Capital One — with detailed case studies for Pepsi (alert intelligence) and American Express ("traversal is the first responder to every single incident... within 3 minutes we'll post a very detailed root cause analysis"). - **Competitive differentiation:** Explicit positioning against observability tools ("tools like data dog, elastic, splunk, service now") and against coding-agent loops ("cloud code or cursor or codeex"), plus a five-question buyer's checklist for evaluating "AI SRE" vendors — indicating awareness of a crowded, "very hot space." ## Intended Audience (Observable) - **Enterprise engineering leaders and on-call/SRE practitioners.** Evidence: discussion of "on call teams," "alert fatigue," war rooms of "50 engineers," Fortune 100 scale concerns, and cost framing ("$400 billion a year," "seven plus hours each week"). - **Prospective enterprise buyers, not hobbyists.** The talk is a conference-style product presentation ("I'm happy to answer any questions after") focused on procurement-relevant proof points, case studies, and evaluation criteria. - **Technically literate but not deeply technical:** concepts (SRE, observability, causal ML) are explained at a primer level ("just a quick primer on what I'll cover"). ## Creator Claims vs. Demonstrated Patterns - **Claims:** performance metrics (80%+ root cause, 3-minute RCA posting, "50 plus engineers" saved per incident) and customer outcomes are creator/vendor assertions from named engagements, not independently verified in the material. - **Demonstrated:** the video itself shows a structured product-marketing talk format — problem framing, analyst-flavored statistics, customer case studies, framework naming ("5 levels," "production world model"), and a buyer's checklist — consistent with vendor thought-leadership content aimed at enterprise AI/SRE adoption. # Delivery Observation — Eric Schwartz, "The 5 Levels of Self-Driving Production" ## Overall Style Eric delivers a **product-manager-style conference talk**: structured, customer-evidence-driven, and promotional in a measured way. The delivery is conversational and speech-like, with frequent fillers and self-corrections typical of live spoken delivery. ## Recurring Vocabulary & Phrases - **"Kind of"** is the dominant hedge word, appearing constantly: > "you could think about software engineering as **kind of** three buckets" > "level five is **kind of** the holy grail" - **"That's a big problem"** is repeated as an emphatic refrain: > "And the the data **kind of bears this out. This is a big problem.**" > "if customers aren't able to pay their credit card bill, like **that's a big problem.**" - **Scale number lists** recur as a persuasion device: "five to 10 teams get paged, anywhere from 20 to 50 engineers," "hundreds of repos, thousands of lo log indexes," "thousands or tens of thousands of alerts." - **"Fortune 500 / Fortune 100"** appears repeatedly as a credibility marker: > "results that we're seeing with Fortune 500 companies" > "it's really not trivial to do at scale for a Fortune 100 enterprise." - Frequent **"like"** and **"uh/um"** fillers throughout ("they're like, you're telling me what's broken"). ## Teaching Habits - **Explicit roadmap upfront**, then follows it: "just a quick primer on what I'll cover. Uh I'm going to talk a little bit about how AI agents are changing…" - **Chunking into buckets/levels** — a signature organizing move: > "software engineering as kind of three buckets. There's system design… development… troubleshooting." - **Analogy-driven framing** — the self-driving-car levels structure is used as the talk's spine: "We like to think of it in terms of levels almost like self-driving cars." - **Rhetorical question → answer** pattern: > "So what happens to either end of the spectrum? What happens to system design and what happens to troubleshooting?" > "And so what are we supposed to do about it?" - **Numbered checklists** in the evaluation section: "The first is can your AI surre see all of your production data? … The second is can it search through this data…" - **Contrast framing** ("before / now") in each customer case study: > "**before traversal** their team would get thousands or tens of thousands of alerts" > "And so **now** uh traversal is the first responder to every single incident" ## Communication Patterns - **Personal credential placement**: "tools like data dog, elastic, splunk, service now **where I worked for several years** before joining traversal"; "companies like American Express, **who I spend a lot of time with personally**." - **Customer voice-overs** to dramatize pain points: > "you're telling me what's broken, you're not telling me why, and you're not telling me what to do about it." - **Concrete humanizing details** in metrics: > "this is a a good night of sleep that 53 engineers can have now." - **Softening before sales pitch**: "I won't go into this in too much detail, but this is kind of how we think about these five questions." ## Stable Patterns vs. Isolated Moments **Stable (well-repeated):** hedge words ("kind of"), bucket/level frameworks, before-now case-study contrast, rhetorical questions, and Fortune-500 scale claims. **Isolated (single appearance, treat with caution):** the humorous humanizing touch about "a good night of sleep," the quoted customer complaint, and the self-deprecating note about lacking formal CS training ("Folks like me without any formal computer science training") each appear only once, so they may not be habitual delivery features. # Observation Record: "The 5 Levels of Self-Driving Production" — Eric Schwartz, Traversal ## Speaker Identification - **Eric Schwartz**, identified in the transcript as a **product manager at Traversal**. All claims below are his, expressed in a product presentation/promotional context. --- ## Claim 1: AI coding agents have shrunk development, but shifted burden to troubleshooting **Position:** Coding agents (Claude Code, Codex, Cursor) make development faster, enabling "10x more" output — but the time saved is being consumed by increased troubleshooting. **Stated reasoning:** - Software engineering has three buckets: **system design**, **development**, and **troubleshooting**. - Development has sped up; people without formal CS training (including himself) can now contribute production code. - The *hope* is teams spend more time on creative design; what Traversal actually observes at enterprises is **more time on troubleshooting**, because "much more code is being written" and "people have less understanding of the code that's being pushed into production." **Claimed supporting data:** - Enterprises spend upwards of **$400 billion/year** ("by some accounts") on this problem. - **40% of executives** say their teams face it. - Engineers lose **7+ hours per week** troubleshooting while on call. > "Tools like cloud code and codeex and cursor... are fantastic, but they result in more code and more complexity." *Qualification preserved:* Schwartz acknowledges the tools are "fantastic" — the criticism is about downstream consequences, not the tools themselves. --- ## Claim 2: Observability tools tell you *what* broke, not *why* **Position:** Observability platforms (Datadog, Elastic, Splunk, ServiceNow) are valuable but cannot surface root cause. **Stated reasoning:** - These tools flag breakage and correlations but not root cause or remediation. - From his own experience on observability products at ServiceNow, customers repeatedly said: > "You're telling me what's broken, you're not telling me why, and you're not telling me what to do about it." - He cites Google (the SRE handbook) and Anthropic, saying Anthropic "described in their own words that LLMs are not great at this problem" — i.e., not great at identifying root cause. --- ## Claim 3: Root cause analysis is a causal problem, not an observability problem **Position:** This is Traversal's founding thesis. **Stated reasoning:** - Example (based on a customer case): a failing checkout API may require **5–10 hops across dozens of services and petabytes of data** to reach a root cause (e.g., an expired TLS certificate). - At small companies, one seasoned SRE may hold all the tribal knowledge; at Fortune 50/100 enterprises, no single engineer does — leading to "a war room with 50 engineers." - Traversal's four founders — **three from academia, one from quant finance** — spent decades on **causal machine learning**, which he frames as the right lens for cause-and-effect discovery. --- ## Claim 4: "Self-driving production" — the 5-level autonomy framework **Position:** Traversal is building a **closed-loop system**: detect issue → find root cause → put up fix → verify fix, ideally without paging anyone. The levels (explicitly analogized to self-driving cars): | Level | Description (as stated) | |---|---| | **0** | Fully manual; Slack war rooms, Zoom calls, hours of debugging — "where most companies are today" | | **1** | Rules/automations (e.g., structured workflows with Claude Code, Cursor, Codex); breaks down in novel situations with no runbook | | **2–3** | More automation; e.g., a homegrown agent good at debugging a specific service or alert set | | **4** | The "leap": cutting across an entire environment — hundreds of services, repos, thousands of log indexes; "quite challenging to homegrow" | | **5** | "The holy grail": full-environment diagnosis **plus** deploying and verifying fixes | --- ## Claim 5: Customer results (promotional claims) **Customers named:** American Express, Pepsi, Digital Ocean, Capital One. **Claimed scale/results:** - Handles trillions of logs and spans, tens of billions of metrics/events. - **80%+ root cause** hit rate for high-severity incidents. ### Pepsi (alert intelligence) - Before: thousands to tens of thousands of alerts weekly; engineers had backlogs of **~700 alerts** each ("a crippling state"). - After: Traversal pre-investigates and prioritizes alerts; flags noise-reduction opportunities (updating alert rules, dismissing alerts, creating technical-debt tickets). ### American Express (incident RCA) - Before: **5–10 teams paged, 20–50 engineers**, ~60 minutes in the cited example (possibly hours or days). - After: Traversal is "the first responder to every single incident"; posts detailed RCA to the incident Slack channel **within 3 minutes** of the "bridge" being declared; can update ServiceNow tickets. - Claimed outcome: **50+ engineers saved** from being paged (he cites "53 engineers" getting "a good night of sleep"). *Note:* These are single-company case studies presented by a vendor's product manager; the claims are reported as Traversal's own reported results, not independently verified. --- ## Claim 6: Five evaluation questions for AI SRE tools Schwartz offers criteria for judging vendors "claiming that they're solving these problems": 1. Can it **see all** production data (gaps limit root-cause quality)? 2. Can it **search at scale** without blowing up cost or observability infrastructure? 3. Can it **map relationships** between entities in the data? 4. Does it **improve autonomously** over time (vs. maintained markdown files / forward-deployed engineers)? 5. Can it make **multiple hops** to non-obvious root causes in minutes? — He adds a qualitative threshold: "anything more than 5 minutes and you've kind of lost the plot... people will fall back onto their own habits." --- ## Claim 7: Traversal's architecture - **Production world model**: maps and makes sense of ingested data and entity relationships. - **Causal search engine**: the "harness and mechanism" agents use to search the mapped data. - These two components are presented as the path to Level 5 "fully self-driving production" for Fortune 500 enterprises. --- ## Source-of-truth notes - All figures ($400B, 7+ hours, 80%+, 53 engineers, 3 minutes) are presented as stated by Schwartz; several are explicitly hedged by him ("by some accounts," "in this particular example"). - No counterarguments, contradictions, or opposing views appear in the transcript; this is a one-sided vendor presentation, and the record reflects that framing. # Video Attribution & Provenance Record **Video title:** The 5 Levels of Self-Driving Production — Eric Schwartz, Traversal ## Speaker Roles - **Eric Schwartz** — *Product Manager at Traversal*; sole identified speaker and presenter of the talk. Self-introduced in the transcript: "my name is Eric. I'm a product manager at Traversal." - Role context: creator/company representative delivering what appears to be a conference-style talk; promotional content for Traversal's AI SRE product. - **Unidentified voice** — closes the video ("Cool. Thank you for your time."), likely an event host/moderator; no name provided. ## Speaker Attribution Notes - All product claims, statistics, and case studies originate from the single presenter and are vendor statements, not independently sourced in the transcript. - The title metadata (Eric Schwartz, Traversal) is consistent with the transcript's self-identification. ## Referenced Sources & Third-Party Claims (as stated by presenter) - **Industry statistics** — attributed vaguely: "by some accounts" — $400B/year enterprise spend, 40% of executives, 7+ hours/week troubleshooting. No specific citation given. - **Google** — described as author of the SRE handbook; commented on root cause limitations. - **Anthropic** — quoted as stating LLMs are not great at identifying root cause. - **Observability tools mentioned:** Datadog, Elastic, Splunk, ServiceNow; coding tools: Claude Code, Codex, Cursor. - **Customer engagements claimed:** - **Pepsi** — alert intelligence use case (supply chain; thousands–tens of thousands of alerts/week; 700-alert engineer backlogs). - **American Express** — incident RCA case study (referred to as "annex" once in the transcript); "first responder," RCA posted within 3 minutes, ~50+ engineers spared paging. - Other named customers: Digital Ocean, Capital One. - Performance claims: 80%+ root cause accuracy on high-severity incidents; trillions of logs/spans, tens of billions of metrics. - **Internal example** — one screen example "based on something we saw with one of our customers" (checkout API / expired TLS certificate); anonymous. ## Promotional Segments — FLAGGED - The entire talk is promotional for **Traversal**: product overview (alert intelligence, incident RCA, self-healing, production support, code resilience), "production world model," "causal search engine," and the five-level autonomy framework culminating in Traversal's offering. - Claims of customer results and performance metrics are vendor self-reported and unverified within the source. ## Availability & Provenance Limits - **Comments:** No information available. - **Curated metadata:** Only video ID and title supplied; no channel, date, publication details, or linked sources. - Transcript contains no timestamps, URLs, or citations for the statistics quoted. Hey everybody. Um, my name is Eric. I'm a product manager at Traversal and today we're going to talk about self-driving production. So, just a quick primer on what I'll cover. Uh I'm going to talk a little bit about how AI agents are changing the software development life cycle. Uh the problems that that introduces for engineers and how AI for site reliability engineering fits in uh which is where traversal comes into play. And then I'll talk about a few examples of um what this looks like in practice for enterprises that we work with at Traversal uh and a bit about how we've built our AIS surre uh to deliver the results that we're seeing with Fortune 500 companies. So uh I guess to start some quick context on uh kind of the different phases of software engineering. Uh so sure you're all familiar but at a high level you could think about software engineering as kind of three buckets. There's system design like what is it that I want to build? What's the architecture that I want to build? There's development which is actually writing the code building the thing. And then there's troubleshooting. So once you build something and it's interacting with the real world, it starts to break uh and you need to fix it. And so with the advent of coding agents, the development portion has shrunk. development is a lot faster. Folks like me without any formal computer science training can now contribute u production code. And so this is great. Development's a lot faster. Teams can do 10x more. But then what happens to either end of the spectrum? What happens to system design and what happens to troubleshooting? The hope is that you spend more time on the design part thinking creatively about what it is that you want to build. But what we actually see with the enterprises that we work with is that um more and more time is being spent on troubleshooting. Uh much more code is being written. People have less understanding of the code that's being pushed into production. And so what you end up with is more issues, more comp uh more complex environments. Uh, and instead of spending all your time on the creative architecture and design, your teams are bogged down on troubleshooting. And the the data kind of bears this out. This is a big problem. Um, by some accounts, enterprises are spending upwards of $400 billion a year. Uh, 40% of executives say that this is a problem that their teams face. And on average, engineers are losing seven plus hours each week uh just troubleshooting when they're on call. And this is going to become an increasing issue that we'll all hear more about, that we'll all experience more over time as tools like cloud code and codeex and cursor, which are fantastic, um uh they are fantastic, but they result in more code and more complexity. And so what are we supposed to do about it? Um there are all kinds of great observability tools. Tools like data dog, elastic, splunk, service now where I worked for several years before joining traversal. Um these are great but uh there's only so much that they can do like these tools will tell you that something is broken. They'll point out all the things that have broken. Um they'll point out things that are maybe correlated but they won't tell you the root cause of the issue. And when I worked on observability products at Service Now, this was something I heard time and again from the customers that I served, which was like, you're telling me what's broken, you're not telling me why, and you're not telling me what to do about it. And so, no matter how many dashboards you create in these tools, it's not really helping teams keep up with the pace of innovation uh and complexity that's being added to their environments. And this is not just something we believe at Traversal. This is kind of a widely held view. um Google who kind of wrote the S sur handbook like the bible of site reliability engineering uh has commented on this directly and we also heard recently from anthropic u quotes where they described in their own words that LLM are not great at this problem. They're not great at pointing out what is the root cause of an issue. Now like why is this so hard? What makes this so challenging? Um in this particular example that we have on the screen like which was based on something we saw with one of our customers. Um if a checkout API is failing uh you might need to make five to 10 hops across like dozens of services and pabytes of data to actually get to the root cause. And so in a very small contained environment, perhaps there's a single seasoned SR at your company that knows the full stack and can debug everything and has all the tribal knowledge to sift through all your data. But if you're a Fortune50 enterprise or a Fortune 100 enterprise, there's no single engineer that has all of that context. And so what you end up with is a war room with 50 engineers like pulled in uh and many many hours trying to debug this issue because everyone has their own particular slice of context. No one has kind of the full scope and breadth of this. And so no, it's really challenging for a human or a human paired with cloud code to get kind of the full spectrum of context needed to jump from a checkout API is failing over here five hops away to the expired TLS certificate that maybe caused the issue. And so that's kind of what motivated u our founders to to launch traversal. Fundamentally the belief that we have at traversal is that uh root cause analysis is not an observability problem. It's a it's a causal problem. And so that's why our four founders, three of them come from academia. One comes from quant finance. Uh and they've dedicated like decades of their lives towards causal machine learning which is how do you find cause and effect? uh and have applied it to this problem because it's a massive one that enterprises are really struggling with. And so that kind of brings us to the topic of this talk which is self-driving production. Um what we're building at Traversal is the ability for an enterprise to basically have a self-driving production environment. What that means is a closed loop system where uh as issues break the AI system finds the issue the finds the issue or the incident or the alert finds the root cause of what caused that issue in the first place puts up a fix verifies that it's been fixed and the loop is closed with hopefully without ever having to page or disrupt any of your team members so that they can keep focusing on building. And this is a spectrum. U a lot of companies are not fully there yet. We like to think of it in terms of levels almost like self-driving cars uh or autonomous driving. We think about it in the same frame. So level zero is where most companies are today where everything is fully manual. You're pulling a bunch of people into a Slack war room or onto a Zoom call. You're spending hours debugging things. Level one might be where you have some rules and automations. And we're hearing a lot about like loops that teams are building now with tools like cloud code or cursor or codeex. Uh and so these might be like rulebased automations where you can build out a very structured specific workflow in response to an alert. Those rule-based automations kind of break down when it's a novel situation. And usually a sub one is something you haven't seen before. There's not really a runbook for it. And so the rule-based automation breaks down there. And level two and level three is kind of where you start to get a little more automation built in. In level three, perhaps you have like a a homegrown agent that is really good at debugging a issues for a specific service or a specific set of alerts. But really where we see the leap is going from level three to level four, which is cutting across an entire environment. So hundreds of services like hundreds of repos, thousands of lo log indexes. It's quite challenging to homegrow a solution that can handle that. And level five is kind of the holy grail, which is not only can we diagnose issues across a full production environment for a large enterprise, but also put up the fixes and verify the fixes as well. And so, uh, we're really proud that at Traversal, we get to work with and serve some of the biggest companies in the world. Companies like American Express, who I spend a lot of time with personally, uh, Pepsi, Digital Ocean, Capital One. Um, and it's really cool to see the volume and scale of data that Traversal is able to handle. So, you know, trillions of logs that are generated, trillions of spans, tens of billions of metrics and events, um, and hitting 80% plus root cause uh, for these high severity incidents at this scale is a technical feat that we're pretty proud of. And so, beyond just these kind of results at a high level, um, as a product manager, I like to think about the use cases that we build for our customers. And so there's there's a few different types of scenarios and use cases that we found that can deliver a lot of value. I'll dig into a few in more detail, but at a high level, there's alert intelligence, a product that I spend a lot of time on, which is helping on call teams triage and prioritize hundreds or thousands of alerts that they may be receiving in a single day, helping you deal with alert fatigue. There is incident root cause analysis, which is where we got started. How do we help you find the root cause, pinpoint the root cause of an incident in minutes when it otherwise would have taken hours and dozens of engineers? There is self-healing, which is not only telling you what the root cause was, but putting up a fix to address and mitigate that issue. There's production support, which is the the variety of questions and issues that your team might be dealing with in any given day, wanting to chat with their production environment, get specific data points that maybe aren't part of a a broader incident, but are still taking up a lot of time and toil for your teams. And then pre-production, there is code resilience. Like when you're putting up changes, how do you make sure that this code is making your system more resilient and reliable over time? And so at Traversal, we cover kind of the whole gamut of use cases. Um, but I'll dig into alert intelligence and incident root cause just to give you a bit of a more detailed sense of what that might look like, what that looks like, and I'm happy to answer any questions after about the others. So for alert intelligence, the example that I have here is uh based on our engagement with Pepsi. And so Pepsi uses traversal across a bunch of their different applications, but a very core one is for their supply chain. They have a lot of internal tooling and software to make sure that um the raw materials and the finished product can move through their supply chain. And a very critical piece of that is making sure that finished product gets from their warehouse to their trucks to their retailers at the end. And um before traversal their team would get thousands or tens of thousands of alerts every single week. Uh and at any given time a single engineer might have a backlog of 700 alerts. This is kind of a crippling state to be in. Like you have so much noise that you don't know where to look. You don't know what's broken and things slip through the cracks. Uh or you just try to keep up and burn out. And so this was a big problem that Pepsi was facing and they used traversal uh to help parse the signal from the noise of these tens of thousands of alerts. And so now instead of each engineer having a backlog of 700 alerts, they get a very pri a prioritized and filtered set of alerts that have already been pre-investigated. We flag to them the alerts that are actually worth digging into. We flagged to them opportunities to reduce alert noise, whether that's updating the underlying alert rules in their code, uh dismissing alerts that don't need to be addressed right now, uh or creating tickets for alerts that are maybe technical debt that can be handled later on but aren't super important to deal with at this moment. And so we've seen a lot of great results with Pepsi uh on this alert use case and many of our other customers as well. Um the next example is around incident root cause analysis and and this is a case study from our engagement with annex um where I've personally spent a lot of time myself. Um, so before working with traversal, what an incident looked like at American Express is anywhere from five to 10 teams get paged, anywhere from 20 to 50 engineers, and it could take, in this particular example, 60 minutes, but it could take hours or days to get resolution to to an incident. You can imagine if customers aren't able to pay their credit card bill, like that's a big problem. Or if they're not able to log into their mobile app, that's a big problem. And so now uh traversal is the first responder to every single incident that's created at American Express. And so what that looks like is the second the bridge is declared. That's the term they use internally. The second the incident is declared traversal is dispatched within 3 minutes we'll post a very detailed root cause analysis in the Slack channel where that incident is being managed. We can post updates to Service Now tickets if they want to as well. And rather than paging five teams and 58 engineers because you have that initial analysis, it's a lot less chaotic, you have a sense of what actually broke. And either no teams get paged or maybe you page the one or two teams just to verify the findings that traversal posted. Uh and so we save in this case like 50 plus engineers uh from the time and headache of being paged uh into this incident. Um, and that's especially appreciated when these incidents are happening in the middle of the night. Like this is a a good night of sleep that 53 engineers can have now. And so those are those are two of the use cases that we're especially proud of at Traversal, but like I mentioned, there's a bunch of others. Maybe in the last couple minutes I'll just highlight like AI site reliability engineering is a very hot space. You've probably, if you're familiar, you've probably heard of a lot of companies in the space or claiming that they're solving these problems. Um, we think that there's a few really key questions you should be asking uh that are critical to getting this right. So, the first is can your AI surre see all of your production data? If you're only giving it a slice or if it has gaps in its understanding, it's going to be very hard to get to a very detailed root cause. The second is can it search through this data can be it's often pabytes of data hundreds of billions of logs um without blowing up costs or taking down your observability infrastructure. Um this is really not trivial to do at scale for a Fortune 100 enterprise. The third is can it map out the relationship relationships between all of these entities in your data. even if you're able to ingest and read through all this data, if you don't know what to do with it and if you're lost, it's kind of worthless. And then four, does it get better and smarter over time autonomously without having to dedicate engineering resources to maintaining a bunch of markdown files or having a bunch of forward deployed engineers taking up your your team's time to maintain the system knowledge? And finally, u can it make multiple hops? Can it find the non-trivial, non-obvious root cause that's far away from the initial symptom in a matter of minutes? What we've seen is like anything more than 5 minutes and you've kind of lost the plot. You've lost the patience of the on call team and people will fall back onto their own habits. So, it needs to be really good. It needs to be really fast. And I won't go into this in too much detail, but this is kind of how we think about these five questions at traversal. So at the bottom of the stack is how we think about kind of a analyzing all your data uh without increasing cost. So basically how do we ingest and map all of the data uh that we're connected to and integrate with all of that data. In the middle of the stack is how we make sense of that data. And so we call that our production world model. How do we map out all the relationships between all the dent the data that we're ingesting? And then finally, how do we surface that and package that up in either use cases or user experiences that are valuable to your team? And so there's a lot of components to getting this right u especially at Fortune 500 scale. And so um that's a bit about what we've been building at Traversal, what we're delivering at Traversal. The core pieces like I mentioned are the production world model. So how we map and make sense of all the data that we integrate with and then what we call uh what we call refer to as our causal search engine. Basically the the harness and mechanism that we give our agents to search through all of that data uh that we've mapped out. And so the production world model and the causal search engine are how we believe we are going to help Fortune 500 enterprises get to the level five of autonomy fully self-driving production. \>\> Cool. Thank you for your time. \>\> \[music\]