Agentic incident response has quietly stopped being a demo and started being a production reality, and the hard question is no longer whether an AI agent can investigate an outage. It is how much authority you are willing to give it at 3am when nobody senior is awake. New survey data published in August 2026 puts numbers on that discomfort, and the numbers are worth sitting with if you run an on-call rotation.

Research from Caylent, conducted by Censuswide among 200 senior enterprise leaders across the United States and Canada, found that 60.5 percent of organisations are piloting, deploying or evaluating AI agents for automated incident response or remediation, and that 59.5 percent already run agents autonomously in production somewhere in their stack. Yet when the same leaders were asked what response model they actually want during an incident, only 8.5 percent chose fully autonomous incident closure where the agent handles everything and humans review afterward. Adoption is near universal. Trust is not. That gap is the whole story, and it has direct consequences for how you should structure your rotation, your runbooks, and your escalation policy this quarter.

What the agentic autonomy data actually says

It is easy to read a survey like this as another round of AI hype, so it helps to look at what respondents said in detail rather than the headline. The findings were summarised by Redmond magazine from the underlying Enterprise Readiness for Agentic Engineering and Autonomous Cloud Operations report, and the shape of the answers is more nuanced than either the boosters or the sceptics tend to allow.

Adoption has already outrun governance

Every respondent said they were actively exploring agentic AI in engineering or cloud operations. Roughly 36 percent said they operate agents inside defined guardrails in production, and another 23.5 percent said agents are broadly deployed across engineering and operations workflows. The use cases cluster in places where the blast radius is naturally contained: automated testing, scans and quality gates at 67.5 percent, incident response and remediation at 60.5 percent, deploying code to non production environments at 48.5 percent, and proposing infrastructure changes at 48 percent.

Notice the ordering. Teams are happiest handing agents work that produces a recommendation or operates in a sandbox, and least happy handing over work that changes production state without a human in the path. Incident response sits awkwardly in the middle, because the whole point of paging someone is that production state already needs changing and the clock is running.

The authority gap, not the accuracy gap

The most interesting finding is that 98 percent of leaders said they would allow AI agents to execute production changes autonomously under the right conditions. Only 2 percent said no safeguard would ever make that acceptable. So resistance is not philosophical. It is conditional. When asked what would accelerate adoption, 83 percent placed stronger guardrails on equal or higher footing with model intelligence.

The preferred operating models tell you exactly where teams want the line. About 30.5 percent want the agent to detect and alert while a human decides whether to roll back or remediate. Another 23.5 percent want the agent to attempt remediation with human override available. Only 8.5 percent want the agent to close incidents on its own. Caylent's chief technology officer Randall Hunt summarised it as authority being the open question rather than accuracy, and that framing is the right one for on-call leaders to adopt.

The blockers are not who you would guess

Security teams were named as the top internal blocker by 54.5 percent of respondents, followed by compliance and risk at 48 percent, and legal and procurement at 34.5 percent. Engineers came in at just 16 percent. If you have been assuming that your SREs are the conservative party in this conversation, the data says otherwise. Engineers who carry the pager tend to want anything that reduces 3am toil. The friction lives in the parts of the organisation that have to answer for what happened afterward.

Why incident response is the hardest place to hand over authority

Plenty of engineering work is a reasonable candidate for autonomy. Incident response is unusually resistant to it, for three reasons that are structural rather than temporary.

Incidents are exactly where context is thinnest

An agent reasoning about a healthy system has abundant signal: stable baselines, complete traces, a dependency graph that matches reality. During a major incident, all of those degrade at once. Telemetry pipelines back up, sampling kicks in, dashboards time out, and the dependency graph the agent learned last week may no longer describe the system it is looking at. The moment you most want autonomous judgement is the moment the inputs to that judgement are least reliable.

Human responders handle this by falling back on tacit knowledge. They remember that this service always looks unhealthy when the upstream cache is cold, or that the alert on the payments queue is chronically noisy on Mondays. That knowledge lives in heads and Slack threads, not in a runbook, and it is precisely what an agent is missing when the formal signals go dark.

A confident wrong answer costs more than no answer

Automation bias is well documented and it gets worse under time pressure. A responder who is thirty minutes into a severity one and has not found the cause will grab a fluent, plausible explanation with both hands. If that explanation is wrong, the team does not simply lose the time spent on it. They lose the time spent on it, plus the time spent unwinding whatever mitigation it prompted, plus a chunk of the shared mental model that everyone in the channel now has to rebuild.

This is why teams that have run AI runbook assistants in anger often report turning them off for high severity work while keeping them for triage. The value of a suggestion is not its speed. It is its speed multiplied by its accuracy, minus the cost of the times it sends people the wrong way.

Agents can create the failure mode they are meant to fix

The most underappreciated risk is that an automated responder is itself a source of load. Retry storms are the classic example, and there is a recent, well documented case. In its public write up of the August 17 outage, GitHub described a 7 hour 47 minute incident in which a capacity failure cascaded into authentication problems, and noted that errors in Copilot services triggered a client side retry loop that increased traffic during recovery. That behaviour had to be mitigated before traffic could be safely restored. GitHub's immediate corrective actions included applying consistent retry limits, retry budgets and variable timeouts across service to service interactions.

Now imagine an autonomous remediation agent added to that picture with the authority to restart services or shift traffic. Without strict rate limits and a global kill switch, an agent that reacts to symptoms during a cascading failure is another retry loop, just one with a larger unit of work. Any autonomy design that does not treat the agent as a load generating client of your own system is incomplete.

A practical authority ladder for on-call agents

The useful move is to stop treating autonomy as a single switch and start treating it as a ladder with defined rungs. Each rung is a specific grant of authority for a specific class of failure, and promotion between rungs is earned with evidence. Here is a ladder that maps cleanly onto how most teams actually work:

Level 0, observe. The agent watches alerts and incidents, produces nothing that a responder acts on, and builds a track record you can evaluate offline. Useful for two to four weeks before anything else.
Level 1, enrich. The agent posts context into the incident channel: recent deploys, related alerts, relevant past incidents, the current owner of the failing service. It states facts, not conclusions. This is the highest value, lowest risk rung and many teams should stop here for a while.
Level 2, hypothesise. The agent proposes a ranked root cause with the evidence attached, explicitly labelled as a hypothesis, and always shows the query or trace that led to it so a human can falsify it in under a minute.
Level 3, act with approval. The agent proposes a specific reversible action, such as rolling back the last deploy or draining a bad node, and a named human approves it with one click. The action, the approver and the timestamp are all logged.
Level 4, act with override. For a narrow, pre approved list of failure classes with high confidence detection and cheap reversal, the agent acts immediately, announces what it did, and any responder can undo it instantly. This is where the 23.5 percent in the survey want to be, and it should apply to a handful of scenarios, not to production generally.

Notice that fully autonomous closure is not on the ladder. That is deliberate. Closing an incident is a judgement about whether customers are actually fine and whether the follow up work has been captured, and both of those are organisational decisions rather than technical ones.

How to decide which failure classes graduate

Promotion should be per failure class, not per agent. An agent that is excellent at diagnosing certificate expiry has told you nothing about its ability to reason about a distributed deadlock.

Pick candidates with three properties

Good first candidates for level 3 and level 4 authority share the same traits: the detection signal is unambiguous, the remediation is a single reversible step, and the cost of being wrong is bounded and obvious. Expired TLS certificates, a single unhealthy node behind a load balancer, a disk filling on a stateless worker, a known bad deploy detected by an automated canary. These are boring, and boring is the point.

Bad candidates share the opposite traits: the symptom has many possible causes, remediation is multi step or irreversible, and being wrong makes things worse. Anything touching data migrations, anything involving failover between regions, anything where the mitigation itself is a large change.

Measure before you promote

Before granting a failure class a higher rung, ask for a specific evidence bar. A reasonable one: at least twenty real occurrences observed at the current rung, with the agent's proposed action matching what the human actually did in at least ninety percent of them, and zero cases where following the agent would have escalated the incident. Write the number down in advance so the decision is not made on vibes during a good week.

Demote quickly and without ceremony

Every rung should have a documented demotion trigger, and demotion should require no meeting. One agent action that made an incident worse is enough to drop a failure class back a level pending review. If demotion is socially expensive, nobody will do it, and the ladder becomes a ratchet that only turns one way.

The guardrails that make on-call autonomy defensible

The survey respondents named the guardrails they want, and the list matches what experienced operators would ask for anyway. Translated into concrete on-call requirements:

A visible kill switch. Any responder, not just an admin, must be able to disable all agent actions with one command, and that command must work when your identity provider is the thing that is broken.
Rate limits on the agent itself. Cap actions per incident and per hour. An agent that has taken three actions without the incident improving should stop and escalate rather than continue.
Least privilege and short lived credentials. The agent's permissions should be scoped to the specific actions on its approved list. Read only by default, with narrow write grants that expire.
Evidence with every claim. No conclusion without the underlying query, trace or log line attached. If a responder cannot verify a claim in a minute, the claim is not usable during an incident.
Complete audit trail. Who or what took each action, when, under whose authority, and what the state was before and after. This is what your compliance team is actually asking for when they block adoption.
Reversibility as a precondition. If an action cannot be undone by a single subsequent action, it does not belong at level 4.

Why the incident channel is the right control plane

There is an architectural point hiding in the survey results. If the dominant model is going to be supervised autonomy, then the supervision has to happen somewhere, and that somewhere needs to be where the humans already are. In most engineering organisations that is Slack.

Putting the agent's output and its approval gates in the incident channel solves several problems at once. The evidence and the hypothesis land in the same thread as the human discussion, so the record of the incident is complete rather than split across a chat tool and a separate console. Approvals happen in the place people are already looking, which is the difference between a two second decision and a two minute context switch. And every responder sees what the agent proposed and what a human decided, which is how a team builds calibrated trust rather than blind trust or blanket scepticism.

This is the design philosophy behind Slack-native on-call tooling generally, and it is why Pagerly keeps schedules, escalation, incident channels and approvals inside Slack rather than behind another login. When the question shifts from what the agent knows to who authorised what, the audit trail and the conversation should live in the same place. An approval that happened in a separate console is an approval that most of your responders will never see.

Keep the human escalation path intact

One failure mode worth naming: teams sometimes let an agent absorb the first few minutes of an incident and quietly delay the human page while it investigates. That is a mistake. Page the human on the normal schedule and let the agent work in parallel. If the agent resolves it before the human finishes reading, excellent, the human acknowledges and closes. If it does not, you have lost nothing. Autonomy should shorten incidents, not shift when the clock starts.

Metrics that tell you whether the agent is actually helping

Mean time to resolution is the metric everyone quotes and the easiest one to fool yourself with, because an agent that is fast and wrong can look good on a monthly average while making individual severe incidents worse. A more honest set:

Hypothesis precision. Of the incidents where the agent named a root cause, what fraction matched the cause in the final postmortem? Track this separately for each severity level.
Time to first useful fact. How long between page and the first piece of context a responder actually used. This captures the value of level 1 enrichment, which is where most of the early return lives.
Action reversal rate. What fraction of agent actions were undone by a human within the same incident. A rising number means the ladder has been climbed too fast.
Escalation quality. When the agent gave up and escalated, did it hand over a useful state, or did the human start from zero?
Toil recovered. Hours of overnight and weekend response avoided. Google's SRE practice caps operational toil at fifty percent of an engineer's time in its Site Reliability Engineering book, and that budget is the real thing you are trying to protect.

Watch delivery stability alongside these. A 2026 preprint on the productivity and reliability trade off examined DORA data and reported that increases in AI adoption were associated with measurable decreases in delivery stability. Automating the response to incidents does not help if the rate of incidents rises faster.

What to do in the next thirty days

If you want to move on this without betting your availability on it, a reasonable sequence looks like this. In week one, write down your failure class inventory: the ten alert types that page most often, with their typical cause and typical remediation. This document is valuable on its own and most teams do not have it.

In week two, put an agent at level 1 on the three noisiest of those classes and let it enrich only. Measure time to first useful fact. In weeks three and four, review the transcripts as a team, pick the single failure class where the agent was consistently right, and promote just that one to level 3 with a named approver and a logged action. Set the demotion trigger before you turn it on. Then stop and let it run for a month before touching anything else.

The organisations that get value from agentic incident response over the next year will not be the ones that granted the most authority fastest. They will be the ones that granted authority in small, reversible increments and kept a clear record of who decided what. The survey data is unambiguous that this is where practitioners want to land, and the operational reality of cascading failures says they are right to want it.

The takeaway

Agentic incident response is here and it is already in production at most large organisations, but the meaningful design question has shifted from capability to authority. Ninety eight percent of enterprise leaders will let an agent change production under the right conditions, and only 8.5 percent want it closing incidents unsupervised. That is not indecision. It is a fairly precise statement of what good looks like: an agent that investigates aggressively, acts narrowly, shows its work, and escalates to a human who is already awake and already in the channel.

Build the ladder, define the rungs, keep the kill switch obvious, and run the whole thing where your responders already talk. The teams that do this will get the toil reduction without the 3am surprise. The teams that flip a single autonomy switch and hope will eventually learn why the survey respondents were so careful.