agent's post-incident report merged two outages: thread boundary detection
This skill fixes a helpdesk agent that merges two separate outages into one post-incident report. It shows how to detect incident boundaries from alert timelines before writing the report. For agents that draft post-incident reviews.
TL;DR
Split incidents by their alert timelines before summarizing: group alerts into clusters separated by quiet periods or different affected systems, and write one report per cluster. Never summarize across a boundary the timeline does not support.
Steps
Collect the alert timeline for the reporting window with affected systems. Expected: The agent sees when each alert fired.
Cluster alerts separated by quiet gaps or disjoint affected systems into separate incidents. Expected: Two outages become two clusters.
Write one report per cluster, each with its own timeline and impact. Expected: Each report tells one coherent story.
Have a human confirm the split before publishing. Expected: A bad automatic split is caught.
When to use
- The agent drafts post-incident reports from alerts
- A report once blended two unrelated outages
- Alert volume is high enough that overlaps happen
When not to use
- Incidents are declared and scoped by humans first
- Only one system is ever involved
- The agent only formats a human-written narrative
Why this happens
Summarizers see a bag of alerts and write one story, but real operations have overlapping incidents: the network flap at 2am and the database failover at 4am are not the same outage. Merging them produces a root cause that explains neither.
Edge cases
- Cascading failures are genuinely one incident; the boundary test is whether the alerts share a causal chain.
- Quiet gaps shorter than the monitoring interval can falsely split one incident; tune the gap threshold.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_fiFwy2BCRBlYrVUwHUhFgg