---
title: "AI SRE agents: Uber's Debug Assist, and how to adopt one"
description: "An AI SRE agent finds the root cause of a production issue and proposes the fix. How Uber's Debug Assist works, how Ailoitte runs it, and how to adopt one."
type: Essay
url: https://sunilkumar.ai/writing/ai-sre-agents/
author: Sunil Kumar (https://sunilkumar.ai/about/)
datePublished: 2026-10-10
pillar: Organisation
tags: [ai-dlc, operations, agentic-ai, evaluation, engineering-teams]
license: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/)
---

# AI SRE agents: Uber's Debug Assist, and how to adopt one

An AI SRE agent finds the root cause of a production issue and proposes the fix. How Uber's Debug Assist works, how Ailoitte runs it, and how to adopt one.

## In short

- An AI SRE agent takes a production issue from alert to proposed fix: it collects the evidence, finds the root cause, mitigates if it safely can, writes the fix, tests it and hands a person a pull request with the evidence attached. The person still decides.
- Uber's Debug Assist runs on about 9,000 issues a month. Its root cause matches the developer's eventual fix half the time, and is in the right module for 40 percent of the rest. The merge rate of its pull requests went from 5 percent to nearly 48 in a year.
- The design choices that make it work are old-fashioned: a fixed plan rather than a free-running agent, plain code for collecting data, a cap of about 20 turns on the model, a cheaper model for reading and a stronger one for writing, and a feature-flag rollback before any code change.
- This is the Operate stage of AI-DLC and level two of the AI software factory: agents do the work in pieces a person can check, and people approve. At Ailoitte we run it on our own products and build it into client pods under the client's runbook.
- Pilot it in shadow mode first. Measure the agent's root cause against what your developers actually fix, mitigate only through reversible actions, and let it open pull requests only once the unit of work is small enough for a person to read.

One day an Uber engineer booked a cab to the office, and while he waited for it he noticed his phone was hot in his pocket. He opened the beta build's bug reporter and typed two sentences: the app was using nearly 30 percent of his battery, and his phone was heating up. Then he got in the cab. Twenty minutes later he opened his laptop and found the cause written up with evidence, the offending code identified, and a pull request waiting for him to review. He hadn't clicked anything else. An agent had done the lot.

That agent is called Debug Assist, and Kriti Dangi, an engineer on Uber's app quality and production observability teams, gave a talk about it that's worth every minute of your time. Uber runs it on about 9,000 issues a month. I'm writing about it because the pattern is the one we run at Ailoitte, on our own products and inside client pods, and because the design choices that make it work are ones any CTO can copy. None of them is a bigger model.

> **AI SRE agent**: An agent that takes a production issue from alert to proposed fix. It collects the evidence, finds the most likely root cause, mitigates if it safely can, writes and tests a fix, and hands a person a pull request with the evidence attached. The person decides. It is the Operate stage of AI-DLC, done well.

## What an AI SRE agent actually is

Site reliability engineering is the discipline of keeping production healthy, and the AI SRE agent is the part of that job a model can now do. It's easy to confuse with two older things. It isn't an alerting tool that clusters logs and draws a graph, which is what most of the products sold as AIOps do, in my experience. And it isn't a chat window you paste a stack trace into. Both leave the person doing the work at two in the morning. An AI SRE agent does the work and leaves the person the decision.

The work is the same seven steps in every company I've seen do this. Discover the issue, from a crash reporter, a monitor or a bug report. Triage it: how severe, who owns it. Find the root cause, with the evidence that led there. Mitigate if there's a safe way to, usually by rolling something back. Write the fix. Validate it, by reproducing the issue and showing the fix makes it go away. Then hand it to a person to review and ship.

The reason this matters is in a number Dangi quoted: Stripe's developer survey, she said, found developers spend 40 percent of their time debugging. The figure roughly holds up. Stripe found the average developer spends more than 17 hours of a 41-hour week on maintenance such as debugging and refactoring. Uber's own figure is that an issue takes an engineer about 28 days to resolve on average. In her telling, and in my experience, most of those days aren't spent fixing. They're spent finding where to look, in a codebase too big for anyone to know, with the context scattered across logs, code, configs and data.

## How Uber's Debug Assist works

Uber's starting point is that it already captured everything. Healthline, its crash and exception tool, logs every crash, hang and performance drop across all its mobile apps and more than 5,000 backend services, with the stack trace, the session, and what the user was doing before. Wisdom, its in-app bug reporter, captures the same metadata plus screenshots when an employee or beta tester types a complaint. Between them, about 50,000 issues a year land on engineers, 90 percent of them affecting customers, and 12,000 pages go out.

Debug Assist sits behind those two systems. The pipeline runs discovery, then automatic triage for severity and ownership, then a root cause analysis that Dangi says takes under 30 minutes, then a resolution step that aims at a fix rather than a report. Five things about how it's built are worth stealing.

It controls the plan. The agent is a graph of deterministic nodes and model nodes, built on LangGraph, and the steps are fixed. In Dangi's words, "we control the plan." The model is never asked to decide which step comes next, only how to do the step in front of it. That removes a whole class of wandering.

The first node is plain code. Collecting the crash, the logs and the metadata is a deterministic step, not a model call, because the logs run to gigabytes and have to be parsed and pruned before any model sees them. Fetching data you already know how to fetch doesn't need a model, and it shouldn't pay for one.

The root cause node runs on a cheaper model with a turn limit. It categorises the issue first (Uber's code, a third-party library, infrastructure, the network) and gives a confidence score. If it needs more, it pulls data through MCP connections to the tracing, logging and incident systems. Then it fans out sub-agents in parallel: one rebuilds the user's timeline from the session, one checks whether the crash correlates with a release, one hunts for the offending commit in a git history pruned to the right versions and modules. There are about 30 of these specialist sub-agents today. The node runs on Sonnet, the smaller Claude model, with limited turns, because Uber found that past about 20 turns the agent is usually down a rabbit hole.

Mitigation comes before the fix. Most Uber features sit behind a flag, and tens of thousands of flags are live on your phone at once. The fix node, which runs on the stronger model, Opus, with a higher turn limit, connects to the feature-flag system first, and if it finds a strong enough correlation between a flag and the crash, it rolls the flag back. The issue stops, and the fix can wait for office hours. Only then does it go looking through the codebase for a fix.

The agent tests its own fix. A validation node tries to reproduce the issue with a unit test, an integration test or, for core flows like booking a ride, an automated run on a simulator with the user's network conditions and flags mocked in. It iterates until the test passes, inside a fixed number of retries. Then the pull request is attached to the ticket and sent to the developer on Slack.

![Debug Assist, in the numbers Kriti Dangi shared. Before: about 50,000 issues a year, 12,000 pages, and about 28 days for an engineer to resolve an issue. With the agent: about 9,000 root cause analyses a month, each in under 30 minutes; a root cause that matches the developer's fix 50 percent of the time, with 40 percent of the rest in the right module; roughly twofold improvement in issue resolution, by her account; and a pull request merge rate that rose from 5 percent to nearly 48 over a year.](../../assets/images/writing/ai-sre-agents-uber-numbers.png)

Two more details matter if you're going to build one. The skeleton never changes. What changes is the skills plugged into each node, so adding a new agent is a matter of adding skills, and about eight agents now share one codebase across five monorepos. And the developer can talk back: a small fixer applies a one-line request, such as adding a test or renaming a variable, to the pull request, a chat lets them question the root cause and correct it, and corrections feed the agent's prompts and skills.

The results are the most honest I've seen anyone publish. About 9,000 root cause analyses a month, which is more than the 50,000 issues a year that used to reach engineers. Both are her figures, and I read the gap as the agent picking up issues that never used to get a person. The root cause matches the developer's eventual fix 50 percent of the time, and about 40 percent of the remainder points at the right module, if not the exact file. Dangi says resolution of tracked issues has improved roughly twofold. And the pull request merge rate went from 5 percent when they started a year ago to nearly 48 percent now. In one case a crash that happened when a user tapped a push notification quickly was caught at a 5 percent rollout, root-caused, fixed and deployed the same day.

## The same pattern at Ailoitte

I've described this as if it were exotic. It isn't. It's the Operate stage of [AI-DLC](/ideas/ai-dlc/), which I'd written down before I saw Uber's talk: agents watch the system and propose fixes, people approve them, and every proposal comes with the evidence the agent used.

On our own products, when an alert fires, an agent reads the error tracker, the logs and the traces, writes up the most likely cause with the evidence timeline that led there, and opens a fix for review. Nothing merges without a person, and the person reads the evidence before the diff. Inside client pods, we build the same stage into the handover: the agent runs under the client's runbook, with a named owner, a kill switch that owner can operate, and a refusal list that says what it may never touch. In the [reference architecture](/playbooks/agentic-ai-reference-architecture-for-enterprise/) this is the operations layer.

Three of Uber's choices are ones we'd already made, for the same reasons. The plan is fixed, and the model only chooses within a step, which is the whole argument of the [agent harness playbook](/playbooks/agent-harness-decision-layer/). Every proposal carries its evidence, because a root cause without a timeline is an opinion. And anything irreversible waits for a person.

One place we add rules Uber didn't mention is the fix itself. An agent on our pods can't open a pull request bigger than a person can read in twenty minutes, about 260 lines in practice. It has to split the work. It can't edit an existing acceptance test. If it needs to, it stops and says why. And every pull request carries a section where the agent lists the files it touched outside the ticket's scope. [The pull request nobody could review](/notes/the-pull-request-nobody-could-review/) is why those three rules exist, and an agent that fixes production bugs is exactly the agent that needs them most, because a bug fix is the change everyone is most tempted to wave through.

## What I'd tell a CTO before they build or buy one

Buy the pattern, not the promise. Every vendor in this space will show you a demo where the agent finds the bug. Ask instead how it fails, who sees the evidence, and what it's allowed to touch.

Keep the model out of the plan. The agents that work are workflows with model steps inside them, not loops that decide what to do next. If a vendor's agent "plans its own investigation", ask how many turns it's allowed and what happens at the limit.

Read with a cheap model, write with an expensive one. Root cause analysis is mostly reading, summarising and correlating. Save the strong model for the fix, where the cost of a wrong answer is higher.

Mitigate before you fix. The fastest way to stop a bad rollout is to roll it back, and a flag rollback is reversible in a minute. Give the agent that action, under a confidence threshold, before you give it a keyboard.

Treat validation as the agent's job and approval as yours. An agent that reproduces the bug and shows the fix makes it go away has done something a tired engineer often skips. An agent that merges its own fix has done something no engineer is allowed to do.

And measure it against reality. Uber's 50 percent is measured against what developers actually fixed, not against a benchmark. That's the only number that tells you anything.

## Questions to ask before you start

Do you capture enough? An agent can't root-cause an issue from a one-line complaint. You need the crash, the session, the logs and the version, together, for every issue. If you don't have that, build it first. It's useful on its own.

Can the agent reach the evidence? Logs, traces, deployments, feature flags, incidents, the repository. Read-only access to all of them, through one interface, is most of the integration work.

Who owns the pull request? Not "the team". A person who gets the message, reads the evidence and approves or rejects. If you can't name them, you're not ready.

What may it change without asking? Write the list. Flag rollbacks, probably yes. Deployments, no. Data, never. This is the refusal list, and the [production-grade tests](/writing/what-production-grade-actually-means-for-an-ai-agent/) apply here as they do to any agent.

What's the baseline? If you don't know your median time to resolve, your pages a week and your overdue backlog today, you won't be able to say whether the agent helped.

What does an issue cost? A root cause analysis that calls a frontier model for 40 turns across a dozen sub-agents isn't free. Set a budget per issue and a monthly ceiling before the first run, the way the [reference architecture](/playbooks/agentic-ai-reference-architecture-for-enterprise/) asks of every agent.

## How to measure it, pilot it and scale it

Baseline for four weeks before the agent touches anything. Issues a month. Median time from report to resolution, and the distribution, because an average like Uber's 28 days hides the tail. Pages per engineer per week. The backlog of issues past their deadline. Alongside them, two of DORA's measures: failed deployment recovery time and change fail rate. The agent should move the first without worsening the second.

Pilot in shadow. Pick one issue class, crashes after a rollout, say, and let the agent produce a root cause for each one while your engineers fix them as usual. Compare afterwards. Count exact matches, right-module misses and wrong answers. Uber's numbers, 50 percent exact and 40 percent of the rest in the right direction, are a reference, not a target. What matters is that the right-direction share is high enough that reading the agent's note saves an engineer an hour.

![The pilot ladder for an AI SRE agent, four rungs with the evidence you need before stepping up. Shadow: the agent writes root causes while people fix as usual; step up when its exact-match rate holds for a month. Mitigate: it may roll back a flag under a confidence threshold, with the owner told; step up when rollbacks are not reverted. Fix: it opens pull requests under the twenty-minute cap (about 260 lines) with sealed tests; step up when the merge rate climbs for a quarter. Scale: add skills and issue classes, not agents.](../../assets/images/writing/ai-sre-agents-pilot-ladder.png)

Then give it one reversible action. A flag rollback under a confidence threshold, with the owner told at once. Measure how often a rollback is itself reverted. If the agent rolls back flags that were fine, tighten the threshold before anything else.

Then let it propose fixes. Pull requests under the twenty-minute cap, acceptance tests sealed, the out-of-scope section on every one. Measure the merge rate, the time from alert to a reviewable fix, and the cost per issue, and step up only when the merge rate has climbed for a quarter. Uber's merge rate took a year to get from 5 percent to nearly 48, and it built the feedback loop alongside, with corrections from developers flowing back into the skills. Build that loop before you need it.

Scale by adding skills, not agents. Uber's skeleton is fixed and the skills are pluggable, and teams bring their own. Each new issue class is a new set of skills on the same harness, with the same gates. Keep one evaluation set per issue class, and retire the classes where the agent doesn't earn its cost.

Write the kill criteria at the start. If the exact-match rate falls below the shadow-mode number for a month, or a rollback causes an incident, or the cost per issue passes the budget, the agent goes back a rung. Say so before the pilot, when nobody is attached to it.

## Where this sits in AI-DLC and the software factory

In [SDLC vs AI-DLC](/playbooks/sdlc-vs-ai-dlc/) the eighth stage is Operate, and the AI-DLC version of it is AI-assisted triage with the full history. An AI SRE agent is that stage built properly: the agent carries the context, the person carries the decision.

In the [AI software factory](/writing/ai-software-factory/) it's level two, where agents write and humans check each small piece, with one level-three habit borrowed for the validation step: the agent keeps trying until the test passes, and a person reads the result rather than the attempts. The feature-flag rollback is a level-three move too, and it's allowed because it can be undone in a minute. That rule, blast radius picks the level, is the whole of it. Let the agent act alone where a mistake costs an afternoon. Keep a person in the loop where it costs a customer.

## How I'm helping companies adopt this

The companies I work with mostly arrive at this from the other end. They have agents writing code, and the first time one of those agents touches a production fix, they find out whether their gates are real. On an insurer's claims platform, an agent's 3,100-line pull request passed all 212 tests and was approved in 25 minutes, and twelve days later the finance team found settlements out by $61. The three rules that came out of that retro, the twenty-minute cap, the sealed tests and the out-of-scope section, are the rules we'd apply before letting an agent near a production fix. In the first month after the rules went in, one pull request in six had something in its out-of-scope section, and two of those would have been incidents.

That's the order I'd suggest. Get the gates right on the Build stage, where the stakes are lower, then let the same agent and the same gates into Operate. A pod does this as a fixed-price engagement, and the handover includes the runbook, the refusal list and the evaluation set, so your own team can run and extend it. If you'd rather have a second opinion first, the production readiness review on the [work with me](/work-with-me/) page is two weeks and ends with a written view of what will break.

## If you are doing this in your company

Start by checking what you capture when something breaks. If a crash doesn't arrive with its logs, session and version, fix that first. It's the half of Uber's system nobody talks about.

Write the refusal list before the prompt. What the agent may read, what it may roll back, what it may never touch, and who approves the rest.

Run it in shadow for a month and score it against your developers' real fixes. Exact, right direction, wrong. Decide the threshold for stepping up before you see the numbers.

Cap everything: turns per step, retries on validation, lines per pull request, cost per issue. Uber's limit of about 20 turns is a good first guess.

Give it one reversible action before any code change, and measure whether that action gets reverted.

Build the feedback loop on day one. Every correction a developer makes to a root cause is training data for your skills. Uber built that loop, and over the same year its merge rate went from 5 to nearly 48 percent.

If you want help with any of that, it's the work Ailoitte's pods do, and the [work with me](/work-with-me/) page has the shape of it.

## Sources

- Dangi, K., [How Uber's AI Agent Debugs Production Issues](https://www.youtube.com/watch?v=CacTDGs-If4), talk posted by Perfology, YouTube, retrieved 10 October 2026 (Debug Assist, Wisdom, the pipeline, the models and turn limits, and all the Uber figures: 50,000 issues a year, 12,000 pages, 28 days, 9,000 issues a month, 50 percent and 40 percent, twofold, 5 to nearly 48 percent, 30 sub-agents, about 8 agents across 5 monorepos).
- Dangi, K., [MCP-Powered Crash Investigation: How 11 MCP Servers Help an AI Agent Debug Production Issues at Uber](https://agntconmcpconjapan26.sched.com/), session listing, AGNTCon + MCPCon Japan, Tokyo, 10 to 11 September 2026.
- Dangi, K., Purohit, A. and Bansal, P., [Real-Time Analytics for Mobile App Crashes using Apache Pinot](https://www.uber.com/blog/real-time-analytics-for-mobile-app-crashes/), Uber Engineering blog, 2 November 2023 (Healthline: crash and exception logging, monitoring, analysis and alerting for all Uber mobile apps and more than 5,000 microservices).
- Stripe, [The Developer Coefficient](https://stripe.com/files/reports/the-developer-coefficient.pdf), September 2018 (more than 17 hours a week on maintenance such as debugging and refactoring, 17.3 hours of a 41.1-hour week).
- DORA, [DORA's software delivery performance metrics](https://dora.dev/guides/dora-metrics-four-keys/) (failed deployment recovery time, change fail rate).
- Ailoitte's client example is anonymised. The figures are from [The pull request nobody could review](/notes/the-pull-request-nobody-could-review/).


## Questions people ask

**What is an AI SRE agent?**

An agent that does the first hours of an incident for you. It collects the crash report, logs and traces, works out the most likely root cause with the evidence attached, mitigates if it safely can (rolling back a feature flag, say), and proposes a fix for a person to review. It sits next to your on-call rotation. It doesn't replace the person who decides.

**Can an AI SRE agent replace on-call engineers?**

Not yet, and I would not let it. Uber's agent gets the root cause exactly right about half the time, which is a very good first draft and a poor last word. What it replaces is the two in the morning fog: the hour of finding where to look. The decision to merge and deploy stays with a person, and so does anything the agent cannot undo.

**How accurate is AI root cause analysis?**

Uber reports 50 percent exact matches against the developer's eventual fix, and about 40 percent of the rest pointing at the right module, if not the exact file. That is the only public production number I trust, because it is measured against real fixes rather than a benchmark. Measure yours the same way, in shadow mode, before you let the agent change anything.

**What should an AI SRE agent be allowed to do on its own?**

Read everything it needs, with read-only access. Act only where the action can be undone in a minute, such as rolling back a feature flag, and only when the evidence is strong. Never deploy, delete data or change a customer record without a named person's approval. Write the list down before you build. It's the agent's refusal list.

**How do you measure an AI SRE agent?**

Baseline first: issues a month, median time to resolve, pages per week, the overdue backlog. Then four numbers for the agent: root cause accuracy against developer fixes, the share of its pull requests that merge, time from alert to a reviewable fix, and cost per issue. Watch DORA's failed deployment recovery time and change fail rate alongside them, so a faster agent is not also a riskier one.


---
Sunil Kumar, Co-founder and CEO, Ailoitte Technologies. https://sunilkumar.ai/about/