Agent Behaviour

User Action Recovery

Keep actions correctable after they happen, with a clear path to reverse, compensate and re-approve.

Phase: Design · Build
Applies to: End users, operators, developers
Oversight: Human in the loop and on the loop
Key factor: System autonomy

Overview When to use Multi-agent considerations Questions to ask Example Anti-pattern Anti-patterns to pay attention to References Evidence Related

Overview

Users approve too quickly, set thresholds too low, or miss warnings. In multi-agent systems, a single action can travel through a chain before anyone reviews it. Designing only for prevention assumes errors never happen. User Action Recovery treats correction as a normal state: a clear path to reverse an action where possible, or to issue a compensating action where it isn't, without a support ticket or workaround.

Attention

Two sub-types apply, depending on where in the agent chain the error is caught.
Rollback: the original action is reversed and work returns to its prior state for re-approval.
Compensating action: the original action can't be reversed, usually because downstream agents have already acted on it. A corrective action is issued (cancel, reissue, correction notice) and affected work re-enters review.

When to use

Use when

The agent acts, or people act on its output, and that action has effects someone might need to correct.
Several agents pass output to one another, so errors propagate and the window for reversal shrinks at each step.

Not needed when

The agent is advisory only and its output is non-blocking: no action is taken on it automatically.

Multi-agent considerations

In a single-agent flow, recovery is straightforward: one action, one reversal. In a multi-agent flow, one agent's output becomes the next agent's input. By the time a person reviews the result, several agents may already have committed downstream actions.

Recovery is only clean at review gates, where the flow pauses for a person before the next agent acts. Without gates, rollback isn't possible. Gates make outputs enter a queue that can't be skipped, so a person decides the next step.

Questions to ask

Ask these at kickoff, when design work starts. Tick them off as your team answers.

Which actions can be rolled back, and for how long?
Where in the agent flow are the gates? What commits before the next gate?
For actions that can't be rolled back, what does the compensating action look like?
Does corrected work re-enter review, and at which step?
When a compensating action is triggered in a multi-agent flow, what context is handed to the person taking over?

Example

A researcher submits an AI-generated literature review for team sign-off. The approver confirms it and it's shared with the wider group. Then the approver spots that a key finding was attributed to the wrong paper. The share can't be undone, so the system offers a compensating path: open a corrected version, fix the attribution and resubmit. The resubmission goes through the same approval step, and the audit trail records both events with reasons.

Literature review · Correction flowDo

Original review · Approved 14:32 by J. OseiShared

Attribution error identified after sharing. Open corrected version

Correction v2 · Attribution updatedReason for correction: finding misattributed. Correct source: Study B, §3.2.

Resubmit for approvalCancel

Anti-pattern: No path back

The action completes and the reviewer realises the output was wrong. There's no correction option in the interface; the only route is a support request or a workaround outside the system. In a multi-agent flow it's worse: the error has already reached downstream steps, but the interface shows only the final result, with no record of what each step did.

Literature reviewDon't

Status: SharedNo correction option

Anti-patterns to pay attention to

No correction or re-approval option exists after the first gate.
Corrected work skips review and goes straight back out.
In a multi-agent flow, the interface shows only the final output, not where in the chain the error happened.

References

Current guidelines · EU AI Act, ISO/IEC 420013 references

For orientation only, not legal advice. EU AI Act links open a readable version of the official text published on EUR-Lex; ISO/IEC 42001 is a paid standard.

EU AI Act Art. 14(4)(d) People overseeing high-risk systems must be able to override or reverse the output.
ISO/IEC 42001 A.6.2.5 Deployment plans include release criteria, approvals and rollback.
ISO/IEC 42001 A.6.2.8 Decide which events are logged to support audit. In practice, log what the agent did and what a person changed as separate events.

Evidence

Survey & researchSurvey insights

Survey insightMost respondents preferred flag-and-proceed over blocking. Respecting that preference means some mistakes will get through, so reversal has to be designed.

The survey is still open. Add your perspective ↗