A system incident usually announces itself: an outage, an error rate, a queue that stops moving. An agent incident often does not. The agent stays up, responds quickly and does the wrong thing, consistently, across many cases, within the reach it was given. Detecting, containing and investigating that kind of failure needs different signals and different first moves.
How do agents fail differently from systems?
Conventional incident management is built around availability and errors. Something breaks, monitoring alerts, an engineer restores service. The question is how fast you can get back to normal.
Agents add a second class of failure: wrong action. The agent is healthy by every technical measure, but it is misapplying a rule, relying on a stale source, misreading a document type or following an instruction it should have ignored. Because agents act at volume and repeat their reasoning, one misreading becomes a pattern across hundreds of cases before anyone notices.
| System incident | Agent incident | |
|---|---|---|
| Typical trigger | Outage, error, latency | Wrong decisions within normal operation |
| How it is detected | Technical monitoring | Verdict patterns, reviewer edits, complaints, reconciliation |
| First move | Restore service | Narrow the agent's authority on the affected capability |
| Scope question | Which systems are down? | Which actions did this agent take, and which were wrong? |
| Root cause | Code, infrastructure, capacity | Sources, bounds, model change, case mix, manipulated input |
| Severity measured by | Downtime and users affected | Harm to customers and the business |
The table is the argument in brief. Most incident runbooks cover only the left column.
What signals reveal an agent incident early?
Not technical monitoring, which will usually show everything green. The useful signals sit in the agent's decisions and in the people around it.
Shifts in verdicts. A sudden fall in held or refused items can mean a bound has stopped working. A sudden rise can mean the agent is receiving work it cannot handle, or a source has gone stale.
Reviewer edits. If people approving the agent's drafts start changing amounts or outcomes rather than wording, the agent's proposals have got worse.
Downstream reconciliation. Payments that do not match, records that fail validation, letters returned. These often catch errors that passed every check upstream.
Complaints and contacts. Customers notice wrong outcomes faster than dashboards do. A cluster of similar complaints about one kind of decision is a strong signal.
Each of these needs an owner who watches it and knows that a change may be an incident, not just a bad week. Our playbook on logging and triaging operational incidents covers how to route them.
What should the first move be?
Narrow the agent's authority on the affected capability, immediately. Drop it to draft so a person sends everything, or to read so it takes no action at all. Leave its other capabilities alone unless they are also affected.
This is very different from restarting a service. Restarting an agent does not fix it; it will make the same decision again on the next similar case. Switching it off entirely sends all its work back to people, including the large majority it was handling well. Lowering depth on one capability contains the harm while keeping the rest running.
The person who makes this call should be the capability owner, and they should not need permission. If narrowing an agent requires a change request and a meeting, harm continues while the request waits.
How do you work out the blast radius?
By querying the agent's decisions, not by guessing. If every action the agent proposed is recorded under its own identity, with the capability, the sources it used and the verdict, you can find every case that fits the failure pattern. If the agent acted under a shared or borrowed identity, this step becomes an investigation that may never be complete.
Take a claims team as an example. An agent connected to the claims system, as described in connecting an AI agent to your claims system, has been settling small claims within a limit. A change to the policy wording library means the agent starts treating a new exclusion as if it did not exist. Technical monitoring sees nothing. Reconciliation flags a handful of payments on excluded claims. The capability owner drops settlement to draft. The record then shows every claim the agent settled since the wording changed that touched that exclusion, and each one can be reviewed.
How is root cause different for agents?
Agent root causes rarely sit in code. They tend to fall into a few groups: a source changed or went stale; a bound was set wrongly or an exception was left open; the underlying model changed behaviour; the case mix shifted towards cases the agent was never tested on; or an input contained something designed to mislead it.
Each points to a different fix and a different owner. A source problem goes to whoever owns that source. A bound problem goes to the capability owner. A model change means re-testing before restoring depth. A manipulated input may be a security matter. Write incident reviews that name which group the cause falls into, so patterns across incidents become visible.
What are the reporting duties?
They depend on the sector and the jurisdiction. EU financial entities in scope of DORA must manage and report major ICT-related incidents, and an agent failure on a third-party platform may fall within that. The EU AI Act places duties on deployers of high-risk systems to monitor them and to inform the provider and authorities of serious incidents; our guide on EU AI Act serious incidents for deployers covers that in substance. Conduct regulators will also expect customer harm to be identified and put right. This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.
What is the trade-off in adapting incident handling?
It takes new monitoring, new runbooks and new owners. Operations and risk teams, not only engineering, have to be on call for agent incidents, and they need tools to narrow authority and query decisions quickly.
The alternative is an incident process that waits for something to break. Agents do not need to break to cause harm. Add a section to your incident runbook for wrong action: the signals that trigger it, the capability owner who narrows depth, the query that finds affected cases and the review that names the root cause group. The deployment approach that supports this is in our guide to deploying an AI agent: train, shadow, certify, widen.
Where Pryme fits
In Pryme, a capability's depth can be lowered at once by its owner, and a certification run that clears no depth drops the agent to depth 1 the same day. Every verdict is filed under the agent's own identity with its sources and the deciding bound, so the set of affected cases can be found from the record rather than reconstructed.
Questions people ask
Should agent incidents go through the same incident team as system incidents?
They can share the process and the tooling, but they need different responders. A capability owner from the business must be involved from the start, because the first decision is about authority and customer harm, not service restoration.
How do you tell an agent incident from normal variation?
Agree thresholds in advance for each signal, such as a change in held items or reviewer edits beyond a set range over a set period. Anything beyond the threshold is treated as a possible incident and checked, even if it turns out to be benign.
When can an agent's depth be restored after an incident?
When the cause is fixed and fresh evidence on current cases shows the agent clears the standard for that capability again. Restoring depth because the incident has been closed, without that evidence, repeats the original mistake.