Intervention, Correction, and Recovery

An agentic product should not treat failure as an embarrassing edge case. Failure is part of the interaction model: goals are ambiguous, sources are stale, tools fail, users change their minds, permissions expire, outside systems respond late, and model-mediated behavior sometimes takes the wrong path.

Recovery is where the product proves whether its earlier promise was honest. A system that says “I will handle this for you” but can only apologize and regenerate when something goes wrong has not designed delegated work. It has designed hopeful output.

The product earns trust not by pretending errors are rare, but by making recovery legible and controllable.

Thesis

Recovery UX should preserve truth before comfort: show what is known, what changed, what is uncertain, what can still be undone or corrected, and who owns the next step.

This chapter does not define idempotency, compensation, durable execution, or incident command. Production Engineering owns those mechanics. Product & UX owns whether people can understand and use the recovery path when those mechanics surface in the product.

Make intervention available before crisis

Users should be able to intervene when:

• the goal or scope is wrong;
• the system asks for clarification;
• the proposed action is unacceptable;
• progress is going in the wrong direction;
• a dependency or policy blocks work;
• the user changes priority;
• a partial result is enough;
• another person should take over;
• the system has made a harmful or confusing move; or
• the user no longer wants delegated work to continue.

Do not bury intervention behind final failure. Correction is cheaper before external effects commit. OpenAI’s agent-building article recommends human intervention for repeated failures and high-risk actions (OpenAI, 2026); the product should make those interventions normal, not exceptional.

Useful intervention points include:

Moment	User action	Product requirement
Before start	Edit goal, scope, authority, budgets.	Update the delegation contract.
During planning	Correct assumptions or exclude paths.	Replan and show invalidated work.
Before effect	Reject, edit, or approve a staged action.	Bind decision to exact action and state.
During execution	Pause or cancel.	Stop new work and report in-flight effects.
At blockage	Supply evidence, narrow scope, or escalate.	Preserve blocker reason and next owner.
After partial result	Accept subset or continue.	Label remaining obligations.
After failure	Retry, change strategy, compensate, or handoff.	Offer only valid recovery options.

Treat corrections as state changes

A correction should show:

• what the user changed;
• what it supersedes;
• why it matters;
• which pending actions, approvals, memories, or assumptions are invalidated;
• whether completed work remains valid;
• whether evidence must be rechecked;
• whether approvals must be renewed; and
• what the system will do next.

If a user corrects a recipient, amount, deadline, source, jurisdiction, customer identity, or constraint, the product should not simply append that correction to a chat transcript. It should update the task state and surface consequences. Microsoft recommends supporting efficient correction and dismissal in human-AI systems (Amershi et al., 2019). In agentic products, efficient correction depends on structured state.

Example:

Correction: "Use the enterprise refund policy, not the consumer policy."

Supersedes:
- Policy assumption in current recommendation.
- Draft customer message.
- Pending approval for refund action.

Still valid:
- Order status and customer identity.

Next:
- Re-evaluate eligibility and prepare a new preview.

That message is more useful than “Got it, I will use the enterprise policy” because it tells the user what changed and what did not.

Show effect status before recovery choices

When something goes wrong, users need a status model:

Effect status	Product meaning
Not started	The action was never attempted.
Staged	The action is prepared but not committed.
Committed	The action took effect and evidence exists.
Rejected	The action was attempted and denied.
Partial	Some effects occurred and others did not.
Unknown	The system cannot yet tell whether the effect committed.
Compensating	A corrective domain action is pending or underway.
Escalated	A person or another process now owns resolution.

Do not flatten these states into “error.” A user who cancelled before dispatch needs different reassurance from a user whose message may have been sent. A user who receives a partial result needs the remaining obligations, not a cheerful success banner. A user facing an unknown payment outcome needs reconciliation, not another identical attempt.

Product language should be calm and exact:

The refund request was sent, but the payment provider did not return a final status.
Do not retry yet. I am checking the operation status with the same request ID.

or:

The email was not sent. It is still staged as a draft, and you can edit or discard it.

or:

Two of five records were updated. The remaining three failed policy checks and were not changed.

Offer recovery choices that match reality

Common recovery actions include:

• edit and continue;
• retry the same operation;
• retry with changed input;
• change strategy;
• accept a partial result;
• undo a reversible action;
• compensate for an irreversible effect;
• reconcile an unknown effect;
• escalate to a person;
• open a support case;
• export evidence;
• stop and preserve current state; and
• start a new task with selected artifacts.

Only show choices the system can honor. “Undo” should not appear when the domain supports only compensation. “Retry” should not appear when the previous write has an unknown outcome and another attempt may duplicate it. “Start over” should say whether existing memories, drafts, approvals, audit records, and external effects remain.

Google’s People + AI Guidebook recommends designing for errors and graceful failure rather than presenting AI output as infallible (Google PAIR). Graceful failure is not vague apology; it is a usable next step.

Distinguish retry, regeneration, replan, undo, and compensation

These choices are often collapsed in AI interfaces, but they mean different things:

Choice	Meaning	Use when	Do not use when
Regenerate	Ask for another model sample.	Low-risk drafts or creative alternatives.	Missing authority, stale state, or external effect uncertainty caused the failure.
Retry	Attempt the same operation again under a retry policy.	Failure is transient and duplicate effects are controlled.	Outcome is unknown or request is invalid.
Replan	Choose a different route or constraints.	Evidence shows the current strategy cannot work.	The same plan only needs a transient retry.
Undo	Reverse a reversible action.	The domain truly supports restoration.	The effect is irreversible or only partially reversible.
Compensate	Perform a new corrective domain action.	Exact undo is impossible but repair is available.	Product language implies the original never happened.
Escalate	Transfer responsibility to a capable actor.	Authority, expertise, dispute, or impact exceeds the system.	Nobody accepts ownership.

The UI should teach these differences through labels and consequences. “Try again” is not enough. “Retry the status check” and “send another refund request” have very different risk.

Preserve partial results without disguising completion

Agentic work often produces something useful before it fails:

• a research brief with two verified sources and three unresolved claims;
• a patch that compiles but leaves failing tests;
• a prepared support response without a committed refund;
• a schedule proposal that could not book the meeting;
• a cleaned dataset with excluded rows listed; or
• an operations diagnosis without authorization to fix.

Partial result UX should state:

• which subset is usable;
• which success conditions remain unmet;
• what evidence supports the completed part;
• which effects were committed, staged, rejected, or unknown;
• what the user can do next;
• whether continuing requires new authority, data, time, or cost; and
• how the partial result will be stored or handed off.

Do not convert partial results into success because the final message sounds complete. Partial value is useful precisely because it is honest.

Use language that is accountable

Good recovery language:

• states what happened;
• distinguishes verified fact from uncertainty;
• avoids blaming the user for model ambiguity;
• names the next safe action;
• preserves evidence links;
• gives time or ownership when waiting;
• explains limits without overclaiming; and
• uses the same terms as the product state.

Avoid:

• “I couldn’t complete that” when the system actually changed some state;
• “No worries, I fixed it” when compensation is still pending;
• “Try again” when the same conditions will fail;
• “Cancelled” when only a stop request has been received;
• “Undo” when the product is issuing a new correcting action; and
• “Done” when human acceptance or read-back evidence is still missing.

An apology can be appropriate, but it should not replace operational truth. Users need to know whether work was saved, sent, lost, queued, partial, unknown, or escalated.

Design handoff and takeover

When a user or operator takes over, provide a package:

• original goal and current scope;
• current state and pending work;
• material evidence and sources;
• actions already taken;
• approvals and their limits;
• unknown or partial effects;
• corrections and superseded assumptions;
• files, artifacts, drafts, or records produced;
• remaining deadlines and budgets;
• suggested next options; and
• who currently owns the task.

A takeover button that leaves the user with only a transcript is weak. The workspace should make it possible to continue without reconstructing truth from a conversation. The receiving actor should accept ownership where responsibility matters; a notification alone is not a handoff.

NIST AI RMF Playbook treats response, accountability, and human oversight as lifecycle concerns rather than UI labels (NIST AI RMF Playbook). Product handoff should therefore identify not just the message recipient but the responsible role, the decision needed, the evidence transferred, and the safe default if nobody responds.

Make recovery accessible

WCAG 2.2 error-related success criteria require identifying errors, offering suggestions where possible, and preventing serious mistakes in user submissions (W3C, 2023). Agentic products should apply the same spirit to generated proposals and external effects.

Recovery controls should be:

• reachable by keyboard;
• named clearly for assistive technologies;
• attached to the affected action or artifact;
• understandable without relying only on color or animation;
• available long enough for real review where timeouts exist;
• explicit about destructive or irreversible choices;
• resilient across refresh, session change, and device switch; and
• consistent with the workspace’s current state.

An inaccessible recovery path is a correctness problem. It leaves some users unable to correct delegated work at the moment correction matters.

Escalate beyond self-service when needed

Some failures should not be solved inside the chat or workspace:

• possible data exposure;
• unauthorized or disputed external effects;
• financial, legal, medical, employment, benefits, or safety impact;
• repeated automation failures;
• user complaint or appeal;
• unknown effect that cannot be reconciled automatically;
• policy exception requiring a responsible owner;
• signs of abuse, prompt injection, or account compromise; and
• accessibility blockers that prevent the user from controlling the system.

The product should route these to support, incident response, governance review, or another accountable process. Self-service UX is not a substitute for organizational responsibility.

Failure modes

Regenerate as the only recovery

The product treats every failure as a request for another model sample. The real problem may be missing authority, wrong state, bad source, policy denial, or an already committed effect.

Apology without state

The system says sorry but does not say what happened, what is pending, or what the user can do.

Undo theater

The UI says undo, but the original effect cannot be reversed. A separate compensation or support workflow was required.

Lost correction

A user corrects the task, but a child run or pending action continues under the old instruction.

Transcript handoff

An operator receives pages of chat instead of a concise state, evidence, and action package.

Partial result disguised as done

The system completes an easy subset and hides the unfinished obligations.

Unknown effect flattened to failure

A write times out after dispatch, the product says “failed,” and the user retries in a way that may duplicate the effect.

Fieldbook guidance

1. Make intervention controls available during work, not only after failure.
2. Treat corrections as structured state changes with visible consequences.
3. Show effect status before recommending recovery.
4. Offer only recovery actions the system can actually honor.
5. Distinguish regeneration, retry, replan, undo, compensation, and escalation.
6. Preserve partial results with limits and remaining obligations.
7. Give takeover and handoff recipients an evidence package, not a transcript dump.
8. Keep recovery language factual, specific, accessible, and actionable.

Checklist

• Can users intervene before a harmful or expensive effect commits?
• Do corrections supersede old assumptions and invalidate pending work?
• Does the product distinguish staged, committed, partial, rejected, unknown, compensating, and escalated effects?
• Are retry, regenerate, replan, undo, compensation, restart, and escalation options shown only when valid?
• Are partial results labeled with limits and remaining work?
• Can a person take over with state, evidence, artifacts, approvals, corrections, and pending obligations?
• Are error messages and recovery controls accessible and actionable?
• Does recovery language avoid false reassurance?
• Are serious failures routed to support, escalation, governance, or incident response when self-service is insufficient?
• Does the workspace preserve recovery evidence after the immediate interaction ends?

References and how they are used

• Google People + AI Research, People + AI Guidebook - Google People + AI Research design resource used for error design, graceful failure, feedback, and control; it is not a formal recovery standard.
• Microsoft Research, “Guidelines for Human-AI Interaction” - peer-reviewed human-AI interaction paper supporting correction, dismissal, graceful degradation, explanation, and global controls.
• NIST AI Risk Management Framework Playbook - NIST voluntary risk-management web resource used for lifecycle response, oversight, accountability, and escalation framing; it is not a product recovery certification.
• OpenAI, “A practical guide to building AI agents” - OpenAI product-adjacent agent-building article supporting human intervention for high-risk actions and repeated failures.
• W3C, Web Content Accessibility Guidelines 2.2 - W3C Recommendation used for accessible error identification, suggestions, prevention, and operable controls.