Examples
PagerDuty incident loop
Runtime flow
| Stage | Role in this pattern |
| --- | --- |
| Provider | Perplexity Sonar (ToolAdapter) — grounded research + citations for classification input |
| Loop + Guards | governed-incident-response (or equivalent) — risk tier, human_review, blocked without alert |
| Channel | On-call human in PagerDuty UI / escalation policy — approves escalate vs. auto-path |
| Integration | PagerDuty Events API v2 — trigger only when loop reaches alerting (with audit_ref in custom_details) |
| Evidence | Sonar citations hash, classification rationale, human decision, alert payload reference |
1Provider (Sonar research)2 ↓3Loop + Guards (classify, gate, human_review)4 ↓5Channel (on-call human decision)6 ↓7Integration (PagerDuty alert)8 ↓9Evidence (tamper-evident trail)What this teaches
- Governance — Neither Sonar nor PagerDuty alone produces a compliance-grade decision record; the loop binds them.
- Deterministic boundaries —
blockedand low-tier paths do not emit PagerDuty alerts; guards enforce that. - Human escalation —
human_reviewtimeout paths escalate through policy, not model discretion. - AI assistance — Provider supplies research; it does not page on-call by itself.
What this is not
- “AI incident bot” that posts to PagerDuty without loop state.
- A replacement for PagerDuty scheduling — Loop Engine governs when alerting is allowed.
- A claim that every catalog loop id is pre-installed in your account — register definitions per environment.
Runnable scope
| Piece | OSS today |
| --- | --- |
| Loop definition + engine.transition | Yes — @loop-engine/sdk |
| Sonar + PagerDuty adapters | Yes — see integration guide |
| End-to-end hosted template + tenant connectors | Loop Engine Cloud / operator setup |