Recovery prompts vs retry logic.

Retry logic repeats an operation. Recovery prompts re-enter a task with context, constraints, and a safer route after a personal AI agent hits an exception.

The difference is whether the agent learns from the failure before acting again.

Retry logic is useful for transient infrastructure problems. Recovery prompts are necessary when the next attempt must incorporate user corrections, policy boundaries, stale context, or a changed route.

Retry logic assumes the same path can still work.

That assumption is correct for temporary network errors, rate limits, or flaky tools. It is dangerous when the problem is a user correction, an expired approval, a policy constraint, or a failed public action.

Retry logic console

Use retry for transient failure.

The instruction is unchanged and the next attempt should be mechanically similar.

Use recovery for changed context.

The instruction must include what happened, what changed, and what to avoid.

Use both carefully.

A recovery prompt can decide whether a retry is still safe.

Choose by the kind of failure.

Transient tool failure

If a browser, API, or worker failed without changing task meaning, retry logic can work. Keep a cap, backoff, and an escalation path.

User correction or missed approval

If the user changed the instruction, rejected the output, or missed an approval window, use a recovery prompt so the agent does not repeat the old route.

How the models behave in real workflows.

Retry logic is a reliability primitive. Recovery prompts are an agent behavior primitive.

Text retry recovery

Text agents

Retry delivery failures; recover from ambiguous replies and missed approvals.

Browser retry recovery

Browser work

Retry flaky loads; recover from auth gates, changed pages, and unsafe actions.

Publishing retry recovery

Publishing

Retry deploy checks; recover from broken links, stale sources, and release gates.

Handoff retry recovery

Handoff

Retry notifications; recover by summarizing what the human changed.

Buyer checklist

  1. Can the system distinguish transient failure from changed task context?
  2. Can recovery prompts include what happened, what changed, what to avoid, and next action?
  3. Can retry attempts be capped and escalated?
  4. Can recovery prompts pull from exception memory?
  5. Can users inspect recovery context before risky next steps?
  6. Can repeated recoveries update routing policy?

FAQ

Should recovery prompts replace retries?
No. Retries are still useful for transient failures. Recovery prompts are for changed context.

What is the first workflow to instrument?
Start with approval timeouts or failed browser actions because they clearly show whether retrying is safe.

Where does Supers fit?
Supers is relevant for personal AI agents that span text, browser automation, publishing, and human escalation.

Comparison takeaway

Retry logic keeps infrastructure moving. Recovery prompts keep agent behavior aligned after reality changes. Personal AI agents need both, but they should not be confused.

Retry the operation only when the context is still true.

When the task meaning changes, recover with a prompt that carries the exception forward.