Designing the Observability Agent for triage

Sole design owner across three release cycles. I ran discovery, prioritisation, cross-platform alignment, the designs and user journeys, and the scope containment calls that decided what shipped each quarter. Where the Integration Agent was a zero-to-one problem, this one was mine to keep improving in public — which is a different and in some ways harder job.

An operations engineer watching an end-to-end dashboard can see that a transaction failed. He usually cannot see why, and he is rarely permitted to fix it. So he escalates to an integration specialist, and the business waits — sometimes overnight — for a retry that would have taken thirty seconds. The design problem wasn't error detection. It was the handoff.

• The triage journey end to end — from a failed transaction to a verified fix, across errors spanning multiple integration nodes
• The autonomy boundary: which errors the agent may resolve on its own, which it must propose, and which it must escalate with evidence
• The discoverability rework that moved the agent out of a single monitoring page and onto the platform homepage
• Error grouping by product and error code, and the multi-error handling model behind it
• The retry experience, including the decision to show the control only when a retry configuration actually exists
• Conversation content and structure for error summaries and fix suggestions — condensing verbose model output into something a person can act on at speed
• The reasoning-trace and explainability direction now in flight for 2026

This covers shipped capability and the publicly discussed direction of the product. Internal ticket references, engineering risk detail, named colleagues and commercial figures are deliberately left out. Every diagram here is redrawn from my own working artifacts.