Traversal vs yeet: An AI SRE Reasons Over Your Telemetry, It Doesn't Collect It

Traversal does not collect its own telemetry. It reasons over the observability stack you already run, described in its own Amex Ventures release as identifying root cause "across petabytes of data from any enterprise observability stack," with read-only access to your data. That puts your instrumentation coverage upstream of everything it can conclude, and yeet sits on the other side of that line: it loads an eBPF probe for the one fact nobody recorded, while the incident is still open.

Traversal's benchmark post is called The Model Isn't the Bottleneck, and on its own terms it is right. Against the strongest frontier-model-plus-MCP setup pointed at the same observability stack, Traversal was judged the better root cause analysis 83% of the time, a 255 Elo gap, finishing in 9.5 minutes on average against 19.7 and 33.5 for the top two direct-access baselines. The conditions travel with those numbers: 25 real severity 1 through 3 incidents at one large financial-services enterprise, blinded pairwise judging with five votes per pair and shuffled order, ground truth from the raw human incident record, and a 30-minute budget for the baselines against Traversal's 12. Wiring a good model to your APIs is not the same product as an investigation loop built by causal-inference researchers, and the benchmark says so.

I build kernel-level tooling for Linux hosts, and I have never run a 4,000-service estate or sat in a 150-person incident bridge. What I watch engineers hit, repeatedly, is the step before that bridge convenes: someone trying to establish one fact about what a process on one box actually did, and finding that nothing wrote it down. That step sits upstream of any reasoning layer, and no amount of reasoning quality moves it.

The short version

Tool	What it operates on	What has to already exist	When the deciding fact was never recorded	Where it runs
yeet, a JavaScript runtime for Linux ops	the live kernel on one Linux host: processes, packets, syscalls, file operations, BPF events	a Linux host with BTF and TCX link support, kernel 6.6 or newer. Nothing instrumented in the application	you write a probe for that fact and attach it while the incident is open	on your host. Nothing is shipped off the box, and there is no metrics store, no query language, and no view wider than that host. A probe can outlive the terminal: yeet run -d leaves it running under the daemon, and registering it as a service gives it a restart policy and a definition on disk that survives a daemon restart
Traversal, an AI SRE for the enterprise	"petabytes of data from any enterprise observability stack," plus source code and change management systems	the telemetry, the observability tooling, and the code repositories already in place	the search runs over the records that exist, and its own research measures accuracy falling as information sources are removed	read-only access to your data, with on-premise and bring-your-own-cloud deployment

Two rows, because these are not competing products. The columns are the axis: what each thing operates on, and what has to have happened before it can answer anything.

What Traversal is genuinely better at: 4,000 services, 500TB a day, and a 30-hop causal chain

Everything at estate scale. Their benchmark environment is 4,000-plus services across cloud-native, service mesh, legacy data stores and identity infrastructure, more than 500TB of MELT data per day, 100,000-plus code repositories in ten or more systems, and major incidents that pull 150-plus people in for two to four hours. Getting from "users can't log in" to a causal state there is described as a 10-to-30-hop investigation across millions of tokens. That is estate-scale correlation, and a single-host probe does not do it.

Their single-incident example is worth reading twice. Fourteen minutes of HTTP 500s and 75-second timeouts across an instant-decision service, one pod out of a large fleet producing 631 of 634 failures, invisible unless you compare it against its healthy peers. Traversal isolated that pod and recommended draining it; the direct-access baselines returned a shared infrastructure event, a downstream provider issue, a mainframe database hang, and a recent config deployment. Their line is "every baseline found a reasonable neighborhood. Traversal found the house." Peer comparison across a large fleet is a real capability, and it is what a dependency graph built before the incident is for.

Their research is also unusually candid about how hard the task is. ORCA-bench, built with Columbia and Cornell Tech, put five frontier models through 1,079 production RCA tasks and reported that at medium difficulty the strongest model got every root cause right in only 25.3% of incidents, dropping to 10% on tasks beginning with a vague report like "users are reporting site issues," while the weakest proposed an implausible root cause in roughly 40% of investigations. Publishing a benchmark your own category scores badly on is not a marketing move, and if your problem is multi-hop incidents across a fragmented stack, that is the problem Traversal is built for.

Why a causal search cannot separate two hypotheses when the deciding record was never written

Because a search over telemetry is a search over records, and a record that was never written is not a weak signal, it is an absent one. The general form of that argument, that pre-configured instrumentation caps what any reasoning consumer can conclude, is already made at length in The Observability Industry Has the Wrong Customer. The version specific to causal search is narrower, and Traversal's own research speaks to it directly.

Traversal's own reading of ORCA-bench is that "observability data alone is often insufficient for accurate causal reasoning," which is the people who built the reasoning layer stating that its conclusions depend on what it can reach. Source code is one information source their benchmark removes and measures. Instrumentation coverage is another, and no benchmark varies it, because a benchmark needs a fixed environment. Your fleet is where it varies.

Their fourth finding names the failure this produces: agents "gravitated toward the most visible downstream symptom rather than tracing failures back to their upstream origin," which they flag as especially important on multi-hop incidents where the failing service is several dependencies removed from the component that introduced the issue. Their Can You Trust Your AI SRE? post lands in the same place: systems that "attempt to compensate for missing or partial data through inference tend to produce confident but incorrect conclusions," and a trustworthy one should "make uncertainty explicit when context is missing." Being honest about missing context is the correct answer for a reasoning layer. It is not an answer that produces the missing record.

Read the Amex wording precisely, because it is the sentence most likely to be misread by someone mid-shortlist. Traversal's technology "reduces the need for labor-intensive engineering work to instrument systems and maintain tribal knowledge" as it investigates millions of alerts and incidents simultaneously. That is about the ongoing engineering cost of maintaining instrumentation and institutional knowledge for a reasoning system to consume, across any stack, without vendor lock-in, and nowhere in their published material is it a claim to observe a code path that emitted nothing. Their AI SRE landscape post frames the second of its two axes as "the scope of data searched." The argument here is only that this axis has a floor set somewhere else: by what your fleet recorded, before the incident, about a condition nobody anticipated.

Does adding one more data source actually change what an AI SRE concludes?

By 9 to 16 percentage points, in the one case Traversal measured. ORCA-bench's third finding removes a single information source, source code access, and reports RCA accuracy dropping across every frontier model evaluated, with hallucination rates generally increasing. The useful reading of that is not about source code specifically. It is that accuracy is a function of what the agent can reach, and Traversal put a number on the sensitivity themselves rather than leaving it as an assertion.

Then look at where that benchmark sets its other inputs. Instrumentation is at the top of its range: a live OpenTelemetry-instrumented e-commerce application of 19 microservices in 13 languages, more than 50GB of telemetry over six days, Prometheus, Jaeger, OpenSearch and Grafana all exposed to the agent, and full source code available on every task. With the evidence turned up that far, the strongest of five frontier models got every root cause right in 25.3% of incidents at medium difficulty, and 10% when the incident arrived as "users are reporting site issues." Their enterprise benchmark rules out one candidate for the binding constraint: point the strongest frontier model at the same stack, watch it lose 83% of the pairings, and the model is not what was limiting the answer. ORCA-bench then measures a second candidate and finds it binds as well. Hold the loop and the model fixed, take one information source away, and the accuracy moves. Which makes the reachable evidence a term in the result, and it is the term that sits on your side of the boundary.

Two of the three ways to move it are slow. A better frontier model is not yours to ship. Getting consistent instrumentation and log retention across 4,000 services is a program of work measured in quarters, and when it lands it still covers conditions somebody anticipated in advance. The third way is a probe for one specific fact, attached to one host, during the incident that made you want the fact. That one takes minutes, needs no deploy window, and is the only one of the three that responds to something you learned after the incident started. It is also the narrowest: one fact, one host. It does not have to be short-lived, though. Detach it with yeet run -d and it keeps running under the daemon after you close the terminal, and a probe worth keeping can be registered as a service with a restart policy. Narrow and available beats broad and quarterly when the bridge is open and the hypothesis space has not collapsed.

Our traces are sampled and our logs are capped. Does an AI SRE still find the root cause?

It finds the root cause when the deciding evidence survived filters you configured months ago, and each of those filters is documented by its own project. Jaeger, one of the four interfaces in Traversal's benchmark environment, returns a default probabilistic sampling policy of 0.001, one trace in a thousand, when no configuration is provided. OpenTelemetry's sampling documentation states that with head sampling the decision "is not made by inspecting the trace as a whole," so it "is not possible" to keep every error-bearing trace by head sampling alone. Prometheus warns that "every unique combination of key-value label pairs represents a new time series," which is why per-request detail is structurally unavailable from a metric rather than merely missing. And automatic instrumentation covers what somebody wrote an instrumentation for: the OpenTelemetry Java agent instruments "many libraries, frameworks, and application servers right out of the box", roughly a hundred of them, and points you at the issue tracker for anything not on the list.

None of that is a criticism of those projects; it is the shape of the input. A causal search reading a 0.1% trace sample, cardinality-capped metrics, and logs at whatever level was enabled is reasoning over a filtered projection of the incident, and the filter was configured by someone who did not know what would break.

The AI SRE named a downstream symptom as the root cause. Was the model wrong, or was the data?

Check whether the fact separating the two hypotheses was in the telemetry at all, because if it was not, the answer you got may be the best-supported conclusion the record allows. A causal search ranks explanations by consistency with the evidence it can reach, so when the evidence that would have eliminated the leading candidate was never emitted, the visible downstream symptom is genuinely the best-supported explanation in the data, and a confident answer is the expected output rather than a defect. Traversal's own benchmark measures both halves: agents gravitating to the visible symptom, and accuracy falling when an information source is taken away.

Which makes the postmortem question a different one from "was the tool wrong." Name the specific fact that would have collapsed the hypothesis space, then ask where it would have come from. If someone had to go get it by hand from a live process, that is the step no reasoning layer performs.

Half our dependency graph is managed services and other teams' binaries. What can either tool see there?

Neither can see inside a managed service or another team's binary. The difference is what each establishes about the boundary. Traversal reads the telemetry both sides publish and the change records around them, which is the right layer for "is this us or them" when both sides are instrumented into a system it can reach. yeet reads the syscalls and packets your own host actually issued toward that dependency, which is a different fact from what the dependency's status page claims and needs no cooperation from the dependency. Both stop at the boundary; yeet stops one hop later, on your side of it, which is often the hop that settles a vendor ticket.

Should we buy an AI SRE or close our instrumentation gaps first?

Run the test on your last three postmortems first, because your own history already contains the answer. For each incident, find the fact that actually closed it, and ask whether it was in your telemetry at t=0 or whether a human went and got it. Where the deciding facts were already recorded and the cost was 40 minutes of correlation across six systems, an AI SRE buys exactly what you are short of, and Traversal's benchmark is a reasonable place to calibrate the value. Where a human had to fetch the fact from a live process mid-incident, a faster reader of the records does not address the step that took the time.

This is not an argument for deferring the purchase, nor for treating coverage as a project you can finish. It cannot be finished: coverage is decided before the incident, and the incident is by definition the thing nobody anticipated. The useful version is an ordering. Make sure you can produce a fact on demand, then buy the layer that reasons over facts.

Can I add the missing signal mid-incident without a deploy or a restart?

Yes, and it takes a probe rather than a change to the application. yeetd runs on the host, the yeet CLI talks to it, and a script is JavaScript bound to a typed, live view of the kernel: every process, packet, syscall, file operation and BPF event as a queryable graph. You write a probe for the specific thing you need to know, attach it, read the answer, detach. No application change, no sidecar, no restart of the pod holding the evidence, no deploy during a change freeze.

curl -fsSL https://yeet.cx | sh   # install the runtime
yeet run .                        # attach the probe, read the answer, Ctrl-C to detach
yeet run -d .                     # or leave it running under the daemon, detached
yeet ps                           # what is running; yeet attach <id> to look in again

The worked version, on real HTTP traffic, is in What the Kernel Sees That Your Proxy Doesn't and How to Monitor HTTP Traffic on Linux, where an eBPF program at the TC layer counts request lines the application never logged. httpinspect is one such probe.

One distinction matters here: yeet is not another always-on pipeline shipping everything all the time so a query can find it later. That design carries the same ceiling one layer down, because it still decides what to collect before the incident. yeet is question-shaped. The probe exists because you have a question, and it answers that question. Keeping it around afterwards is a choice you make rather than the default: detach it, or register it as a service with a restart policy, and it keeps running. What stays absent is the pipeline, not the process. A time-series store, a query language, fleet-wide aggregation and service maps are things it does not do, and the tools named in this post do them.

Where Traversal and yeet fit together

In an order, and the order is the recommendation: get the fact, then reason over it. When an incident stalls because nothing recorded what a process on one box did, a probe produces that record in the next few minutes, and the next pass of the causal search runs over evidence that now includes it. yeet closes a coverage gap at the moment you discover it. Traversal correlates across an estate no single host can see. There is no version where yeet closes a 255-Elo gap in cross-system investigation, and none where a better investigation loop recovers a fact from a system that never wrote it down. Both are structural, and both stay true if either company triples its engineering team.

The bottom line: probe for the missing fact with yeet, then let Traversal reason over it

yeet is a JavaScript runtime for Linux ops that produces a kernel-side record of something nobody instrumented, on demand, on one host, while the incident is open. It changes what the evidence contains, which is the one input no reasoning layer can supply for itself. Traversal is a reasoning layer over that evidence, and a good one: an 83% win rate against the strongest direct-access baseline on 25 real sev1-3 incidents, on half the time budget, with the method notes published. It changes how fast the evidence gets read. If your last three postmortems closed on facts already in Prometheus, Jaeger and your logs, a faster reader is what you are short of. If they closed on facts a human fetched from a live process, start on the fetching, because a causal search over a filtered projection of an incident returns the best answer that projection supports, which is sometimes the symptom.

Frequently asked questions

Does Traversal require OpenTelemetry, or a specific observability vendor?

Traversal's published material describes working across any enterprise observability stack rather than naming a required vendor, and frames avoiding lock-in as part of the point. Its public benchmark environment was an OpenTelemetry-instrumented application exposing Prometheus, Jaeger, OpenSearch and Grafana, which is what the agent was evaluated against rather than a stated prerequisite. What it needs in your environment is a deployment question for their team, not for a third party.

Is yeet an alternative to Traversal?

They are not on the same axis, so if you are choosing between two AI SRE products, yeet is not the third item on that list. An AI SRE reads the records your estate already holds. yeet writes a record that does not exist yet, for one Linux host, while the incident is open. The thing to compare it against is the engineer who SSHes in to establish a fact by hand, and the comparison is how long that takes.

Can yeet replace Datadog or Prometheus?

No, and the reason is worth stating precisely, because the runtime is less ephemeral than it used to be. A probe does not have to die with your terminal. yeet run -d spawns the isolate detached under the daemon, prints its id, and returns your prompt; yeet ps lists what is running, yeet attach reconnects to its console output without stopping it, and yeet kill ends it. For something you intend to keep, a script can be registered with the daemon as a service: one or more named units and a restart policy of always or on-failure, started, stopped, restarted, enabled and disabled through the daemon's service API. yeet service list and yeet service tree show what is registered, with its units and routes. A service definition is persisted to disk, so it survives a daemon restart, and a unit can mount HTTP routes and be spawned lazily the first time a route asks for it.

What yeet still does not have is the part that makes Prometheus Prometheus: a time-series store, a retention window, PromQL, alerting rules, and a view wider than the host the probe is attached to. Nothing is aggregated across boxes and nothing is shipped off the one it runs on. Where a probe keeps its numbers, it keeps them because the script you wrote does something with them. That boundary is a design decision rather than a missing feature: the cost of the in-kernel check scales with matched events instead of total traffic precisely because there is no collection pipeline behind it.

What does yeet need on the host?

Linux, a kernel built with BTF, and TCX link support, which means kernel 6.6 or newer. Check both on a quiet afternoon rather than nine minutes into an outage. The daemon handles the privileged BPF load, so yeet run never takes sudo.

Do I have to write the probe myself while the incident is running?

Writing the probe is JavaScript against a typed kernel graph rather than C against the verifier, which is the kind of task a model does well when the runtime checks its work. That is the intended loop: describe the fact you need, the model writes the script, yeet runs it. It is still a task with a clock on it, so install the runtime and run something trivial with it before you need it.

Can either tool see inside TLS?

Not at the packet layer. TLS payloads are ciphertext where a TC-layer probe reads them, so there is no plaintext request to parse; reading it needs a uprobe on SSL_write or SSL_read, which is a different probe. A reasoning layer sees whatever your application chose to log after decryption, which returns you to the coverage question.

Sources

• The Model Isn't the Bottleneck (Traversal, August 2026). The benchmark this post grants: Traversal judged the better RCA 83% of the time against Fable 5 + MCP, 1696 Elo against 1441, a 255-point gap; 9.5 minutes average against 19.7 and 33.5; conditions are 25 real sev1-3 incidents at one large financial-services enterprise, blinded pairwise judging with five votes per pair and shuffled order, ground truth from the raw human record, and a 30-minute budget for baselines against Traversal's 12.
• ORCA-bench: How Ready Are Language Model Agents for Oncall? (Traversal AI Research, with Columbia and Cornell Tech). The benchmark environment is a live OpenTelemetry-instrumented e-commerce app of 19 microservices in 13 languages generating over 50GB of telemetry across six days, with Prometheus, Jaeger, OpenSearch and Grafana exposed plus full source code; 1,079 tasks, five frontier models, 25.3% best-case accuracy at medium difficulty, 10% on vague reports, and a 9 to 16 point accuracy drop when source code access is removed.
• Traversal Announces Strategic Investment from Amex Ventures (Traversal, 2026). The wording this post reads closely: root cause "not just correlation, across petabytes of data from any enterprise observability stack through intelligent data caching, a proprietary AI agent architecture, and dynamic learning of an enterprise's underlying causal system dependencies," which "reduces the need for labor-intensive engineering work to instrument systems and maintain tribal knowledge."
• Can You Trust Your AI SRE? (Traversal). Their own treatment of the confident-wrong-answer failure mode, arguing that systems which "attempt to compensate for missing or partial data through inference tend to produce confident but incorrect conclusions," and that a trustworthy system should "make uncertainty explicit when context is missing."
• The AI SRE Landscape (Traversal). The two-axis framing drawn from hundreds of engineer interviews, workflow complexity against "the scope of data searched," plus the argument that incumbent platforms "only provide insight on the data that is stored on their platform."
• Announcing our Seed and Series A from Sequoia and Kleiner Perkins (Traversal, June 2025). The deployment model quoted here, "read-only access to their data and flexible on-premise deployments," alongside the $48M raise led by Sequoia and Kleiner Perkins and the founding team's background in causal machine learning.
• Jaeger sampling documentation (Jaeger, 2.11). Head-based, tail-based and remote sampling; where no configuration is provided, "Jaeger will return the default probabilistic sampling policy with probability 0.001 (0.1%) for all services," which is the coverage floor a reasoning layer inherits on an unconfigured service.
• OpenTelemetry sampling concepts (OpenTelemetry docs). Head sampling makes the decision "as early as possible" and "not by inspecting the trace as a whole," so it "is not possible" to guarantee every error-bearing trace is kept with head sampling alone; consistent probability sampling keys the decision on the trace ID and a target percentage.
• Prometheus metric and label naming (Prometheus docs). "every unique combination of key-value label pairs represents a new time series, which can dramatically increase the amount of data stored," with an explicit warning against labels holding high-cardinality dimensions such as user IDs or email addresses.
• OpenTelemetry Java agent supported libraries (OpenTelemetry docs). The agent "automatically instruments many libraries, frameworks, and application servers right out of the box," roughly a hundred entries with per-version support notes, and anything absent gets "consider filing an issue," which is what automatic instrumentation coverage means in practice.
• BPF Type Format (BTF) (kernel.org). BTF is "the metadata format which encodes the debug info related to BPF program/map," extended from type descriptions to function and source-line information, and it is what makes a compiled probe portable across kernels rather than rebuilt per host.
• httpinspect (yeet-src, GPL-2.0). A worked example of a question-shaped probe: two eBPF programs on tcx/ingress and tcx/egress that match HTTP request lines in-kernel and aggregate by METHOD host path, with its own caveats section stating the plaintext-only and lower-bound-count limits.

Related resources

• The Observability Industry Has the Wrong Customer. The general form of this post's argument, made as architecture rather than comparison: you decide what to monitor before you know what will break.
• What the Kernel Sees That Your Proxy Doesn't. The concrete version of an on-demand probe, on HTTP traffic, including what a TC-layer program can and cannot read.
• How to Monitor HTTP Traffic on Linux. Where kernel-side counts and an access log disagree, and which one to believe when they do.
• The Advantage of yeet. What a programmable kernel runtime is for, if the probe-shaped model in this post is unfamiliar.
• What is eBPF?. The mechanism underneath, for a reader evaluating whether running probes in the kernel is something they want on production hosts.
• eBPF-Speed L7 Enforcement Without a CNI Migration. The same runtime acting rather than observing, which is the half of it this post did not cover.

See your machine the way the kernel sees it.

Built with yeet, a JS runtime for writing eBPF programs on Linux machines. Join us on discord.