Post-Incident Business Impact Review: A Source-Linked Record

Agent Swarm can prepare a source-linked customer impact record after mitigation, and people validate it, decide what the impact was, and choose what to investigate next. The work is gathering what the company already recorded into one account where every statement carries its source. Then the operations owner and the engineering lead argue about the impact instead of about where a number came from.

Limits

A prepared record is not a definitive impact assessment. It reports what the available records say and where they disagree. It cannot tell you what a customer experienced if nothing recorded that experience.

The data access needs configuration. Every system the review reads, from the incident tool to the order records, needs a read path the swarm may use. Wiring those is custom work per company.

A spreadsheet may be enough for a simple case, and so may the incident tool you already use. One service, one short window, one support queue. Adding agents buys nothing there.

What follows is a proposed design assembled from two documented playbooks. Adapting them to a business-impact review needs custom configuration, and no shipped Agent Swarm feature runs a post-incident business-impact review today.

When to run the review

Three conditions, settled before the first query.

After mitigation. The record describes a window that has closed or been contained. Running it mid-incident competes with the people restoring service, and the data is still moving.

An agreed window. The operations owner and the engineering lead name the start and end of the period, in one timezone, and write down which systems define those edges. A floating window produces a record nobody can compare with the next.

A named operations owner and a named engineering lead. The operations owner knows which customer workflows matter. The engineering lead knows what the systems did and what the records can and cannot show. Two names accountable for the outcome, neither of them the agent.

Two roles, because the evidence sits in different places: operations holds the support queue and the workarounds people invented that morning, engineering holds the monitoring, the deploy history and the logs. A record built from one side alone will be confidently wrong about the other.

The steps

Five steps, in order. Each one narrows what the next may use.

1. Collect the approved inputs for the window. The incident timeline from the tool that ran the incident, service data from monitoring and logs, support records from the desk, and order or billing records if money moved while the service was degraded. Read-only access, only for the sources the two owners approved. Anything outside the window stays out, including the alert traffic that followed the fix.

2. Keep only the fields you need. Data minimization is a design decision, not a cleanup pass. A ticket's title, timestamp, channel and product area usually establish impact; the customer's message body and address usually do not. If a field is not needed to show what happened, it does not enter the record. Redact before the record exists: one that has travelled cannot be un-shared.

3. Separate confirmed facts from hypotheses. A fact is a statement a record supports. A hypothesis is a reading someone has formed, worth keeping as long as it is labelled. "Confirmations stopped reaching customers" is a fact when the monitoring timeline shows it. "Customers who could not order went to a competitor" is a hypothesis until something records it, and it is the one most likely to reach a board meeting as though it were measured.

4. List affected workflows and the evidence still missing. A workflow here means the customer's job: placing an order, booking a visit, changing an address, requesting a refund. For each one the record states what happened, what evidence exists and what does not. The gap list is a deliverable, not an apology. A gap nobody wrote down becomes a silence that reads like a clean result.

5. Write every statement with its source. Each line names the query, export, dashboard or log it came from and the window that source covers. A statement with no source appears as a hypothesis or as a gap, never as a fact.

The output is an internal record. It is not a customer message, a public post-mortem or a regulatory filing, and reusing it as one needs a person rewriting it for that audience.

Who decides

A person validates the evidence, determines the impact and picks the follow-up actions: the operations owner for the customer-facing judgment, the engineering lead for the technical one, signing the record together.

The swarm's part ends at the record. It sends no customer messages, offers no credits and closes no incident. Those actions carry commitments the company has to stand behind, and the agent that assembled the evidence is the wrong party to decide what the company owes.

The record shows the shape of the gap: which workflows have evidence, which have conflicting evidence, which have none. What to do with an unsupported workflow, investigate it, instrument it for next time, or accept it, belongs to the two people who own the consequences.

A fictional worked example

This example is fictional and illustrative. It uses no real company and reports no figures.

A company sells maintenance contracts and books service visits. Its booking service fails partway through a morning. Mitigation finishes by early afternoon. Before the first query, the two owners agree a window that runs from the start of the working day to the moment bookings resume, in one timezone, and name the three systems the record may read: the booking database, the monitoring service and the support desk. Writing them down first means nothing has to be fetched twice.

Data minimization happens at the export, not after it. The support export keeps a ticket's title, timestamp, channel and product area, and nothing that names or contacts the requester.

Everything else stays out. The attachments and the satisfaction score are not needed to show that bookings failed. The free-text message body is where street addresses and gate codes arrive, and the record needs neither. The export also starts when the desk opened, so the record says where that coverage begins and files the exclusion list beside the redacted export.

Two of the records disagree about when the failure began. The booking database logs the first failed write. The monitoring service probes the booking page on a timer and turns red later, because the probe loads the page and the page kept loading while the writes behind it failed. Both describe the same service and the same morning, and they give different start times for one event. Behind them sits the booking database's route table, the source for the day's schedule for field engineers, and it holds nothing for the window at all: the workflow that builds it never recorded whether it ran.

The record reads:

Statement	Status	Source attached
Booking requests failed during the window	Confirmed	Booking database request log
The failure began when the monitoring service first reported it	Disputed: the booking database logs failed writes before the monitoring probe turned red	Both records attached, conflict marked
Customers reported failed bookings to the desk	Confirmed	Support export, kept fields only
Customers who could not book took their visit elsewhere	Hypothesis	Nothing yet
Field engineers' route sheets were produced during the failure	Open gap: no records exist for that workflow	None available

The disagreement about the start is the most useful line in the record, and it is not settled by picking the earlier source or the more senior one. It is marked, with both records attached. It becomes a question for the engineering lead: what did the customer trying to book see when the request failed? Neither record holds that, so the start stays disputed and the window stays as the two owners wrote it. A disputed line is a better result than a record that looks finished.

The route-sheet workflow shows the other failure mode. Absence of evidence is not evidence of no impact. A workflow with no records is one nobody can clear, and the honest entry is the gap itself, with instrumentation as the follow-up rather than a conclusion.

How the documented pieces map to it

Both ends of the work have a documented playbook.

Open Oncall covers the incident end. An alert from PagerDuty, Datadog, Grafana, Opsgenie, Sentry, SigNoz or any webhook opens a Slack thread. The swarm investigates the code and its git history, reads the telemetry, then posts the root cause and the evidence with a one-click approval link. Only listed approvers can answer, and agents get a 403. An approval opens one pull request and merges nothing. A rejection, or no answer within six hours, hands the incident to a human. That thread is the timeline a review starts from.

Reports from multiple sources covers the collection end. Deterministic script nodes fetch from each source over HTTP or SQL into one JSON payload, a Researcher agent synthesizes the narrative, and a complex report renders as a hosted Page. One agent holds the scoped secrets for the cross-source queries, so the credential surface stays small. That is the mechanism that turns a support export, a monitoring timeline and a booking table into one comparable payload.

The human-in-the-loop gate pattern covers the decision. The agent prepares the work up to the point where it cannot be undone, and a person answers. Here, the gate sits between the assembled record and anything that leaves the company.

Two pieces are missing from the documented set, which is why this is a proposal. Neither playbook produces an impact record with a status on every claim, and neither judges what the evidence means for a customer workflow. Adapting them means writing the record format, the source list and the gap list for your systems and your support desk, and that configuration is not packaged for anyone yet.

What this is not

It is not alert-to-fix incident response. Open Oncall and its secondary-on-call case cover detection through to the approved fix. This starts where that ends.

It is not a single failed payment or a single mispriced booking. Those are individual cases with a specific remedy; the small company field guide covers companies putting agents on that kind of recurring operational work. This review covers a window in which nobody knows yet how many cases there were.

It is not a governance or operating-model guide. Where approval thresholds and workflow ownership belong in a written policy is covered by technology as an operations moat. This post covers the review that follows an outage.

FAQ

How can AI agents help a company assess customer impact after a service outage?

Agents collect and assemble. They pull the incident timeline, the service data and the support records for an agreed window, keep only the fields needed to establish impact, and write each statement with its source. They also mark disagreements between sources and name the workflows with no evidence, because both are mechanical checks once the sources are connected. They stop before judgment. A person decides what the evidence means and what the company does about it.

How can engineering and operations combine incident and support data for a post-incident impact review?

By naming one window and one record before collecting, then fetching each source into one payload with the source attached to every line. Engineering's own records will often disagree about when the failure began, and the review should show both rather than settle the conflict by seniority. Both mechanics are documented: multi-source reports for collection, approval gates for the decision.