- In short
- Recovery strategy selection is choosing the right response for each error class: retry with exponential backoff for transient transport and rate-limit errors, reprompt with the validation error as feedback for malformed structured output, and escalate to a human for unrecoverable or ambiguous failures. The strategy follows from the error class, so it must never loop indefinitely on a failure that will not resolve.
Strategy is a function of the error class
Recovery strategy selection is the apply-level companion to classification. Once you have named the failure using error type identification, the recovery is largely determined: each class of error has a matching remedy, and the skill this knowledge point tests is applying the correct one under a described scenario. The Claude Certified Developer - Foundations (CCDV-F) exam frames Task 4.1 as a pipeline, classify first, then recover, and this page is the second half of that pipeline.
There are three recovery strategies to master, and each belongs to a specific situation: retry with backoff for transient failures, reprompt with feedback for malformed output, and escalate for the unrecoverable. The exam is less interested in whether you can name them than in whether you route the right failure to the right one. The two most punished mistakes are both routing errors, sending a deterministic failure to a retry, and sending a semantic failure into an endless reprompt, so the substance of this knowledge point is knowing exactly where each strategy stops applying.
- Recovery strategy selection
- Choosing the appropriate recovery for a given error class: retry with exponential backoff for transient transport and rate-limit errors, reprompt with the validation error as feedback for malformed structured output, and escalation to a human for unrecoverable or ambiguous failures. The correct strategy is dictated by the class of error, and no strategy should loop without bound.
Retry with exponential backoff
Transient transport errors and rate-limit errors are the retry candidates, and the correct form of retry is exponential backoff. Rather than retrying immediately or on a fixed interval, you wait a growing amount of time between attempts, doubling the delay each round, so a spike of load or a brief outage has time to clear. Backoff matters most for rate-limit errors: retrying a 429 immediately just earns another 429 and can deepen the throttle, whereas backing off respects the quota window and lets it reset. For transient network failures the same pattern gives an ephemeral fault time to resolve without a tight, wasteful loop.
The essential constraint is that retry is only valid when the failure is genuinely transient, when something about the next attempt can plausibly differ. That is why classification precedes strategy: a transport blip or a throttle can succeed on retry, but a deterministic error cannot. The boundary between retryable and non-retryable failures is exactly the retry effectiveness boundary the Architect track formalises, and it is the same line the CCDV-F exam draws when it plants a deterministic error inside a set of retry candidates.
Reprompt with the validation error as feedback
When the failure is a model-output error, the JSON was malformed, a field was missing, the structure violated your schema, retrying the identical call is pointless, because the same input tends to reproduce the same output. The correct recovery is to reprompt: send the request again, but this time include the validation error as feedback so the model can see precisely what was wrong and correct it. Telling the model "the field total was missing and date was not ISO-8601" gives it the corrective signal that a bare retry lacks.
This is the retry with error feedback pattern, and its power comes entirely from the feedback. A plain retry changes nothing about the request, so it changes nothing about the result; a reprompt that carries the specific error changes the input, which is what makes a different, valid output possible. The distinction between "retry the same thing" and "reprompt with what went wrong" is one the exam tests directly, because candidates who blur them will try to fix a malformed-output error with a mechanism that has no chance of working.
Escalate to a human
Not every failure is recoverable by the application, and recognising that is the third strategy. When a failure is unrecoverable, or when the model keeps producing an ambiguous or semantically wrong result that reprompting does not resolve, the correct move is to escalate to a human rather than loop indefinitely. An application that retries a hopeless call forever, or reprompts a stubborn semantic error on an infinite loop, burns cost and latency while never converging. Escalation is the deliberate decision to stop automated recovery and hand the problem to a person.
Escalation is also a safety valve on the other two strategies. Every retry loop needs a cap, after so many backed-off attempts, escalate. Every reprompt loop needs a cap, after so many corrective attempts, escalate. The bound is what separates a robust recovery design from a runaway one, and the exam rewards designs that fail over to a human at a sensible limit rather than spinning. This same discipline of bounding attempts and routing the unresolved onward appears in batch failure handling and retry, where large jobs must isolate and escalate the items that will not succeed.
The exam traps
Misconception
If a call failed, retrying it is always a reasonable first attempt at recovery.
What's actually true
The first trap is retrying a deterministic input error without changing anything. A malformed request, an invalid argument, or a schema-violating payload fails the same way every time because nothing about the resend differs. Retry is reserved for transient failures where the next attempt genuinely could succeed; applying it to a deterministic error produces a loop that always loses and masks the real fix. When the exam offers "retry the request" as a recovery for an input or schema error, it is offering the wrong tool on purpose.
Misconception
If reprompting improves the output a little, I should keep reprompting until it is perfect.
What's actually true
The second trap is the mirror image: reprompting endlessly on a semantic failure. Reprompting with feedback is the right recovery for a malformed output, but a genuinely ambiguous or semantically wrong result may not be fixable by more prompting. An application that keeps reprompting past a sensible cap never converges; it just accumulates cost. The exam expects you to bound the reprompt loop and escalate the failure that resists correction, exactly as it expects you to bound the retry loop. Both traps are failures to know where a strategy stops applying, which is why every recovery in this knowledge point carries a cap and an escalation path.
Worked example: routing three failures to their recovery
Worked example
An invoice-processing service must recover from three different failures without human intervention where possible, and escalate only what it genuinely cannot resolve.
The first failure is an HTTP 429 during a burst of uploads. This is a transient rate-limit error, so the strategy is retry with exponential backoff: wait, double the delay each attempt, and let the quota window reset. Within a couple of backed-off attempts the call succeeds, and no human is involved.
The second failure is a response whose JSON omits the required invoice_total. This is a model-output error, and a plain retry would likely reproduce the same gap. The strategy is to reprompt with the validation error as feedback, telling the model that invoice_total was missing and must be present. On the reprompt the model returns complete JSON, and the item clears.
The third failure is a scanned invoice so degraded that the model returns contradictory totals on every attempt, and two feedback-carrying reprompts fail to resolve the ambiguity. Continuing to reprompt would loop without converging. The service hits its reprompt cap and escalates the document to a human reviewer. That is the correct outcome: the failure was genuinely ambiguous, so automated recovery is abandoned rather than spun forever.
The lesson is that all three failures were handled by matching the class to its strategy, and that escalation was not a failure of the design but a designed outcome. The retry loop and the reprompt loop were both capped, and the one failure that neither could resolve fell through to a human at a sensible limit rather than consuming the service in an infinite loop.
How this is tested on the CCDV-F exam
Task 4.1 items present a described failure and ask which recovery to apply, or critique a recovery that used the wrong one. The credited answer matches the strategy to the class: backoff for transient and rate-limit errors, a feedback-carrying reprompt for malformed output, and escalation for the unrecoverable or ambiguous. The seductive distractors are the two traps, retrying a deterministic error unchanged, and reprompting a semantic failure without bound.
Answer these items by first fixing the class with error type identification, then reading the proposed recovery against it. Is the error transient? Backoff is right. Is the output malformed? A reprompt with the error is right. Is the failure deterministic or stubbornly ambiguous? Then the only sound answers change the input, fix the code, or escalate, never resend the identical request or loop forever. When a scenario spans multiple steps of an agent and the failing layer is unclear, pair this with trace analysis and problem origin isolation to locate the fault before choosing a recovery, because recovering the wrong layer is just a slower way of not fixing the bug.
A Claude call returns valid, well-formed JSON, but validation shows a required field is missing. The team's current handler simply retries the identical request up to five times. What is the correct recovery?
People also ask
When should I retry a Claude API call versus escalate?
How do I recover from malformed structured output?
What is exponential backoff and when do I use it?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
No videos curated for this concept yet
We are still curating the best official and community videos for this topic.
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.