PagerDuty SRE Agent: Virtual Responder Setup and Guardrails

The pitch that caught my attention was a single sentence in PagerDuty's Spring 26 release post: you will be able to add the SRE Agent directly to schedules and escalation policies. An AI sitting in the on-call rota is a different category of change from a chatbot in Slack, because a rota is where accountability is defined.

I have not run this: the escalation-policy path is early access and I do not have a PagerDuty Advance account. This post is a close reading of PagerDuty's release posts, support pages, changelog entries and MCP documentation, with every figure and flag taken from a page I fetched myself. Where the pages disagree, or where a control is promised but not documented, I say so.

What PagerDuty shipped, and where its own pages disagree

The Spring 26 release post introduces the SRE Agent as a virtual responder, an AI agent acting as your first line of defense. It gathers signals across your stack to detect, triage and diagnose an incident before paging a human, and it recalls past incidents, diagnostics and knowledge base content. The same post says Cursor MCP and the Claude Code plug-in are generally available, and that the agent features arrive over the next several months.

Status is the trap. The Spring release post gives no dates, the press release lists virtual responder early access for Q2 2026 and a fully autonomous responder for H2 2026, and a PagerDuty post dated 5 August 2026 splits the surface into generally available and early access pieces. The table below uses the newest page for each row, which is the safest way to read a vendor whose roadmap moves between posts.

Two ways in: incident workflows and escalation policies

PagerDuty describes two trigger paths. Incident workflows can engage the agent the moment an incident triggers, or when criteria such as priority or severity are met; the May 2026 post says this can all happen before a responder acknowledges the incident. Escalation policies are the path the Spring release headline refers to, and the support guide says every incident that reaches the configured level triggers the agent, with no per-incident assignment.

That difference is the first design decision. The only severity filtering I could find documented sits on the workflow path, not on the escalation-policy toggle. My reading, not a documented recommendation: if you want the agent only on serious incidents, start with a workflow keyed on priority, and reserve the escalation-policy path for a policy that already carries only the incidents you want investigated. The Spring post also mentions schedules, but the support guide I found configures policies only.

Adding the agent to an escalation policy, step by step

The setup is short. The support guide calls the agent Paige and the matching changelog entry calls the feature the SRE Agent on escalation policies, so I treat them as the same thing; I did not find a page announcing a rename. You need Paige enabled for the account and a Manager or Admin role, because editing escalation policies requires one.

1. Open the escalation policy you want to configure.
2. Select the escalation level where the agent should engage.
3. Turn on the toggle labelled Trigger Paige for incidents in this escalation policy.
4. Choose where findings go: the agent side panel in PagerDuty, Slack, or both.
5. Save. Every incident that reaches that level now triggers the agent automatically.

Two details from the guide matter more than the clicks. The agent triggers immediately after the incident is created, in parallel with that level's on-call responder, and it runs concurrently with the humans in the policy: neither blocks waiting on the other. Slack output goes to the incident's dedicated channel if one exists, otherwise to the team or service channel where the notification was posted.

Permissions and approve-before-act: what is and is not documented

The control I most wanted to verify is the one the Spring release post promises: admins can decide whether the agent acts on its recommended remediations or waits for approval. I could not find a settings page for it. The support guide lists what the agent does, which is review the payload, check how similar incidents were resolved and query connected integrations for logs and runbooks, but it names no act-or-wait setting.

So I would design as if the human click is the only approval gate, because it is the only one a page actually shows. The agent recommends a workflow, the responder runs it, and anything the connectors can write to is something the agent could in principle be steered toward. Authorise connectors with read-only credentials and the act-or-wait question mostly answers itself.

Cursor and the PagerDuty MCP server

The Spring release post says the Cursor plug-in is generally available and lets Cursor pull PagerDuty data and take actions such as on-call lookups, service management and incident history, so developers can ask about operational posture before shipping. Underneath it is PagerDuty's MCP server. The self-hosted GitHub repository is deprecated and archived, with development moved to a hosted server at mcp.pagerduty.com for US accounts and mcp.eu.pagerduty.com for EU accounts.

The tool names encode the risk. Read tools are prefixed browse_ (browse_incidents, browse_services, browse_schedules, browse_escalation_policies and others) and write tools manage_ (manage_incidents can create, update, add notes, add responders and start a workflow; manage_schedules can create overrides; manage_teams can delete). The old self-hosted server exposed only read tools unless started with --enable-write-tools. The hosted guide describes no equivalent flag and says tool filtering is not available there, so a Scoped OAuth client is how you limit what succeeds.

The hosted server needs Advanced Permissions on the account and either a User API key or an OAuth client. API-key auth uses an Authorization header of the form Token token followed by your key; OAuth tokens go as a Bearer header; Dynamic Client Registration is not supported.

Claude Code: /risk-score before you commit

The Claude Code plug-in runs a different part of the loop. When a developer runs /risk-score, Claude correlates the git diff with 90 days of PagerDuty incident data and returns a risk score with recommendations before the code is committed, based on high-risk file types, change scope and overlap with past incident areas. The marketplace listing adds a 0-5 score, incident context and structural risk signals, and says a PagerDuty API key is required. It tries to match the repository name to a PagerDuty service automatically, or lets you pick one, and caches the mapping.

The input is uncommitted changes, so it reviews the thing you are about to do, not the history you already shipped. That makes it the cheapest piece of the Spring release to trial: it is read-only by design, needs no escalation-policy change, and gives you a first-hand feel for how PagerDuty maps a service to code. The marketplace page shows an install button but no install command, so I give none.

Where this breaks: five trade-offs to price in

First, the agent does not take the page off a human. The guide states it does not replace a step in the escalation chain or delay paging. If the goal is fewer 3 a.m. pages, a virtual responder at level one will not deliver that on its own; what it changes is how much a human knows when they open the incident.

Second, release status is unstable across PagerDuty's own pages. On agent-to-agent MCP, the Spring release post says early access with general availability by the end of H1 of FY27, while the press release lists agent-to-agent MCP capabilities as generally available in H1 2026. I did not resolve that, which is the point: pin your plan to the newest support page and recheck before a rollout.

Third, the escalation-policy feature is early access and the guide marks it subject to change. Fourth, the self-hosted MCP repository is archived, so any tutorial that tells you to run uvx pagerduty-mcp with an API key is pointing at the deprecated route. Fifth, the agent only knows what its connectors and memory give it; a team with no logs connected will get a confident-sounding triage built on a payload and past incidents alone.

What to do on Monday

A rollout I would be comfortable defending, in order of increasing blast radius:

1. Check whether the account is on PagerDuty Advance and, if the escalation-policy path matters, request early access at pagerduty.com/early-access.
2. Pilot the workflow trigger first, keyed to priority or severity, because it is generally available and the only path with a documented criteria filter.
3. Connect observability through Connectors with read-only credentials, then use team-level permissions to scope AI to one team.
4. Give developers the read-only MCP setup and the /risk-score plug-in; keep any write-capable MCP client out of shared configs.
5. Only then add the agent to level one of one team's policy with Slack output, and compare its findings with what the human found for several incidents before widening.

The snippets below are the read-only starting points: the project-level Cursor config from the archived server's documentation, the hosted server with an API key in Claude Code as the MCP guide describes, and the one flag that turns writes on in the old server.

# Wrong: a write-capable client in a shared config. manage_incidents can
# create incidents, add notes, add responders and start workflows.
# Right: read-only. Without --enable-write-tools the old self-hosted
# server exposes only read tools (archived repo, kept for reference).
# ~/.cursor/mcp.json, or .cursor/mcp.json in the project root
{
  "mcpServers": {
    "pagerduty": {
      "command": "uvx",
      "args": ["pagerduty-mcp"],
      "env": {
        "PAGERDUTY_USER_API_KEY": "your-api-token-here"
      }
    }
  }
}

# Only with a reason you can write down: writes enabled.
#   "args": ["pagerduty-mcp", "--enable-write-tools"]

# Hosted server, API-key auth, as the PagerDuty MCP guide describes.
# US accounts: mcp.pagerduty.com. EU accounts: mcp.eu.pagerduty.com.
# The header value is Token token=<key>, not Bearer.
export PAGERDUTY_API_KEY="<a key scoped to what you will let the agent read>"

claude mcp add-json pagerduty '{"type":"http","url":"https://mcp.pagerduty.com/mcp","headers":{"Authorization":"Token token=${PAGERDUTY_API_KEY}"}}'

# Then, inside Claude Code, with uncommitted changes in the working tree:
git diff --stat HEAD    # what the score will be about
/risk-score             # 0-5 score, incident context, recommendations

The rule I took from this: treat a virtual responder as a new on-call participant with credentials, not a feature toggle. Scope it to a team, give it read-only connectors, start it on a workflow before a policy, and keep every write tool a human has to choose to run. PagerDuty's own pages show the guardrails are still being built.