Recovery depends on what kind of error it is. A timeout can be retried safely if each step is idempotent. Missing or conflicting facts should pause the task for a person. A refusal is not an error to work around. A half-finished change is compensated or handed back with a record of where it stopped.
Which kinds of error happen mid-task?
| Error type | Example | Right response |
|---|---|---|
| Transient | A system times out | Retry with the same idempotency key, a limited number of times |
| Input | A required document is missing or unreadable | Hold the task and ask for it |
| Conflict | Two sources disagree on a customer's address | Hold for a person to resolve |
| Authority | The platform refuses an action | Stop that path; do not try another route to the same outcome |
| Partial completion | The agent updated 120 of 200 records before a failure | Record exactly what changed; resume or reverse, never guess |
| Agent fault | The agent misread a field and acted on it | Stop, flag, and drop its depth for that capability until reviewed |
The point of the table is the first decision. An agent that treats every failure as "try again" will retry its way through a refusal or repeat a step that already succeeded.
Why must a refusal never be treated as a bug?
When the platform refuses an action, it is telling the agent the action is outside its bounds. An agent that responds by trying a different tool, a smaller amount repeated several times, or a request to another agent is attempting to get around a control. Each attempt should itself be refused, and the pattern should be visible in the record.
Good recovery logic encodes this directly: a refused verdict ends that line of work and routes the task to a person or back to the queue. It does not trigger re-planning towards the same outcome.
How should partial completion be handled?
Batch work is where this bites. Take an agent applying a premium adjustment to 200 policies. It succeeds on 120 and then the policy system goes down.
The task record shows exactly which 120 changed, with the verdict for each. When the system returns, the agent resumes at policy 121, using idempotency keys so that any policy already done is not adjusted twice. If the business decides instead to reverse the batch, the agent applies compensating changes to those 120 only. Reversible work can be compensated. If any step had been irreversible, the agent would stop and hand the whole batch to a person. The same pattern applies when you let an agent make mid-term changes in a policy administration system.
What may the agent do, and what stays with a person?
The agent may retry transient failures within a set limit, resume from its last confirmed step, and compensate reversible steps when instructed. It may flag its own suspected mistakes.
A person decides what to do about conflicts, partial batches that cannot simply resume, any step that cannot be reversed, and whether a failed agent should continue. A person can also stop an agent mid-action at any point; the design of that control is covered in the Article 14 stop button, drawing on the EU AI Act's human oversight requirement.
What does this look like when several agents are involved?
Errors cross agent boundaries. A matching agent fails mid-run and leaves invoices half-matched; the payment-prep agent downstream picks up the matched ones and waits on the rest. Without a shared task id, nobody can tell which invoices are in which state.
With one, the full path is visible: which agent did what, where it stopped, and which downstream agent consumed partial output. See how to trace a task across several AI agents. Routing the remainder to another agent is a decision with its own owner, covered in who decides which agent handles a task.
What controls make recovery safe?
- Every action carries an idempotency key, so retries cannot duplicate.
- Retries are capped, after which the task is held.
- Refusals end the path and are never retried by another route.
- Task state records each confirmed step, not just the plan.
- A certification run that clears no depth drops the agent to depth 1 the same day, so a faulty agent cannot keep acting while it is investigated.
The governing layer that holds these controls is described in the governed agentic operating system guide.
Questions people ask
Should an agent apologise and try again when it makes a mistake?
Not on its own. An agent that has acted on a misreading should stop and flag the error, because the same misreading may affect the retry. A person decides whether to correct and resume.
Can an agent undo its own actions?
For reversible actions, yes, through compensating steps within its bounds. For irreversible ones, undoing is a new action, often requiring a person, and some, such as reversing a settled payment on a rail, are withheld for every agent.
How do you know an agent recovered correctly?
Compare the end state in the systems of record with the task record. Recovery is correct when every step the record says happened did happen, once.