PagerDuty SRE Agent vs. Resolve AI: Which Parts of On-Call and Incidents Do You Need AI For?

The cost of on-call starts with volume. Production-scale deployments generate thousands of alerts a month, most of them noise. But engineers have no way of understanding noise from the signal until it responds. Even small alerts pull engineers away, and serious ones pull senior engineers off roadmap work for hours, with follow-ups filling their time for weeks to come. This is never fully budgeted within an engineering org, but it all comes out of engineering headcount.

AI agents offer to hand back some of that time. PagerDuty and Resolve AI make the offer in different ways, and the difference is why each was built. PagerDuty is an AI ops platform for incident management. It was built to run the process around failures, so alerts become managed incidents, the right people get involved, and the fixes you've already automated get run, with an SRE Agent now working inside that process. Resolve AI was built for the investigation itself, working out what actually broke, showing the evidence, and helping fix it.

Working out which one you need, or when the answer is both, starts with knowing what to ask of them.

Three questions to ask any agent

When a vendor says “we have an agent,” the pitch usually consists of a list of features. Really, you need to know not what the agent is, but what the agent does:

• Coverage: how many of your alerts and incidents does the agent actually work on?
• Autonomy: how much of the work does it do without a human driving?
• Quality: is it right often enough that you'd act on its output?

Those questions don't have one answer per product. They have one answer per stage of work, because every alert and incident moves through the same four stages:

1. Triage. Something fires, or two hundred things fire at once, and someone decides what's real, how bad it is, and whether it becomes an incident. The work is short per alert; at volume, the cost is the noise itself and the interruptions it generates.
2. Investigation. Someone works out what's affected, what changed, and which change caused this symptom, along with the path, by combing through dashboards, logs, traces, deployment history, and the memory of whoever knows that part of the system. This is the open-ended cluster: twenty minutes or a full day, with more senior engineers pulled in the longer it runs.
3. Remediation. Someone picks a fix, gets it approved, executes it, and confirms the problem is actually gone. It's fast when the diagnosis was right, and for failures the team has seen before, the fix often already exists as a script or a runbook.
4. Coordination and close. Responders get mobilized, stakeholders get updates, the record gets kept, and a postmortem gets written. This is steady, predictable work, and the first cluster software learned to automate.

Ask the three questions across those stages, and the pattern shows up quickly. Coordination scores high on all three, and has for years. Triage automates well because each decision is small, and remediation is fast once the diagnosis is right. The open stage is investigation: it's where the hours concentrate, and it's the hardest for AI, because it requires understanding your system rather than your process.

Response agents and investigation agents

A response agent treats the alert-to-resolution pipeline as the thing to run. Its raw material is operational record: which alerts cluster together, who owns which service, what was done last time, and which automation fixed this before. Applied end to end, the pipeline looks like this:

• Incoming events get deduplicated, grouped, and suppressed, so a storm of alerts becomes a handful of incidents.
• What remains is routed to service ownership and escalated until a human acknowledges it.
• The agent mobilizes responders with context attached, recommends next steps from what worked before, and keeps comms and the record running.
• When the failure matches one the team has encoded, it selects the right automation and runs it with approval.
• Each incident feeds back into memory, so the next similar one starts further along.

When judged against the three questions, the pipeline scores well where process dominates. It covers everything that enters it, runs with little human input, and has checkable output. When it does investigate, it works outward from the incident record, the alerting service, and the data associated with them. Its picture of the system reaches only as far as each investigation digs.

An investigation agent treats the system behind the alert as the thing to understand. It needs a current picture of production, meaning the code, the deploys, the infrastructure, the telemetry, and the dependencies between services, because that's where root cause actually lives. Working from that picture:

• It forms competing explanations for what changed and tests them against the evidence.
• It follows the failure through the dependency chain rather than stopping at the service that raised the alert.
• It arrives with a conclusion an engineer can check: the change, the path from change to symptom, and the evidence for each step.
• It proposes the fix that follows from its findings.

Coverage depends on where it sits; on the alert stream, it can work everything, not only declared incidents. Autonomy runs deep through the investigation and stops at the fix, which waits for approval. Quality rests on the model and harness doing the work, which is why the evidence comes attached.

That's the split between PagerDuty and Resolve AI. PagerDuty is the pipeline. The Operations Cloud runs detection, on-call, event orchestration, incident workflows, status pages, and automation, and its SRE Agent works inside that pipeline, with its memory scoped to each PagerDuty service. Resolve AI is anchored to the system rather than the service that alerted. It maintains a continuously updated model of production and runs its agents against it, on the alert stream and inside incidents. The cleanest comparison is to follow one bad deploy through each.

An investigation using PagerDuty alone

Say a deploy goes out and a downstream service starts throwing errors. On PagerDuty, the path looks like this:

1. Monitoring floods PagerDuty with events. Event orchestration deduplicates and groups them into one incident, a stage PagerDuty claims can cut alert noise by up to 91%.
2. Routing pages the on-call engineer for the affected service, and escalation moves the page up the chain if nobody acknowledges. Delivery runs across phone, SMS, push, and email.
3. The SRE Agent picks the incident up with PagerDuty's context attached: the service, its dependencies, recent change events, and related incidents. It works several root-cause hypotheses in parallel, drawing on service memory such as runbooks and past incident summaries, and engineers can steer it from the Operations Console, Slack, or Teams. That memory is scoped per service, which is what makes the agent fast within a service and thin when the cause lies in another.
4. If the failure matches an encoded fix, the agent recommends the right Incident Workflow or Runbook Automation job, explains why, and runs it once someone approves. That's diagnosis to executed fix without leaving the platform.
5. Mobilization, stakeholder updates, status pages, and the postmortem run through the same platform for the incident's whole life.

So with PagerDuty alone, the pipeline is handled at high volume, and failures you've seen before go from alert to executed, pre-approved fix with very little human effort. On investigation, the SRE Agent gives responders a head start inside the incident. When the failure is novel, when the cause sits outside the connected tools, or when the fix was never encoded, the work comes back to your engineers.

The same incident with Resolve AI

Now run the same bad deploy through Resolve AI, with paging staying wherever it lives today:

1. The alert lands on Resolve AI's on-call agent, which assesses it at the depth configured for that alert type, anywhere from a quick check to a full investigation. That includes the long tail of alerts that never become incidents.
2. An agent team picks it up: investigators chase competing hypotheses in parallel across code, infrastructure, and telemetry, and a verifier tests the leading explanation against production evidence.
3. The output is a causal timeline: the deploy, the path from that change to the symptom through the dependency chain, and the evidence for each step. Resolve AI's internal evaluations put root-cause quality at more than double its earlier architecture.
4. The proposed fix follows from the findings, whether that's silencing the alert, reverting the commit, opening a remediation PR, or running a GitHub Action. Every action waits for human approval, and the models never touch write APIs directly; a separate execution engine runs what's approved.
5. Findings and summaries land in the Slack or Teams channel where the response is happening, while paging, escalation, status pages, and the incident record stay in the existing stack.

This is the deployment behind Resolve AI's published numbers: Coinbase cut investigation time by 72% and reached a likely root cause in under 10 minutes; Zscaler runs root-cause investigations 75% faster with over 30% fewer engineers per incident; and Salesforce reports roughly 60% lower MTTR. Teams that can't hand credentials to a vendor cloud run Resolve AI's Satellite component inside their own infrastructure, with redaction applied before anything leaves it.

Running PagerDuty and Resolve AI together

PagerDuty and Resolve AI have a documented integration. Combining them is a simple 2-minute setup with a webhook, where PagerDuty keeps the pipeline, and Resolve AI takes care of the investigation:

1. PagerDuty ingests events, applies event orchestration, opens incidents, and pages responders as it always has.
2. The incident fires a webhook that automatically launches a Resolve AI investigation, with alert details pulled via the PagerDuty API where needed.
3. Resolve AI's findings, timeline, and proposed actions arrive in the incident's channel while PagerDuty runs escalation, communication, and status through to resolution.
4. Encoded fixes continue to run through PagerDuty's approved workflows, and fixes for novel failures emerge from Resolve AI's investigation, each with an engineer's approval.

Choosing between them

Go with PagerDuty alone if your main problem is alerting the right person at the right time. It won't investigate beyond what PagerDuty can see, meaning the incident and the tools you've connected to it, and if the fix was never automated, it can't run one.

Go with Resolve AI alone if your main problem is investigation time. It works out what broke, shows the evidence, and proposes the fix. It doesn't do paging or the incident process, so that stays with whatever you run today.

Run both if you want each job done by the thing built for it: PagerDuty pages and coordinates, Resolve AI investigates. The integration is a webhook. The one decision to make up front is which agent gets to propose fixes.

So which parts do you need AI for? For most teams, the response side is already well handled. What's still costing senior engineers days is the investigation, and that's the problem Resolve AI was built to solve.

Book a demo to see how Resolve AI takes an alert to a verified root cause.