Your Retry Loop Never Stops: Bounded Retries for LLM Output

July 24, 2026 · Claude Certified Architect (CCA) Prep (part 39)

▶ Watch on YouTube & subscribe to The Stack Underflow

You forced the schema with tool_choice. You validated the result. And then, on the first malformed field, your pipeline did the thing every production incident report starts with: it kept trying, forever, at 2am, burning through your token budget while paging nobody and fixing nothing. A retry loop with no ceiling isn’t resilience — it’s an unbounded liability wearing a resilience costume.

The one-sentence version: A validation-retry loop needs two properties to be production-safe — a hard cap on attempts, and the validation error fed back into the next prompt so each retry is actually informed, not just a repeat of the last guess.

The question

A validation-retry loop keeps retrying a malformed field forever. What’s the best design?

• A) Retry infinitely
• B) Cap retries AND feed the validation error back into the next prompt
• C) Give up on first failure
• D) Ignore the error

Pause here and pick one before you scroll — this is Domain 4 (Prompt Engineering & Structured Output), question 6 of the practice set, and the point is to reason through the mechanism, not to pattern-match the letter.

The answer

B — cap retries, and feed the validation error back into the next prompt. Both halves are load-bearing. A cap without error feedback just retries the same mistake N times before giving up. Error feedback without a cap just delays the infinite loop by giving it better ammunition. You need both.

Here’s the mechanism:

VALIDATE → fail
    │
    ▼
append error to next prompt
  "field 'date' must be ISO 8601 (got: 'next tuesday')"
    │
    ▼
RETRY  (attempt 2 of max N)
    │
    ├── passes validation ──► SUCCEED, return result
    │
    └── fails again ─────────► append new error, RETRY (attempt 3)
                                        │
                                        └── attempt N fails ──► ESCALATE
                                            (log, alert, fallback,
                                             or return to a human)

The loop has exactly one entry point (validate) and two legal exits: success, or escalation once the attempt counter hits its ceiling. There is no third path where the loop just keeps spinning — that path is the bug this question is testing you on.

The “feed the error back” half is what separates a retry from a repeat. If attempt 2 is an identical API call to attempt 1, you’re not retrying, you’re gambling on nondeterminism. What actually works is appending the specific validation failure — the field name, the expected type or format, and what was actually received — into the next request, so the model has new information to correct against:

attempt 1 prompt:  "Extract the appointment date as ISO 8601."
attempt 1 output:  { "date": "next tuesday" }
validation:        FAIL — not ISO 8601

attempt 2 prompt:  "Extract the appointment date as ISO 8601.
                     Your previous answer was 'next tuesday', which is not
                     a valid ISO 8601 date. Return YYYY-MM-DD only."
attempt 2 output:  { "date": "2026-07-28" }
validation:        PASS — return result

The error message is the next prompt’s context, not a log line nobody reads. This is the same “context, not vibes” principle you’ll see across Domain 4 — a validator’s job isn’t just gatekeeping, it’s producing the training signal for the very next call.

Why the other options fail

• A) Retry infinitely — no ceiling means a single persistently malformed field (or a transient upstream issue that never resolves) can spin forever, burning cost and latency with nothing to show for it. Production systems need a defined failure mode, and “runs forever” is not one.
• C) Give up on first failure — this throws away exactly the cases an LLM is most likely to fix on a second attempt: a wrong date format, a string where a number belongs, a field name typo. One failed attempt tells you almost nothing about whether the model can produce a valid answer — it just tells you this particular sample didn’t. Zero retries wastes the easy wins.
• D) Ignore the error — silently passing bad data downstream is the worst outcome on the list. It doesn’t fail loud, it fails quiet, and quiet failures are the ones that show up three weeks later as a corrupted record in someone else’s database, with no error log pointing back to the cause.

The common thread: A and D both remove the cap-or-validate discipline entirely (one loops forever, one skips validation’s consequence), while C removes the retry half. Option B is the only one that keeps both control loops — bounded attempts, and validated gating — intact.

The concept behind it

Zoom out from this one question and the pattern generalizes to any place an LLM’s output has to satisfy a hard constraint before it’s usable: JSON schema conformance, an enum of allowed values, a regex-shaped ID, a foreign-key reference that has to exist in your database. Whenever you’re validating LLM output against a contract, you need the same three components:

A useful mental model: think of the retry loop as a bounded search with feedback, not a dice reroll. Each failed attempt should narrow the space of plausible next outputs, because the model now knows what specifically was wrong. If your retries aren’t narrowing anything — if attempt 5 looks statistically identical to attempt 1 — the loop isn’t doing its job even if it eventually terminates. That’s the deeper reason “cap it” alone (without error feedback) is an incomplete answer: it stops the bleeding but doesn’t actually improve your success rate per attempt.

Picking the retry cap itself is a judgment call, not a magic number — 3 is a common default for user-facing latency-sensitive paths, higher for async/batch pipelines where a few extra seconds don’t matter. The number matters less than the fact that a number exists, is enforced in code (a counter, not “just try again”), and has a defined escalation behind it.

This same pattern shows up any time you compose structured output with something enforcing a contract on it: forcing the shape with tool_choice (so you have something to validate in the first place), tightening the schema so validation actually catches type mismatches, and — when volume is high enough that per-call retries add up — batching the whole pipeline so retries are cheap in aggregate, not just per-request.

FAQ

Is 3 retries the “right” number for a validation loop? There’s no universal right number — it’s a tradeoff between latency tolerance, cost, and how likely the model is to self-correct given a good error message. Three is a common default for synchronous, user-facing calls. What the exam (and production) actually cares about is that the number is finite, enforced, and paired with an escalation path — not that it’s exactly 3.

What should the escalation path do when the retry cap is hit? It depends on the system, but “nothing” is never the answer. Common patterns: log the failure with the full attempt history for debugging, alert if this is happening at an unusual rate, fall back to a safe default value if one exists, or route the case to a human reviewer. The escalation is what keeps a bounded retry loop from becoming a silent data-loss path.

Does feeding the error back into the prompt actually improve the retry, or is it just longer context? It measurably helps, because the model now has a concrete signal — the exact field, the exact expected format, and what it produced instead — rather than being asked to guess again from scratch. A retry with no error feedback is statistically closer to a second independent sample than a correction.

How is this different from just lowering the temperature to get more consistent output? Temperature affects sampling variance, not correctness against a schema. Lowering it might make output more consistent, but consistently wrong is still wrong. Validation-retry with error feedback targets correctness directly; temperature is a separate, weaker lever.

Not affiliated with, authorized, or endorsed by Anthropic. “Claude” and “Claude Certified Architect” are trademarks of Anthropic. These are original practice questions for study, not real exam content — verify current exam details on Anthropic’s official pages.

Where this fits in the CCA series

This question sits in Domain 4 — Prompt Engineering & Structured Output (20% of the exam) — right alongside the other structured-output failure modes: forcing the shape in the first place with How Do You Guarantee Valid JSON? Forcing Structured Output, tightening the schema so a validator actually catches type drift in A Number Comes Back as a String: Validating Structured Output Types, and choosing when the shape is non-negotiable at all in Force the Tool, or Let It Decide? tool_choice Explained. Together they form the “force it, validate it, retry it” chain the exam expects you to reason through end to end.

For the full five-domain map of what’s tested and how the exam is structured, start with the Claude Certified Architect (CCA) Exam Guide. Browse all tutorials for the rest of the series.