PagerDuty SRE Agent: Setup Virtual Responder dan Guardrail

Yang menarik perhatian saya adalah satu kalimat di post rilis Spring 26 PagerDuty: SRE Agent nantinya bisa ditambahkan langsung ke schedule dan escalation policy. AI yang duduk di rota on-call itu perubahan kategori, bukan sekadar chatbot di Slack, karena rota adalah tempat akuntabilitas ditetapkan.

Saya belum menjalankannya: jalur escalation policy masih early access dan saya tidak punya akun PagerDuty Advance. Post ini adalah pembacaan teliti atas release post, halaman support, entri changelog, dan dokumentasi MCP PagerDuty, dengan setiap angka dan flag diambil dari halaman yang saya fetch sendiri. Kalau halamannya saling berbeda, atau ada kontrol yang dijanjikan tapi tidak terdokumentasi, saya sebutkan.

Apa yang dirilis PagerDuty, dan di mana halamannya saling berbeda

Post rilis Spring 26 memperkenalkan SRE Agent sebagai virtual responder, agen AI yang bertindak sebagai first line of defense. Ia mengumpulkan sinyal dari seluruh stack untuk mendeteksi, triage, dan mendiagnosis incident sebelum mem-page manusia, serta mengingat incident lama, diagnostik, dan isi knowledge base. Post yang sama menyebut Cursor MCP dan plug-in Claude Code sudah generally available, dan fitur agent datang dalam beberapa bulan ke depan.

Jebakannya ada di status. Post Spring tidak memberi tanggal, press release mencantumkan early access virtual responder untuk Q2 2026 dan fully autonomous responder untuk H2 2026, lalu post PagerDuty bertanggal 5 Agustus 2026 memecah fitur menjadi bagian GA dan early access. Tabel di bawah memakai halaman terbaru untuk tiap baris, cara paling aman membaca vendor yang roadmap-nya bergeser antar post.

Dua pintu masuk: incident workflow dan escalation policy

PagerDuty menjelaskan dua jalur pemicu. Incident workflow bisa mengaktifkan agent begitu incident terpicu, atau saat kriteria seperti priority atau severity terpenuhi; post Mei 2026 menyebut semuanya bisa terjadi sebelum responder meng-acknowledge incident. Escalation policy adalah jalur yang dimaksud headline rilis Spring, dan panduan support menyebut setiap incident yang mencapai level terkonfigurasi memicu agent, tanpa penugasan per incident.

Perbedaan itu keputusan desain pertama. Filter severity yang terdokumentasi hanya ada di jalur workflow, bukan di toggle escalation policy. Pembacaan saya, bukan rekomendasi resmi: kalau ingin agent hanya untuk incident serius, mulai dari workflow berbasis priority, dan sisihkan jalur escalation policy untuk policy yang memang hanya membawa incident yang ingin diselidiki. Post Spring juga menyebut schedule, tapi panduan support yang saya temukan hanya mengonfigurasi policy.

Menambahkan agent ke escalation policy, langkah demi langkah

Setup-nya singkat. Panduan support menyebut agent itu Paige dan entri changelog yang sepasang menyebut fiturnya SRE Agent on escalation policies, jadi saya anggap keduanya sama; saya tidak menemukan halaman yang mengumumkan pergantian nama. Anda butuh Paige aktif untuk akun dan role Manager atau Admin, karena mengedit escalation policy memerlukannya.

1. Buka escalation policy yang ingin dikonfigurasi.
2. Pilih escalation level tempat agent harus mulai bekerja.
3. Aktifkan toggle berlabel Trigger Paige for incidents in this escalation policy.
4. Pilih tujuan hasil temuan: agent side panel di PagerDuty, Slack, atau keduanya.
5. Save. Setiap incident yang mencapai level itu kini otomatis memicu agent.

Dua detail dari panduan lebih penting daripada kliknya. Agent terpicu segera setelah incident dibuat, paralel dengan responder on-call di level itu, dan berjalan bersamaan dengan manusia di policy: tidak ada yang menunggu yang lain. Output Slack masuk ke channel incident khusus jika ada, kalau tidak ke channel tim atau service tempat notifikasi diposting.

Permissions dan approve-before-act: apa yang terdokumentasi dan apa yang tidak

Kontrol yang paling ingin saya verifikasi adalah yang dijanjikan post rilis Spring: admin bisa memutuskan apakah agent menjalankan remediation yang direkomendasikannya atau menunggu approval. Saya tidak menemukan halaman pengaturannya. Panduan support mendaftar apa yang dikerjakan agent, yaitu meninjau payload, mengecek bagaimana incident serupa diselesaikan, dan query integrasi terhubung untuk log dan runbook, tapi tidak menyebut pengaturan act-or-wait.

Jadi saya akan mendesain seolah klik manusia adalah satu-satunya approval gate, karena hanya itu yang benar-benar ditunjukkan sebuah halaman. Agent merekomendasikan workflow, responder menjalankannya, dan apa pun yang bisa ditulis oleh connector berpotensi diarahkan ke sana. Otorisasi connector dengan kredensial read-only dan pertanyaan act-or-wait sebagian besar terjawab sendiri.

Cursor dan MCP server PagerDuty

Post rilis Spring menyebut plug-in Cursor sudah generally available dan memungkinkan Cursor menarik data PagerDuty serta melakukan aksi seperti on-call lookup, service management, dan incident history, sehingga developer bisa bertanya soal kondisi operasional sebelum shipping. Di bawahnya ada MCP server PagerDuty. Repository GitHub self-hosted sudah deprecated dan di-archive, dengan pengembangan pindah ke hosted server di mcp.pagerduty.com untuk akun US dan mcp.eu.pagerduty.com untuk akun EU.

Nama tool menyandikan risikonya. Tool baca berawalan browse_ (browse_incidents, browse_services, browse_schedules, browse_escalation_policies, dan lainnya) dan tool tulis berawalan manage_ (manage_incidents bisa membuat, mengubah, menambah note, menambah responder, dan memulai workflow; manage_schedules bisa membuat override; manage_teams bisa menghapus). Server self-hosted lama hanya mengekspos tool baca kecuali dijalankan dengan --enable-write-tools. Panduan hosted tidak menjelaskan flag setara dan menyebut tool filtering tidak tersedia di sana, jadi Scoped OAuth client adalah cara membatasi apa yang berhasil.

Hosted server butuh Advanced Permissions di akun dan User API key atau OAuth client. Auth API key memakai header Authorization berbentuk Token token diikuti key Anda; token OAuth dikirim sebagai header Bearer; Dynamic Client Registration tidak didukung.

Claude Code: /risk-score sebelum commit

Plug-in Claude Code menjalankan bagian loop yang berbeda. Saat developer menjalankan /risk-score, Claude mengorelasikan git diff dengan data incident PagerDuty 90 hari dan mengembalikan risk score beserta rekomendasi sebelum kode di-commit, berdasarkan tipe file berisiko tinggi, cakupan perubahan, dan irisan dengan area incident lama. Listing marketplace menambahkan skor 0-5, konteks incident, dan sinyal risiko struktural, serta menyebut PagerDuty API key diperlukan. Ia mencoba mencocokkan nama repository ke service PagerDuty secara otomatis, atau membiarkan Anda memilih, lalu menyimpan mapping-nya.

Inputnya adalah perubahan yang belum di-commit, jadi ia menilai hal yang akan Anda lakukan, bukan riwayat yang sudah dikirim. Itu membuatnya bagian rilis Spring yang paling murah dicoba: read-only secara desain, tidak perlu mengubah escalation policy, dan memberi gambaran langsung bagaimana PagerDuty memetakan service ke kode. Halaman marketplace menampilkan tombol install tanpa perintah install, jadi saya tidak menuliskannya.

Di mana ini bermasalah: lima trade-off yang perlu diperhitungkan

Pertama, agent tidak mengambil page dari manusia. Panduan menyatakan ia tidak menggantikan langkah di escalation chain dan tidak menunda paging. Kalau tujuannya mengurangi page jam 3 pagi, virtual responder di level satu tidak akan mewujudkannya sendirian; yang berubah adalah seberapa banyak yang diketahui manusia saat membuka incident.

Kedua, status rilis tidak stabil antar halaman PagerDuty sendiri. Soal agent-to-agent MCP, post rilis Spring menyebut early access dengan GA pada akhir H1 FY27, sementara press release mencantumkan kapabilitas agent-to-agent MCP generally available di H1 2026. Saya tidak menyelesaikan perbedaan itu, dan itulah intinya: patok rencana Anda pada halaman support terbaru dan cek ulang sebelum rollout.

Ketiga, fitur escalation policy masih early access dan panduannya menandainya subject to change. Keempat, repository MCP self-hosted sudah di-archive, jadi tutorial yang menyuruh menjalankan uvx pagerduty-mcp dengan API key menunjuk ke rute yang deprecated. Kelima, agent hanya tahu apa yang diberikan connector dan memory-nya; tim tanpa log terhubung akan mendapat triage yang terdengar yakin tapi hanya berdasar payload dan incident lama.

Yang dikerjakan hari Senin

Rollout yang berani saya pertahankan, berurutan dari blast radius kecil ke besar:

1. Cek apakah akun ada di PagerDuty Advance dan, jika jalur escalation policy penting, ajukan early access di pagerduty.com/early-access.
2. Pilot pemicu workflow dulu, berbasis priority atau severity, karena sudah generally available dan satu-satunya jalur dengan filter kriteria terdokumentasi.
3. Hubungkan observability lewat Connectors dengan kredensial read-only, lalu pakai team-level permissions untuk membatasi AI ke satu tim.
4. Beri developer setup MCP read-only dan plug-in /risk-score; jauhkan klien MCP berkemampuan tulis dari config bersama.
5. Baru kemudian tambahkan agent ke level satu policy satu tim dengan output Slack, dan bandingkan temuannya dengan temuan manusia pada beberapa incident sebelum diperluas.

Snippet di bawah adalah titik awal read-only: config Cursor level project dari dokumentasi server yang di-archive, hosted server dengan API key di Claude Code seperti dijelaskan panduan MCP, dan satu flag yang menyalakan write di server lama.

# 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

Aturan yang saya bawa dari sini: perlakukan virtual responder sebagai peserta on-call baru yang memegang kredensial, bukan toggle fitur. Batasi ke satu tim, beri connector read-only, mulai dari workflow sebelum policy, dan biarkan setiap tool write hanya dijalankan manusia yang memilihnya. Halaman PagerDuty sendiri menunjukkan guardrail-nya masih dibangun.