Incident Relay

A WebMCP-native SRE workbench where agents investigate incidents and stage mitigations, while an explicit operator approval gate prevents unsafe execution.

Comment

Inspiration

AI agents are becoming very good at reading telemetry, correlating deployments, and proposing fixes. Production incident response still has a hard boundary, though: investigating can be autonomous, but executing a mitigation must remain accountable. We built Incident Relay to show what an agent-native SRE workflow looks like when that boundary is part of the product instead of an instruction in a prompt.

What it does

Incident Relay is a fully client-side incident response workbench built around a simulated checkout regression. A checkout-api v1.8.43 deployment raises p95 latency from 352 ms to 2.84 seconds and the 5xx error rate from 0.4% to 8.7%.

The interface brings the complete response context into one place: service health, SLO charts, alerts, logs, deployment diffs, diagnostics, an evidence timeline, a staged rollback, and an agent-drafted postmortem.

The page registers seven typed WebMCP tools:

  • get_incident_summary
  • query_logs
  • compare_deployments
  • run_diagnostic
  • stage_mitigation
  • execute_approved_mitigation
  • draft_postmortem

Together they support the full flow: detect → investigate → stage mitigation → operator approval → execute → recover.

The approval boundary

The most important part of the project is what the agent cannot do. There is no approval tool. stage_mitigation can prepare the exact rollback proposal, but only the visible UI can write an operator-ui approval. Execution then revalidates the current incident phase, the staged mitigation ID, the approved mitigation ID, and the approval source. Agent-supplied fields such as approved: true are rejected, and replay attempts fail after execution begins.

This makes the human confirmation a real application invariant rather than a conversational convention.

How we built it

The workbench uses React 19, TypeScript, and Vite. Recharts renders the SLO and recovery timeline, while a pure incident state machine owns the six legal phases. A shared controller connects React's useSyncExternalStore to the WebMCP handlers, so agent actions immediately update the visible UI.

The WebMCP adapter wraps document.modelContext.registerTool() with official TypeScript declarations, strict Zod runtime schemas, JSON-serializable results, secure-context feature detection, and AbortSignal-based cleanup. Unsupported browsers receive a clear notice while the normal UI remains fully usable.

Vitest covers state transitions, input validation, immutable snapshots, approval provenance, exact plan matching, registration cleanup, and replay prevention. GitHub Actions runs the suite and deploys the static app to GitHub Pages.

Challenges we ran into

The hardest design problem was separating staging from authorization without creating a token that an agent could manufacture. We solved it by keeping approval out of the WebMCP surface entirely and tying execution to live, frozen application state.

We also had to treat tool input as untrusted even when a browser advertises JSON Schema. The browser schema helps agents call tools correctly, but Zod validation inside every handler remains the security boundary.

Finally, WebMCP support is still browser-dependent, so the demo needed to be useful both with and without an agent connection. The same state machine now powers both paths.

Accomplishments that we're proud of

  • Seven WebMCP tools registered and verified in the live Chrome build
  • A human approval gate an agent cannot bypass or replay
  • A live activity feed populated only by genuine WebMCP invocations
  • A polished responsive English workbench with no backend or paid APIs
  • 45 passing tests covering workflow and security invariants
  • A public, MIT-licensed repository and reproducible GitHub Pages deployment

What we learned

Agent-native UX is not a chat box added to an existing dashboard. It means exposing meaningful, typed actions while making authority boundaries visible and enforceable. We also learned that good tool descriptions, runtime schemas, state provenance, and lifecycle cleanup matter as much as the UI when a page becomes an agent surface.

What's next

The MVP deliberately uses deterministic data. A production version could add read-only adapters for observability platforms, signed deployment-provider actions, multi-operator approval, and persisted audit trails while keeping the same approval invariant and WebMCP contract.

Built With

Share this project:

Updates

Submission history