One More Try: When Retry Fixes an AI Failure and When It Just Repeats It

A retry button is only honest when the next attempt has a real chance of producing a different result. Stochastic failures — sampling variance, transient timeouts, flaky tool calls — genuinely can resolve on a second try. Deterministic failures — a missing permission, a malformed prompt, an unsupported input — will fail identically every time, and offering retry there just wastes the user's patience.

Quick Answer: Offer a plain retry only when the failure cause is stochastic (sampling variance, network blips, transient tool errors). For deterministic causes (bad input, missing context, policy block), replace retry with a fix-the-input path. After a second failure of any kind, stop repeating the same button — change the offer.

Why Retry Buttons Lie More Often Than They Help

Most retry buttons are copy-pasted from web-era error handling, where "try again" made sense because failures were almost always transient — a dropped packet, a server hiccup. Large language model failures are a different animal: many are reproducible, because the failure is baked into the prompt, the context, or the model's actual competence boundary, not into network conditions.

When a team ships a generic retry button without asking which category a given failure belongs to, they inherit a false promise. The user reads "Try Again" as "this might work differently next time." If the underlying cause is deterministic, it won't — and the second failure reads as the product not listening, not as bad luck.

This distinction is not cosmetic. It changes what the button should say, what happens when it's pressed, and what should happen after it fails again. Get it right and retry becomes a trust-building moment. Get it wrong and it becomes the second data point in a user's decision to stop trusting the tool's error states at all — a theme covered in depth in the complete guide to UX of failure.

Two Failure Families, Not One

Stochastic failures stem from randomness somewhere in the pipeline: temperature-driven sampling variance, a transient rate limit, a flaky retrieval call, a race condition in tool orchestration. Because the underlying process has real entropy, a second attempt draws from a genuinely different distribution of outcomes.

Deterministic failures stem from a fixed condition: the prompt lacks a required field, the user's request exceeds a hard policy boundary, the retrieved context is empty because the source document doesn't exist, or the model has a structural blind spot for that task type. None of these change on re-roll. Retrying is functionally identical to asking the same closed door to open by knocking again.

The Decision Rule: Tie Retry to Cause, Not Symptom

The single most useful discipline in error-recovery design is classifying failure by cause before choosing a recovery affordance, rather than defaulting to retry because it's the easiest control to build. A button is cheap; a wrong button is expensive in trust.

Use this rule of thumb: if you can articulate what specifically would be different on attempt two, retry is honest. If your honest answer is "nothing, unless the user changes something," retry alone is dishonest — you need a different primary action.

Treat "mixed" causes as deterministic by default. If you can't confidently say the retry will differ, design for the case where it won't — that's the safer failure mode to plan around.

A Quick Diagnostic Before You Design the Button

Before writing any retry copy, answer three questions about the failure you're handling:

1. Does the failure trace to a random draw (temperature, network jitter, a race condition) or a fixed condition (missing data, a hard policy rule, a capability gap)?
2. Did the same input produce a different outcome in testing, or does it fail the same way every time you run it?
3. Would changing the model, the prompt, or the input meaningfully change the odds — and which of those three is the actual lever?

If the answer to (3) is "none of them, reliably," you're looking at a case for graceful decline, not retry — a distinction the guide to designing for hallucination failure modes treats as its own design problem, separate from recoverable errors.

Three Retry Variants and When Each Earns Its Keep

Not all retries are the plain "run it again" button. Three distinct variants exist, and each is honest for a different cause profile.

Plain retry re-runs the identical request with no changes, relying purely on sampling variance or transient conditions clearing. It's appropriate only for genuinely stochastic causes — rate limits, timeouts, sampling noise on a low-stakes generation. Using plain retry on a deterministic cause is the single most common ai retry ux mistake, because it's the cheapest to build and the easiest to reach for by default.

Retry-with-tweak changes one variable before re-running — a clarifying detail added to the prompt, a narrower scope, an example of the expected output format. This is the right choice when the failure is ambiguity-driven: the model wasn't wrong so much as under-specified. It converts a dead-end retry into a small, honest negotiation with the user about what changed.

Retry-with-different-model swaps the underlying model, typically escalating from a fast/cheap model to a more capable one, or from a general model to one better suited to the task (code, structured extraction, long context). This is the correct move when the failure is a competence-boundary issue: the first model structurally can't do the task well, and no amount of re-rolling the same weights will fix that.

Why Variant Choice Is Also a Trust Signal

Offering the wrong variant is its own honesty failure, even if some variant would have worked. A plain retry offered for a capability-boundary failure implicitly tells the user "this was bad luck," when the truer statement is "this model can't do this reliably." Naming the actual cause in the copy, even briefly, is what separates an honest retry from a decorative one.

This is also where confidence communication intersects with retry design: if the system already displays some confidence signal, the retry copy should be consistent with it, not contradict it. The guide to confidence displays without scaring users covers how to phrase that signal without inducing false alarm or false reassurance.

Change the Offer After the Second Failure

One retry is a hypothesis. A second failure of the same kind is data — and the data says the current recovery path is wrong. The single most important pattern in this space is that the second failure should never produce the same button again.

Looping the identical retry control after two consecutive failures does two kinds of damage. It tells the user the product either didn't notice the pattern or doesn't care, and it burns the user's remaining patience on a control that has already proven itself unreliable for this case.

What Should Change After Failure Two

1. Escalate the variant. If attempt one was plain retry, attempt two's offer should be retry-with-tweak or retry-with-different-model — never the same plain button again.
2. Surface the cause explicitly. State what seems to be going wrong, even in plain language: "this type of request tends to need more context" or "this is timing out under current load."
3. Offer a non-retry exit. Give the user a path that doesn't involve trying again at all: save the draft, escalate to a human, or narrow the request into a smaller piece that's more likely to succeed.
4. Never silently keep retrying in the background without the user's knowledge — a spinner that hides three internal retries and then fails is its own trust violation, independent of the retry-variant question.

A good heuristic: think of retry attempts as a small budget, not an infinite loop. Spend attempt one on the cheapest honest fix. Spend attempt two on the most likely honest fix. After that, stop spending the user's attention and offer a different kind of help.

Designing the Retry Copy Itself

Retry copy fails most often by being generic — "Something went wrong. Try again." — which answers neither "why" nor "will this help." Effective retry copy does three things in one or two short sentences: names what happened, states whether trying again is expected to differ, and says what the button will actually do differently, if anything.

Compare a generic version against a cause-aware one:

The cause-aware version costs almost nothing extra in engineering effort — it's largely a copywriting and state-tracking exercise, not a new capability. Most of the honesty gap in retry UX is a writing gap, not a technical one.

Prodinja's Retry Scaffold

Prodinja's UX of Failure Timeout pattern in the Studio is built around exactly this problem: it gives you a copy scaffold for a retry state that sets honest expectations up front about whether trying again is likely to differ, rather than defaulting to a generic "try again" every time. It's designed as a starting structure you adapt to your own failure taxonomy, not a finished answer — the judgment about which of your failures are stochastic versus deterministic still has to come from you, ideally informed by the same jobs-based thinking laid out in the complete guide to jobs to be done, since the retry offer should match the job the user was actually trying to get done, not just the technical error.

How This Fits the Larger Error-Recovery Picture

Retry design doesn't live in isolation — it's one moment inside a longer arc of how a user experiences an AI product's failures over a session, and sometimes over many sessions. A well-designed retry that appears at the wrong point in that arc, or contradicts the emotional tone set earlier, still reads as dishonest even if the copy itself is accurate.

Map failure-recovery moments against the complete guide to customer journey mapping to see where retry decisions cluster — usually right after a trust dip, which is exactly when the honesty of the recovery offer matters most. A retry that overpromises at a low-trust moment does more damage than the same overpromise earlier in a session.

Two design principles carry across all of this:

• Never offer a control whose outcome you can't honestly characterize. If you don't know whether a retry will differ, that's a signal to investigate the failure cause further, not to ship a generic button.
• Treat repeated failures as an escalation ladder, not a loop. Each subsequent failure should narrow toward either a fix or an honest exit — never repeat the identical ask.

Key Takeaways

• Classify failure cause before choosing a recovery control — stochastic causes (sampling variance, transient errors) justify retry; deterministic causes (missing input, policy limits, capability gaps) do not.
• Three retry variants exist for a reason: plain retry for stochastic causes, retry-with-tweak for ambiguity, retry-with-different-model for capability-boundary failures.
• A second failure must change the offer, not repeat the same button — escalate the variant, name the cause, or provide a non-retry exit.
• Retry copy should state what would actually differ on the next attempt, or admit that nothing would — generic "Try Again" copy is dishonest by omission more often than by intent.
• Silent background retries erode trust even when they eventually succeed, because they hide information the user is entitled to.
• Retry design connects to confidence displays and journey mapping — an honest retry offer at the wrong emotional moment in a session still reads as a broken promise.