How does an agent recover when a plan fails?

An AI agent recovers from a failed plan by identifying what failed, preserving valid completed work, choosing the right recovery action, and updating the remaining plan instead of blindly starting over.

The recovery strategy depends on whether the failure is temporary, caused by bad inputs, caused by a broken assumption, or makes the current path impossible.

Start by identifying the failure

Before changing the plan, the agent should understand what happened.

Common failures include:

• tool timeout
• permission denied
• invalid input
• missing data
• unavailable resource
• unexpected tool output
• failed dependency
• changed external state

Different failures require different responses.

Do not restart everything automatically

Suppose the plan is:

1. retrieve customer data
2. generate report
3. email report

If the email step fails, the agent should usually keep:

• retrieved customer data
• generated report

and recover only from the failed delivery step.

Preserving completed work reduces cost and prevents duplicate actions.

Retry when the same step is still correct

A retry is appropriate when the failure is temporary.

For example:

send_email → timeout

If the email service is expected to recover, the agent may retry using bounded retry logic.

Retries should have limits and should be especially careful with state-changing actions.

Replan when the path itself is no longer valid

Suppose the selected flight is sold out.

Retrying the same booking request will not solve the problem.

The agent should replan:

1. search alternative flights
2. compare options
3. continue with a valid choice

A useful distinction is:

Retry: Same step, another attempt.

Replan: Change the remaining path.

Use fallback options when available

Some workflows can define approved fallbacks.

For example:

• primary API unavailable → use backup API
• preferred warehouse empty → check another warehouse
• email unavailable → save report and notify the user

Fallbacks should be known, permitted, and appropriate for the task.

Repair invalid state before continuing

Sometimes the failure leaves the workflow state incomplete or inconsistent.

For example:

• an ID was missing
• a value was stale
• a previous result was malformed

The agent should repair or refresh that state before executing downstream steps.

Otherwise, one bad result can cause several later failures.

Verify uncertain side effects

A timeout does not always mean an action failed.

Suppose:

create_payment → timeout

The payment might have been created even though the response was lost.

Before retrying, the agent should check the current external state or use an idempotency mechanism.

This helps prevent duplicate actions.

Ask the user when recovery requires a decision

Some failures cannot be resolved safely without user input.

For example:

• several valid alternatives exist
• required information is missing
• the user's original constraint cannot be satisfied

Instead of guessing, the agent can ask for the minimum information needed to continue.

Escalate when the agent lacks authority

A recovery path may require:

• human approval
• additional permissions
• another specialist agent
• operator intervention

The agent should escalate rather than trying to bypass those boundaries.

Stop when no safe path remains

Recovery should not become an endless loop.

The agent should stop when:

• retry limits are exhausted
• replanning repeatedly makes no progress
• no valid tool is available
• required authorization is unavailable
• continuing would violate policy or safety constraints

A clear failure is better than repeatedly taking ineffective actions.

Record the recovery path

For important workflows, the system should track:

• failed step
• failure reason
• retries
• fallback used
• revised plan
• approvals
• final result

This makes recovery behavior easier to debug and audit.

A practical recovery flow

A plan-failure recovery process can look like:

1. Detect the failed step.
2. Classify the failure.
3. Check whether the action may already have succeeded.
4. Preserve valid completed work.
5. Retry if the failure is temporary.
6. Repair missing or invalid state if needed.
7. Use an approved fallback or replan when the path is invalid.
8. Ask the user or escalate if required.
9. Verify the recovered result.
10. Stop safely if no valid path remains.

In short

An agent recovers from a failed plan by diagnosing the failure, keeping completed work, and choosing between retry, state repair, fallback, replanning, user clarification, escalation, or safe termination.

Good recovery avoids repeating successful steps, prevents duplicate side effects, and changes the plan only when the current path can no longer reach the goal reliably.