Building and Deploying an AI-Powered Incident Summary Generator

incident.io · Tech · 2024 · source Agentic: no · promotional bias: low · source-backed · extracted with prompt 0.5.4 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Incident response documentation

incident.io needed to keep incident summaries fresh while responders focused on mitigation, without letting AI silently write inaccurate operational status during incidents.

Constraints:

Incident summaries are the first thing newcomers read when joining an incident.
Responders often lack bandwidth to maintain summaries during mitigation.
Suggestions needed explicit human acceptance, editing, or rejection.
Customer data, OpenAI subprocessors, Slack enrichment, and zero-data retention had to be handled carefully.

Architecture

incident.io built suggested summaries using OpenAI models. The system considers the latest update, Slack conversation, prior summary, incident metadata, and prompt fixtures; forces JSON output for structured summaries; wraps provider calls in a RunPrompt interface that handles data loading, customer eligibility, prompt building, OpenAI calls, and metadata storage; and exposes accept/edit/reject feedback buttons.

Diagram confidence: explicit (topology described by the source).

flowchart LR
  responder[Responder] --> suggested-summary-ui[Suggested Summary UI]
  suggested-summary-ui --> runprompt[RunPrompt]
  runprompt --> incident-data[Incident Data]
  runprompt --> slack-api[Slack API]
  runprompt --> openai[OpenAI]
  suggested-summary-ui --> feedback-buttons[Feedback Buttons]

Drag to pan · scroll or use +/− to zoom · reconstructed from the source's described component topology

Components

Component	Role	Interacts with
`Responder`	Human incident responder reviewing summary suggestions.	`Suggested Summary UI`
`Suggested Summary UI`	Accept/edit/reject surface for AI summary suggestions.	`RunPrompt`
`RunPrompt`	Internal abstraction for eligibility, data loading, prompting, provider calls, and metadata storage.	`Incident Data`, `Slack API`, `OpenAI`
`Incident Data`	Updates, previous summary, metadata, and timeline context.	`RunPrompt`
`Slack API`	Conversation enrichment source for incident-channel messages.	`RunPrompt`
`OpenAI`	Model provider generating JSON summary suggestions.	`RunPrompt`
`Feedback Buttons`	Tracks accept, edit, and bad-suggestion outcomes.	`Suggested Summary UI`

Data flow

When an incident update is posted, the system loads incident data, Slack conversation context, and prior summary, decides whether there is enough data and whether the customer allows the feature, builds a prompt, calls OpenAI in JSON mode, stores the response/metadata, and asks a human to accept, edit, or reject the suggestion.

“This suggestion will consider your update, the conversation in the channel, and the previous summary (if there was one). You can choose to accept it as-is or apply some tweaks first.”article, stated

“* Builds the prompt and calls OpenAI * Stores the response and other metadata This means that when building a new AI feature you just need to fill out the interface and call RunPrompt. The caller does not need to concern itself with any of the admin aspects of using OpenAI.”article, stated

Why this architecture

incident.io kept a human-in-the-loop suggestion flow because acceptance data did not justify auto-updating summaries. Structured JSON output and fixture-based prompt tooling made the first AI feature more testable, while RunPrompt centralized legal, data, and provider concerns.

“This means we don’t yet have high enough conviction to auto-set the summary every time, because the majority of suggestions are not used, but we might want to consider changing the flow to make our suggestions more visible (rather than being hidden in a thread).”article, stated

“You must return the summary in JSON format, with the following keys: - problem (required): High level sentence explaining the problem that has caused the incident - impact (optional): How this problem has affected customers - causes (optional): What triggered or caused the incident”article, stated

Models used: OpenAI models · GPT · JSON mode

Scale

Half of all summary updates are now written by AI.
“Half of all summary updates are now written by AI, and we’ve had lots of requests for similar functionality across our product. ”article, stated
Suggestions are actioned 20% of the time.
“* When we suggest a summary, it gets actioned (i.e. a button is clicked) 20% of the time * When a summary is actioned: * 63% of the time it is accepted ✅ * 26% of the time it is edited 📝 * 11% of the time it is rejected ❌”article, stated
When actioned, 63% are accepted, 26% edited, and 11% rejected.
3 supporting quotes
“* When we suggest a summary, it gets actioned (i.e. a button is clicked) 20% of the time * When a summary is actioned: * 63% of the time it is accepted ✅ * 26% of the time it is edited 📝 * 11% of the time it is rejected ❌”article, stated
“* When we suggest a summary, it gets actioned (i.e. a button is clicked) 20% of the time * When a summary is actioned: * 63% of the time it is accepted ✅ * 26% of the time it is edited 📝 * 11% of the time it is rejected ❌”article, stated
“* 11% of the time it is rejected ❌ This means we don’t yet have high enough conviction to auto-set the summary every time, because the majority of suggestions are not used, but we might want to consider changing the flow to make our suggestions more visible (rather than being hidden in a thread).”article, stated
The feature launched to all customers in November.
“This gives people the benefit of an up-to-date incident summary with loads of time saved. We launched it to all our customers in November, and the reaction was better than we could have hoped for.”article, stated

Alternatives considered (roads not taken)

Automatically update summaries by default.

Rejected because: Most suggestions were not used and the team lacked enough signal for auto-setting.

“* (A) Propose a new summary and ask a human to accept or reject it * (B) Automatically update the summary but give a human the option to undo this”article, stated

Treat prompt improvement as straightforward engineering.

Rejected because: Prompt work was trial-and-error with hard-to-estimate timelines.

“Engineers build logical infrastructure. When something doesn’t work, there’s usually a logical reason behind it. But to make your results from OpenAI better, you need to improve the prompt which is the thing you ask GPT to do. This process is both a science and an art.”article, stated

Call OpenAI ad hoc from each feature.

Rejected because: RunPrompt centralizes eligibility, data loading, prompt calling, and metadata storage.

“This means that when building a new AI feature you just need to fill out the interface and call RunPrompt. The caller does not need to concern itself with any of the admin aspects of using OpenAI.”article, stated

Patterns

`human-in-the-loop-gate` (incident response)

AI proposes summaries but humans accept, edit, or reject them.

“Propose a new summary and ask a human to accept or reject it”article, stated

`structured-output-contract` (prompting)

The model must return a JSON summary with required fields.

“force GPT to provide its response in JSON”article, stated

`observability-tracing` (feedback)

Feedback buttons track acceptance and rejection rates over time.

“track % acceptance / rejection and see ourselves improving”article, stated

`privacy-preserving-processing` (provider governance)

OpenAI use required subprocessors, customer notification, and zero-data-retention negotiations.

“negotiated a super-strict zero-data retention agreement”article, stated

Tradeoffs

Automation level

Chose Suggest and ask for approval over Auto-set every summary.

Rationale: Suggestion usage and rejection rates did not justify automatic updates.

“We’d rather make AI seem like your helpful side-kick”article, stated

Output format

Chose JSON mode over Free-form summary text.

Rationale: Structured output made summaries easier to validate and consume.

“You must return the summary in JSON format”article, stated

Data enrichment

Chose Slack API enrichment on the fly over Storing all Slack messages up front.

Rationale: On-demand enrichment reduced customer-data storage concerns.

“calling the Slack API (to avoid concerns about storing customer data)”article, stated

Gotchas (what bit them)

Useful AI suggestions still may not be visible enough.

Root cause: Only 20% of suggestions were actioned, suggesting many were ignored.

Resolution: Keep feedback buttons and consider changing the flow to make suggestions more visible.

“majority of suggestions are not used”article, stated

Prompt fixes are hard to estimate.

Root cause: Small phrasing changes can matter, and daily goals may fail.

Resolution: Create fixture-based prompt tooling and leave time for trial-and-error.

“small rephrasing made a huge difference”article, stated

Third-party model providers trigger customer/legal work.

Root cause: Customers approve subprocessors and may object to data processing changes.

Resolution: Coordinate with legal and negotiate zero-data retention.

“customers approve a list of sub-processors”article, stated

Evaluation

incident.io evaluated suggested summaries with fixture-file prompt tests, accept/edit/reject feedback, action rate, customer rollout, and prompt iteration after launch.

Metrics: AI-written summary share · Action rate · Accepted rate · Edited rate · Rejected rate

“63% of the time it is accepted”article, stated

Outcomes

Half of incident summary updates are now written by AI.
Actioned suggestions are accepted as-is 63% of the time and rejected 11% of the time.
The team kept human approval because most suggestions were not used.

The source reports 50% AI-written summary updates, 20% suggestion action rate, 63% accepted, 26% edited, 11% rejected, and launch to all customers in November.

“Half of all summary updates are now written by AI”article, stated