In short: AI raises the volume of change reaching production faster than operations can absorb it. Operating capacity is an organisation's ability to run what it ships. Its core, recovery capacity, is how much change production can absorb while still detecting, attributing and recovering within its objectives. AI SRE agents speed up investigation, yet independent benchmarks show frequent misdiagnosis. The foundations come first.

Where do the defects your review missed go?

They go to production, and the evidence that they are arriving there is now difficult to dismiss. In New Relic's 2026 State of AI Coding survey, 78% of respondents reported more incidents once AI generated code shipped, and 82% experienced at least one production failure tied to it in the previous six months. Qodo's 2026 report puts the share of organisations that have experienced an AI related production incident at 89%.

The same New Relic survey shows where the problem hides. At review, 94% of respondents favoured AI generated code and only 2% considered it lower quality. Code that reads well in the review room behaves differently under production load, which is the perception gap of the Absorption Gap moving one stage downstream.

When agents raise the volume of change faster than the organisation can verify it, the shortfall in verification capacity becomes leakage. Whatever the Verification System cannot catch, operations inherits.

Why was operations sized for human change?

Every operating model carries assumptions about the change it receives. On call rotas, alert thresholds, runbooks and incident processes were designed around a certain rate of change, made by people who could usually explain why they made it. Agents shift all three at once: more changes, more authors, and less human memory of the intent behind each one.

The last shift matters most. When an incident starts, the first questions are which change caused it and why it was made. With human authors, the answer often lives in someone's memory or a pull request thread; with agent authors, the reasoning may never have been recorded anywhere a responder can find it.

Early signals suggest operations is already absorbing the strain. Catchpoint's SRE Report 2026, based on 418 reliability professionals surveyed in July and August 2025, found median toil at 34% of engineering time, up from 20% the year before, even as AI tooling spread across alerting, diagnosis and remediation. Only 49% said AI had reduced their toil, while 35% saw no change and 16% saw an increase. Directors were far more likely than individual contributors to report a reduction, 60% against 38%.

This is the third downstream stop in Constraint Migration, after verification and integration. The capability that has to grow here is operating capacity: an organisation's ability to run what it ships, from observability and service objectives to on call, incident management and learning. Within it, the measure that binds is recovery capacity: the volume of change production can absorb while still detecting, attributing and recovering from failures within its service objectives.

It joins integration capacity at the pipeline and context capacity on the input side, each naming the point where agent supply meets a limit designed around people.

What did Amazon's outages reveal?

In February 2026, the Financial Times reported that a 13 hour interruption to a customer facing AWS system in December followed engineers allowing Kiro, Amazon's agentic coding tool, to carry out changes. According to the reporting, the agent chose to delete and recreate the environment, affecting AWS Cost Explorer in parts of mainland China. Amazon said the engineer involved had broader permissions than expected, a user access control issue rather than an AI autonomy issue, and that the same failure could have followed from any developer tool or manual action.

In March, a briefing note for a mandatory retail engineering meeting, also reported by the FT, described a trend of incidents with a high blast radius and listed generative AI assisted changes among the contributing factors. One outage of the retail site lasted around six hours. Senior Vice President Dave Treadwell wrote that the company would introduce "controlled friction" to changes in the most important parts of the retail experience while investing in more durable safeguards. Amazon has disputed parts of this account, stating that only one incident discussed was related to AI and that none involved AI written code.

Amazon's position deserves weight, and four lessons hold under either reading. The first is that Amazon is widely regarded as one of the most operationally rigorous organisations in the industry, with a long practice of correction of error reviews and service ownership, yet its operating model still appears to have been sized for human change.

The second lesson is that the public argument centred on blame, human error or AI error. For operations, the more useful question is whether the system records which actor did what, under which permission and intent, quickly enough to recover. The third is the remedy: controlled friction reduces the rate of change in the places where failure costs most, which is the short term lever when recovery capacity binds. The fourth is that the agent reportedly acted with operator level permissions, which moves the question from observing agents to controlling them, the subject of governance and its core, control capacity.

What do AI SRE agents already do well?

The market has read the same signals, and capital is following. Resolve AI announced a $125 million Series A at a $1 billion valuation in February 2026, followed in April by a $40 million extension at $1.5 billion. Traversal and Cleric compete in the same emerging AI SRE category, and the incumbents have moved as well: Datadog made its Bits AI SRE agent generally available in December 2025, and AWS followed with its DevOps Agent on 31 March 2026.

The capabilities converge on investigation. An AI SRE agent starts work when an alert fires, gathers metrics, logs and traces, correlates them with recent deployments and code changes, and writes an investigation journal for the responder. AWS reports that one customer, Western Governors University, reduced a production investigation from an estimated two hours to 28 minutes, with the agent locating a configuration fault and surfacing knowledge that had existed only in undiscovered internal documentation.

That last detail matters as much as the time saved. Much of what slows an investigation is context that exists but cannot be found, the same problem a governed context supply addresses on the input side, and an agent that assembles it in parallel, at any hour, removes a genuine share of the toil Catchpoint measured.

Where do AI SRE agents fall short?

Vendor reported accuracy and independent benchmarks currently diverge. AWS reports 94% root cause accuracy among preview customers. ITBench, presented at ICML 2025, found agents on state of the art models resolved 11.4% of its SRE scenarios, and ORCA-bench, a 2026 preprint built on six days of telemetry from an instrumented microservice system, found the best agent identified the full root cause in 25.3% of realistic incident reports and 10% of vague ones. Some models named an implausible root cause in up to 40% of reports.

The gap is partly a matter of conditions, since customer incidents tend to arrive with better context than a deliberately vague benchmark report. Two ORCA-bench findings point to what that context is. Removing source code access lowered accuracy and raised hallucination for every model tested, and vaguer incident reports cut accuracy by between 19 and 50 percentage points. The benchmark is coauthored by researchers from Traversal, a vendor in the category, which lends weight to its candour about current limits.

Practitioners report a consistent pattern. Speaking at QCon London in March 2026, Anthropic reliability engineer Alex Palcuie described Claude as exceptionally fast at reading logs and traces but prone to confusing correlation with causation, at one point repeatedly diagnosing a broken cache as a capacity spike. The chief executive of Resolve AI has made a similar point from the vendor side: foundation models alone are not yet sufficient for production operations, which demand reasoning over fragmented telemetry with a very high bar for accuracy.

A detail from the ORCA-bench paper captures the deeper issue. In a worked example, the best performing agent traced failed checkouts to a feature flag that had been switched on, then reported that it could not determine who or what had switched it, because no change audit had been recorded. The agent completed its reasoning; the system had not given it the provenance to finish the attribution.

An agent reasons over the signals, ownership and change records an organisation already has. Where these are fragmented or missing, it produces confident wrong answers faster, and any remediation it proposes is itself agent output that must pass through the Verification System before it touches production.

What foundations do agents need first?

The foundation is mostly established practice; what changes is that it stops being optional, because both responders and agents depend on it. Service objectives come first, defined on the user journeys that matter rather than on individual components. Without them, neither a person nor an agent can judge whether an anomaly is an incident, and the organisation has no error budget with which to slow change when reliability degrades.

Alerting standards follow. Paging on user facing symptoms and on the rate at which the error budget is consumed keeps alert volume proportionate to impact. An AI SRE agent triggered by every noisy cause alert will investigate noise at scale.

An owned service catalogue tells responders and agents who is accountable for each system and what it depends on. It is one of the inventories behind a governed context supply, and operations is where its freshness is tested hardest.

Reliable release practice carries over from integration capacity. Every deployable artefact should be versioned, releases managed through a known process, changes kept backward compatible, and risky behaviour placed behind feature flags with a tested path to roll back. These practices let a responder pin an incident to a specific version and revert it in minutes, and they matter more as the number of authors grows, because an agent that cannot see which version is live cannot reason about what changed.

Change provenance is the new requirement. Every production change should carry its intent, the change itself, the type of author, person or agent, the approval and the permission used, and that record should appear as a marker in the telemetry. This is the record the ORCA-bench agent lacked, and the record that would have settled much of the Amazon debate.

Codified runbooks and graduated autonomy complete the foundation. Agents start read only, then propose actions, then execute reversible ones within the error budget, while people approve anything irreversible. Each step up is earned through evidence gathered at the step below.

Figure 1. AI SRE agents sit on the foundation, not beside it; recovery capacity is measured across the whole stack.

Figure 1. AI SRE agents sit on the foundation, not beside it; recovery capacity is measured across the whole stack.

How should recovery capacity be measured?

Recovery capacity relates operational performance to the change load that produced it. Mean time to recovery describes the incidents an organisation has had. Recovery capacity indicates whether production can still detect, attribute and recover within its objectives as change volume rises, which is what tells a CTO whether agents can be allowed to add more.

The shape of the change matters as much as its volume, and a case from La Redoute illustrates the relationship. Under an earlier quarterly release cycle, each release delivered a large batch of change, and roughly two weeks of incidents and hotfixes followed. The pattern was a capacity signal: change arriving in batches of that size exceeded what operations could absorb.

The constraint eased once change became small and continuous. Changes flowing through CI/CD, a shared platform and automation raised integration capacity, and automated tests raised verification capacity. Change then reached production at a size and rhythm that operations could absorb, without enlarging the operations function.

The lesson for agents is direct. Recovery capacity is shaped upstream, by batch size, verification and integration, as much as by anything operations does. Agents can recreate the quarterly release through volume alone, so keeping each change small, verified and attributable is the least expensive way to keep production within what it can absorb.

Three probes give a first reading without new tooling. Time to attribution measures the interval from the first alert to naming the change, its author and its intent. Provenance coverage is the share of production changes that carry the full record. Error budget burn per unit of change shows whether reliability holds as weekly change volume grows. When these probes degrade, the defensible response is to slow change where recovery capacity is thin and invest until it can carry more, and they supply the evidence for the health window in validated business value.

Why is incident management the next absorption capacity?

More change from more authors produces more incidents that overlap. In the busiest ORCA-bench scenario, six faults ran concurrently, and three of the models tested each identified a different single cause while missing the other five. Coordination, not diagnosis alone, becomes the limit.

Agents can carry a growing share of that coordination: building the timeline, keeping the record, drafting status updates, retrieving similar past incidents and suggesting runbook steps. These tasks are well bounded and free responders to concentrate on the decision in front of them.

Some decisions remain with people. Declaring severity, choosing between rollback, a forward fix or graceful degradation, approving what customers are told and deciding what the organisation learns all weigh business risk against technical evidence. PagerDuty's 2026 survey of 1,000 leaders found that 68% of organisations lose more than $300,000 per hour during IT incidents, which indicates the scale of judgement involved.

Learning after the incident is where operations feeds the rest of the AI Engineering Production System. In the same PagerDuty survey, 48% of organisations reported increasing resilience by turning incidents into structured learning. Under agent volume, that learning should change Direction: where agents are allowed to act, which services need more verification and where change should slow. Who and what may act during an incident is also the first question of control capacity, the subject of the next article in this series.

Where should a CTO start?

A sensible sequence begins with the three probes, which show whether recovery capacity is already binding. Agent changes should then be held to the same small batch discipline asked of people, the provenance gap closed, and service objectives, alerting standards and release practice brought to the services where agents change the most. AI SRE agents belong after these steps, read only at first, with time to attribution measured to confirm that they help.

The question for your operations

Agents will keep raising the volume of change, and production will absorb only what operations can detect, attribute and recover from. The organisations that keep pace are likely to be the ones that treat recovery capacity as something to design and measure.

If agents doubled your change volume next quarter, would you know within minutes which change, from which author and under which intent, broke production?

Read further

FAQ

What is operating capacity?

Operating capacity is an organisation's ability to run what it ships: observability, service objectives, alerting, on call, incident management and learning after incidents. In the AI Engineering Production System it is the capacity of the operations and observability stop. As agents raise the volume of change, operating capacity has to grow with it, or the defects that escape verification accumulate in production.

What is recovery capacity, and how does it differ from MTTR?

Recovery capacity is the volume of change production can absorb while still detecting, attributing and recovering from failures within its service objectives. Mean time to recovery describes past incidents in isolation. Recovery capacity relates recovery performance to change load, which makes it the measure that indicates whether agents can safely be allowed to ship more.

Do AI SRE agents replace on call engineers?

Current evidence does not support that. Agents speed up investigation and correlation, but independent benchmarks such as ITBench and ORCA-bench report low root cause accuracy on realistic incidents and frequent plausible but wrong diagnoses. The likely near term model is agents assembling context and proposing actions while engineers decide, with autonomy extended step by step as evidence accumulates.

Is the rise in incidents really caused by AI generated code?

The survey evidence is self reported and often vendor sponsored, and Amazon disputes that AI written code caused its outages. The underlying mechanism holds regardless of attribution: when change volume rises faster than verification capacity, more defects reach production, and operations sized for human change rates absorbs them. Recovery capacity matters whatever the share of blame.

What should be in place before deploying an AI SRE agent?

Service objectives defined on user journeys, alerting on symptoms and error budget burn, an owned and current service catalogue, reliable versioning and release practice, and change provenance recorded on every production change. Without these, an agent reasons over incomplete signals and produces wrong answers faster. Agents should start read only, with time to attribution measured to confirm the benefit.

Sources