Eric Schwartz on what it takes to run an AI SRE at petabyte scale

Coding agents have made writing code cheap, and left troubleshooting exactly where it was. At the AI Engineer World's Fair 2026 in San Francisco, I sat down with Eric Schwartz, a product manager at Traversal, which builds an AI site reliability engineer for large enterprises. Traversal's thesis is the corollary: "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."

Traversal is a Series A company of around 100 employees working with Fortune 500 and Fortune 100 enterprises to support their on-call engineering teams. It started with root cause analysis on sev 1 and sev 2 incidents to cut resolution time, then expanded into triaging high volumes of alerts and support channels. The product runs in the web, in Slack, and in the terminal or code editor.

The version people think they can build in an afternoon

Schwartz gets one objection more than any other. "A lot of people think they can just hook up like Claude to a DataDog MCP and get an AI SRE."

The reason that doesn't hold is the shape of the data. Traversal's customers emit billions of logs a day and petabytes of telemetry, which rules out the pattern where an agent issues live queries and reasons over what comes back. Instead the platform does the work ahead of time: "So actually having a very deep integration and 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."

Indexed data only gets you to the starting line. On top of it sits the harness: the right tool set, the right prompts, the whole experience shaped around SRE workflows. Schwartz describes that as a lot of work in its own right.

A week to production

The obvious follow-up for anything sold to Fortune 100 buyers is how much bespoke tuning each deployment takes. Traversal has pushed that down hard: "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."

There is still a forward deployed engineering team for last-mile optimization, and deployment times were much longer when Schwartz joined a year ago. The data platform is what buys the speed. Because indexing and compression happen systematically, the agent arrives already able to see the customer's production system.

Not every alert deserves a frontier model

Traversal continuously evaluates frontier models from Anthropic and OpenAI alongside open-source models, and assigns different models to different tasks. Scoped sub-agents can run on a lighter open-source model while the initial orchestrator uses the latest closed-source frontier model.

The customer-facing version of that decision is severity. Traversal has a product called alert intelligence that you drop into an alert channel taking on the order of a thousand alerts a day, and it triages and prioritizes them. A sev 1 incident sits at the other end of the same spectrum, and Schwartz is blunt about why they can't be handled the same way: "We're not going to do a really deep, expensive investigation a thousand times in a day. Like it's kind of ridiculous."

So the agent gets tools and models that let it reuse prior work, or do lighter work when the severity is lower. He doesn't claim this is solved, and points to Cognition and Factory as coding agent companies doing work he wants to take inspiration from.

Where the SRE agent and the coding agent stop overlapping

We've run into the convergence question ourselves. WorkOS built an internal coding agent system called Horizon, and we've found it's good at debugging; we often use it to triage issues and run SRE-shaped workflows. So I asked whether coding agents and SRE agents end up as the same product.

Schwartz's answer draws the line at scale: "when you're ingesting like petabytes of data in a day or like 200 billion logs across 500 log indexes in Open Search […] unless you're really really focused on SRE and building the data platform to support that scale it's going to be a challenge."

For a company with a monorepo and its logs in a single index, he expects real overlap, which is precisely why Traversal aims at organizations with thousands of engineers. What separates the two products is whether someone built the ingestion layer underneath. The reasoning on top is the part everybody already has.

The permission ladder

Schwartz gave a talk the day before called self-driving production. The natural question is whether the agent is allowed to act on what it finds and ship the fix itself. The answer turns out to be a customer setting rather than a capability question.

Internally, Traversal has run as a closed loop for most of this year: "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."

With a new customer it starts further down the ladder. Action tools may be disabled entirely, so the agent won't even open a PR. Then it asks a user for permission. Then it opens the PR and a human reviews it. As trust accumulates, customers move toward the self-driving end.

One rung gets skipped almost immediately. Customers like letting Traversal continuously open PRs that tune alerting rules and code to cut volume and noise, and nobody wants a permission prompt for that, because hardly anyone is reading those channels in the first place. Autonomy arrives first in the places humans have already abandoned.

Traversal's CEO Anish Agarwal described the same progression at HumanX earlier this year as a change management problem more than a technical one. Schwartz's version is the operational one: the ladder is a product surface, and each rung is a negotiation.

From air-gapped laptops to bring your own cloud

Enterprise reality shows up hardest in deployment. Early on, Traversal went fully on-prem to get in the door. Schwartz describes being onboarded as a contractor with a company-issued laptop, with the system deployed on customer servers, air-gapped, no data leaving the environment. Even a handful of those was a lot of work, because every deployment was different.

Today there are two models: standard SaaS, and bring your own cloud, where Traversal deploys into the customer's VPC. Bring your own cloud is AWS-only right now, which Schwartz says has been enough for the enterprises they work with; he expects to cross the multi-cloud bridge eventually, and notes that supporting AWS alone is already a lot of work.

The hard parts of putting an autonomous agent inside a Fortune 100 production environment were infrastructure and trust problems. If you're evaluating an AI SRE, or building agents that touch production at all, the questions that separate the demos from the deployments are how the data gets indexed before the agent ever asks anything, and what the agent is allowed to do without asking you first. Where it runs matters too, mostly to your security team.