Recording belongs to the agent; judgement stays with the incident manager. It gathers reports from alerts, mailboxes and staff, logs each incident with standard fields, links duplicates, pulls impact from systems of record and proposes a severity. A named person confirms high severity, decides whether a regulator must be told, and closes the incident.
What is operational incident triage, and who owns it?
An operational incident is anything that disrupts a service or harms customers: a payment file rejected by the clearing system, a batch job that did not run, fees charged twice, an outage at a supplier, a misdirected letter. Triage decides how serious it is, who must act, and who must be told.
The incident manager on duty owns triage. The operational risk team owns the incident register and the severity matrix. Service owners own the fixes. Compliance owns any decision to notify a regulator. The agent supports all of them by making the first hour faster and the record complete, which is where incident handling most often fails.
What are the steps, and who acts at each?
- Agent, depth 1: collects reports. Monitoring alerts, messages to the operations mailbox, staff reports through the incident form, and customer contacts that mention the same symptom. Triage of the mailbox itself follows triaging a shared operations mailbox.
- Agent, depth 3: logs the incident in the register with the standard fields: time detected, how detected, service affected, symptoms, reporter. It logs at once, before anyone has worked out the cause.
- Agent, depth 3: links duplicates. Ten alerts and four staff reports about the same failure become one incident with fourteen linked reports.
- Agent, depth 1: gathers impact from systems of record: how many payments are in the rejected file, how many customers were charged, which branches are affected. Each figure is stamped with its source.
- Agent, depth 3: sets low severity where the written matrix leaves no doubt, for example a single internal user affected with a workaround.
- Agent, depth 2: proposes higher severities with the matrix criteria it relied on. The incident manager confirms or changes.
- Agent, depth 3: notifies the on-call people the matrix names for that severity and service.
- Agent, depth 2: drafts the reportability assessment against the firm's criteria for telling regulators, customers or partners. Compliance decides.
- Agent, depth 3: keeps the timeline: who joined, what was tried, when service returned.
- Person, incident manager: closes the incident and hands it to problem management for root cause.
| Step | The agent does | Depth | Stays with a person |
|---|---|---|---|
| Collect | Gathers reports from all channels | 1 | Nothing |
| Log | Creates register entry | 3 | Nothing |
| Link | Merges duplicates | 3 | Splitting wrongly merged incidents |
| Impact | Pulls figures from systems | 1 | Interpreting them |
| Low severity | Sets by matrix | 3 | Overrides |
| Higher severity | Proposes with criteria | 2 | Deciding |
| Notify on-call | Pages named people | 3 | Nothing |
| Reportability | Drafts assessment | 2 | Deciding to notify |
| Timeline | Records events | 3 | Nothing |
| Close | Nothing | none | Closing and root cause |
Why does the agent log before anyone understands the cause?
The first record of an incident is often written an hour late, from memory, by someone who was busy fixing it. Detection time, the first symptom and the first person who noticed are lost. Those facts matter later: regulators and auditors ask when you knew, and the honest answer depends on the register.
An agent can create the entry the moment the first report arrives, with nothing interpreted. Cause, severity and scope are added as they are known, each with a time.
What changes when the incident involves an AI agent?
Incidents caused by agents need a different set of questions. Was the action allowed, and by which bound? Did the agent act on bad sources? Has its depth already dropped? The differences are set out in why agent incidents look different from system incidents. The triage agent should flag any incident where another agent's action is in the timeline, and pull that agent's verdict records into the incident.
If the AI system involved falls under the EU AI Act's high-risk rules, deployers have their own duties when a serious incident occurs; see what a deployer of an AI agent must do about serious incidents. For EU financial entities, DORA's ICT incident reporting may also apply. In both cases the agent drafts and a person decides.
What controls apply, and what evidence do they leave?
A written severity matrix. The agent can only set severity where the matrix is unambiguous. Evidence: the matrix version and the criteria cited for each severity.
Confirmation of high severity by a named person. Evidence: who confirmed and when.
Sourced impact figures. Evidence: the system and query behind each number.
Changes to the incident record are kept. Evidence: every field change with its author, agent or person.
Separation from the fix. The triage agent does not run fixes. Changes to production go through the change process, and checks on those changes are covered in running four-eyes checks on operational changes.
What should you measure?
- Time from first report to logged incident. This should fall to minutes.
- Severity changes by incident managers, up and down. Downgrades suggest the matrix is cautious; upgrades are the more serious count.
- Duplicates missed, where two incidents turn out to be one.
- Reportable incidents identified, and any found reportable only later.
- Completeness of the timeline at closure, sampled monthly.
Where does it usually go wrong?
Severity becomes the agent's call. People stop questioning a severity that appeared automatically. Show proposed severities as proposals until confirmed.
Impact figures are guessed. Under pressure, the agent fills a "customers affected" field from an email estimate. External estimates must be labelled as such, never stored as counts.
Too many pages. Notifying everyone on every incident teaches people to ignore pages. Keep notification lists tight and tied to severity.
The agent goes quiet during the big one. The worst incidents often affect the systems the agent reads from. Decide in advance what the agent does when its sources are down: log what it can and say what it cannot see. Rehearse it, as train, shadow, certify, widen suggests for any new capability.
Questions people ask
Can the agent decide that something is not an incident?
It can propose that a report is a known issue or a duplicate. Dismissing a report entirely should need a person, because the cost of missing an incident is higher than the cost of logging one.
Should the agent talk to customers during an incident?
Not as part of triage. Customer messages during an incident are approved by the incident manager and sent through the normal channels.
How long should the incident record be kept?
As long as your operational risk and regulatory rules require. The agent's verdict records for the incident should be kept for the same period.