LearnAdvanced Agents & RetrievalAgent Failure & Recovery

🤖HardLLM Agents & Tool Use

Agent Failure & Recovery

Add validation checks, retries, checkpointed recovery, state reconciliation, loop breakers, and graceful degradation when LLM agents hallucinate, stall, or drift from their tools.

48 min read

Learning path

Step 132 of 196 in the full curriculum

Agent Memory & Persistence Recursive Language Models (RLM)

Personalize this lesson

Adapt explanations and teaching visuals to your background and preferred voice.

A deploy-status agent gets one plain question: "What happened to run RUN-842?" It should look up a CI (continuous integration) run, read the failing job, and give you a short summary. Instead, it might call a tool that doesn't exist, send the wrong field name, read the same result until its budget runs out, or say a rollback succeeded after the write timed out. The response can still sound calm and complete.

Agent memory can carry scoped context across that run, but it can't decide whether a recalled note is still true, whether a timed-out write committed, or whether a generated tool call is safe. An agent runtime is the trusted loop around the model: it validates proposals, executes allowed tools, records observations, and checks claims before they leave the system. ReAct interleaved reasoning and actions,^{[1]Reference 1ReAct: Synergizing Reasoning and Acting in Language Models.https://arxiv.org/abs/2210.03629} while Toolformer explored learned API use.^{[2]Reference 2Toolformer: Language Models Can Teach Themselves to Use Tools.https://arxiv.org/abs/2302.04761} Neither makes those runtime checks optional.

We'll stay with RUN-842 and follow one failure at a time. Start by separating a plausible answer from verified state, then add validation, retry policy, circuit breakers, checkpointed resume, and bounded fallback. Success isn't "never fail." It means keeping failure visible, bounded, and reversible before a generated claim or an uncertain write reaches a user.

Why agent failures require runtime checks

Once a model can choose tools, tests alone can't police every generated path. Ask what must be checked while RUN-842 is in flight. The comparison makes the extra runtime boundary visible:

Failure Mode	Traditional Software	LLM Agent	Recovery Strategy
Invalid input	Rejected with error message	Agent hallucinates a "valid" response	Validation checks: Schema checks before tool execution
Infinite loop	CPU spin or runaway resource use	Agent keeps calling the same tool with slight variations	Semantic Loop Detection: Hash canonicalized actions and compare intent similarity
Service unavailable	Connection timeout	Agent fabricates the API response	Circuit Breaker: Fail fast and fallback to static logic
Logic error	Wrong result, sometimes unnoticed	Plausible but unsupported answer or tool choice	Verifier + source check: Validate against deterministic evidence where available

The extra risk comes from generated actions and answers. A small input or sampling change can make the same agent choose a different tool or interpret the same observation as success. Boundary checks catch known errors; runtime signals also need to catch a trajectory that is quietly getting worse.

You can't unit-test every conversational path. Offline eval harnesses still matter, but they miss generated branches you didn't sample. Runtime guardrails fill that gap with schema checks, allowlists, step limits, loop detection, budgets, verifiers, and side-effect reconciliation. When the model drifts, the surrounding system either steers it back or stops before the next untrusted write.

Why small per-step errors compound

Put numbers on the risk before naming the equation. A task with 40 required steps can succeed less than half the time when each step succeeds 98% of the time. In the toy model, every step is required and the steps are independent, so task success is:

P(\text{success}) \approx p^{n}

Here, p is the success probability for one step and n is the number of required steps. The product decays fast, even when each individual step looks reliable:

Per-step success `p`	5 steps	20 steps	50 steps
99%	95%	82%	61%
95%	77%	36%	8%
90%	59%	12%	0.5%

A 95%-reliable step can look acceptable in a one-shot demo and become nearly useless in this 50-step model. Real failures are rarely independent or equally likely. One expired credential can break every later call, while a checkpoint can make some failures recoverable. Treat the equation as a warning about long chains, not as a production reliability estimator.

The toy model isn't a benchmark. METR's March 2025 task-horizon analysis measured the length of software tasks agents could complete at a given reliability level. On that suite, Claude 3.7 Sonnet reached roughly one hour of human task time at 50% reliability.^{[3]Reference 3Measuring AI Ability to Complete Long Taskshttps://metr.org/blog/2025-03-19-measuring-ai-ability-to-complete-long-tasks/} That's a dated snapshot of one model on one benchmark, not a per-step estimate or a current leaderboard claim. It still shows why a capability demo and a dependable long-running workflow are different engineering targets.

The $\tau$ -bench paper gives the same warning from another angle. Its retail and airline tasks involve an agent, a user, and tools. GPT-4o got below 25% pass^8 in retail: fewer than a quarter of tasks succeeded on all eight sampled trials.^{[4]Reference 4Tau-Bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domainshttps://arxiv.org/abs/2406.12045} A system can look capable on one run and still be inconsistent across repeats.

Every defense in this lesson attacks that product in one of two ways. It can raise per-step reliability p with validation, action contracts, or structured feedback. Or it can shrink the number of unrecovered steps with retries, fallbacks, checkpoints, loop breakers, and escalation. You can't make p = 1, so build a system that survives the steps where p < 1.

The deploy-status agent

The equation explains why a long trajectory is fragile. Now trace one short task so each boundary has a concrete place in the story. The ReAct agent loop supplies the plan-act-observe pattern, and function calling lets a model propose a call against a tool schema.

A single ReAct-style agent receives a developer question, plans a tool call, executes it, and observes the result:

Developer asks: "What happened to run RUN-842?"
Agent reasons: "I need to query CI status for run RUN-842."
Agent acts: Calls get_run with {"id": "RUN-842"}.
Agent observes: "Status: failed, failing job: unit-tests."
Agent answers: "Run RUN-842 failed in unit-tests."

That happy path hides three separate decisions: choose a registered tool, serialize arguments that satisfy its contract, and stop only after verified evidence arrives. Any one can fail. The sections that follow keep the same run ID while adding one symptom and one defense at a time.

Classify failure before choosing recovery

Recovery follows the boundary that failed, not a label such as "the model was wrong." A timeout shows why labels aren't enough: a read may be safe to retry, while a write must be reconciled before any replay. Use the observable evidence to choose the first safe response:

Failed boundary	Observable evidence	Safe first response
Proposal	Unknown tool, invalid arguments, forbidden action	Reject before execution; return structured correction feedback
Dependency	Timeout, rate limit, or temporary service failure	Retry only if the fault is transient and the operation is safe to repeat
External state	Timeout after a write; local state disagrees with source of truth	Reconcile using an operation ID or idempotency key before replay
Progress	Repeated call, repeated intent, or exhausted budget	Stop, narrow capabilities, or escalate with trace evidence
Result	Empty, stale, or unsupported answer	Validate evidence; degrade explicitly rather than inventing an answer

Read the table as an incident triage order. First ask whether a side effect may already have happened. If not, classify the dependency fault, then look for a trusted checkpoint before deciding to stop or escalate.

Diagram showing Failed step, Write uncertain?, Reconcile, and Transient fault?. — Failed step, Write uncertain?, Reconcile, and Transient fault?.

Recovery choice depends on side-effect uncertainty, fault class, and checkpoint validity. Retry is only one branch.

Worked example: the wrong parameter

Start with a malformed proposal that never reaches external state. get_run expects {"id": "RUN-842"}, but the deploy-status agent sends {"run_id": "RUN-842"} instead. The API rejects it with a 400 Bad Request: Missing required parameter 'id'.

A naive agent sees the error and sends the exact same call again. Nothing changed, so it gets the same 400. That's the "just try again" anti-pattern: without a reason it can act on, the agent has no basis for changing its proposal.

Feed the error back as structured feedback rather than a raw exception string. The agent can compare its proposal with the tool schema, correct the key name, and try again. This is a repair retry: validation supplies new information before another model call. It doesn't require the longer-lived episodic reflection used by Reflexion, which we revisit later.

The corrected trace is short enough to inspect by hand:

text

Step 1: get_run({"run_id": "RUN-842"}) -> 400 Bad Request: Missing required parameter 'id'.
Step 2: Agent reflects: "I used 'run_id' but the schema requires 'id'."
Step 3: get_run({"id": "RUN-842"}) -> 200 OK: Status failed, failing job unit-tests.

The retry must carry new information. The same prompt with the same context will likely produce the same wrong answer. You need to tell the model exactly what went wrong in a format it can act on.

Validate arguments before execution

Strict JSON schema validation gives this failure a clean boundary. Model APIs often support tool calling or structured outputs, but you still validate arguments before execution and apply authorization separately. Production code often uses Pydantic or Zod. The standard-library function below makes the contract visible: get_run accepts only {"id": "RUN-842"}, rejects unknown keys, and returns a one-line correction instead of executing.

validate-run-tool-arguments.py

import re

class ToolCallError(Exception):
    pass

RUN_ID = re.compile(r"^RUN-[0-9]{3,}$")

def validate_tool_call(raw_args: dict[str, object]) -> dict[str, str]:
    unknown = [key for key in raw_args if key != "id"]
    if unknown:
        raise ToolCallError("get_run requires valid field: id")
    run_id = raw_args.get("id")
    if not isinstance(run_id, str) or not RUN_ID.fullmatch(run_id):
        raise ToolCallError("get_run requires valid field: id")
    return {"id": run_id}

try:
    validate_tool_call({"run_id": "RUN-842"})
except ToolCallError as exc:
    print("rejected:", exc)
print("accepted:", validate_tool_call({"id": "RUN-842"})["id"])

Output

rejected: get_run requires valid field: id
accepted: RUN-842

Common mistake: Returning a raw Python traceback to the LLM. Stack traces are noisy, and the model will often retry the same mistake after skimming them. Agentic debugging means sending the smallest root-cause sentence that changes the next proposal, not a 50-line trace.

Tool call hallucination

Shape validation still isn't enough. A payload can be well-formed and name a tool that no runtime has registered. Tool misuse has two concrete forms: the model invents a tool, or it emits malformed arguments for a real one. When context is incomplete, a plausible-sounding name can replace a request for clarification.

For example, our deploy-status agent might output:

text

// Model generates this:
{"tool": "search_runs", "args": {"query": "run RUN-842", "format": "json"}}
// But the actual API expects:
{"tool": "get_run", "params": {"id": "RUN-842"}}

search_runs sounds reasonable, but it isn't in the registry. Without an allowlist check, the runtime either sends the call to a nonexistent endpoint or lets the model infer a nearby capability. Either response creates an error the agent may misread.

Reject calls outside the tool registry

Use the same schema validation from above, plus a tool allowlist. Before executing any tool call, check whether the requested tool name exists in the registered tool set. If it doesn't, return a clear error: Tool 'search_runs' is not available. Available tools: get_run, get_logs, suggest_alternative.

This transforms an ambiguous failure into structured feedback the agent can use to self-correct.

Infinite loops (the "stuck agent")

Fixing one proposal doesn't guarantee progress. A valid call can repeat forever, either exactly or with new wording. A deploy-status agent might produce this trace:

text

Step 1: get_run({"id": "RUN-842"}) -> "Failed in unit-tests"
Step 2: get_run({"id": "RUN-842"}) -> "Failed in unit-tests"
Step 3: get_run({"id": "RUN-842"}) -> "Failed in unit-tests"
... (continues forever)

Or with semantic rephrasing:

text

Step 1: get_run({"id": "RUN-842"}) -> "Failed in unit-tests"
Step 2: search("status for run RUN-842") -> "Failed in unit-tests"
Step 3: search("RUN-842 failing job") -> "Failed in unit-tests"
Step 4: search("where is run RUN-842") -> "Failed in unit-tests"
... (continues forever)

The missing ingredient is an explicit progress signal. A vague stopping condition, weak error feedback, or absent state check lets the model propose the same approach with slightly different wording. The model isn't required to prove that its new action differs from the failed one, so the runtime has to detect repetition.

Detect repeated actions before the hard cap

A step cap is too late. LoopBreaker.check looks at a proposed tool name and arguments before the call runs. It combines exact-call hashes, same-tool streaks, and approximate intent similarity, then returns True when the next call would cross a loop threshold.

defense-strategy.py

import difflib
import hashlib
import json
import re

class LoopBreaker:
    def __init__(
        self,
        max_steps: int = 15,
        max_identical: int = 3,
        same_tool_streak: int = 5,
        semantic_threshold: float = 0.9,
    ):
        self.max_steps = max_steps
        self.max_identical = max_identical
        self.same_tool_streak = same_tool_streak
        self.semantic_threshold = semantic_threshold
        self.tool_call_history: list[dict[str, str]] = []

    def _stable_call_hash(self, tool_name: str, args: dict[str, object]) -> str:
        canonical_args = json.dumps(
            args,
            sort_keys=True,
            default=str,
            separators=(",", ":"),
        )
        return hashlib.sha256(f"{tool_name}:{canonical_args}".encode("utf-8")).hexdigest()

    def _intent_text(self, tool_name: str, args: dict[str, object]) -> str:
        argument_text = " ".join(str(value).strip().lower() for value in args.values())
        identifiers = sorted(set(re.findall(r"\b[a-z]+-\d+\b", argument_text)))
        combined = f"{tool_name.replace('_', ' ')} {argument_text}"

        # Normalize tool-specific phrasing into a task-level intent.
        if identifiers and "run" in combined:
            return f"lookup run {' '.join(identifiers)}"

        fields = [tool_name.replace("_", " ")]
        fields.extend(identifiers)
        fields.extend(
            str(args[key]).strip().lower()
            for key in ("query", "prompt", "text", "task")
            if args.get(key)
        )
        return " ".join(fields)

    def check(self, tool_name: str, args: dict[str, object]) -> bool:
        """Returns True if a loop is detected."""
        call = {
            "tool": tool_name,
            "args_hash": self._stable_call_hash(tool_name, args),
            "intent_text": self._intent_text(tool_name, args),
        }

        if len(self.tool_call_history) >= self.max_steps:
            return True

        identical_attempts = 1 + sum(
            1 for h in self.tool_call_history if h["args_hash"] == call["args_hash"]
        )
        if identical_attempts >= self.max_identical:
            return True

        same_tool_attempts = 1
        for h in reversed(self.tool_call_history):
            if h["tool"] != tool_name:
                break
            same_tool_attempts += 1
        if same_tool_attempts >= self.same_tool_streak:
            return True

        recent_window = self.tool_call_history[-(self.same_tool_streak - 1):]
        similar_attempts = 1 + sum(
            1
            for h in recent_window
            if h["intent_text"]
            and difflib.SequenceMatcher(
                None, h["intent_text"], call["intent_text"]
            ).ratio() >= self.semantic_threshold
        )
        if similar_attempts >= self.max_identical:
            return True

        # Only append after checks to avoid polluting history with the failing call
        self.tool_call_history.append(call)
        return False

breaker = LoopBreaker(max_identical=3)
print("first:", breaker.check("get_run", {"id": "RUN-842"}))
print("second:", breaker.check("get_run", {"id": "RUN-842"}))
print("third:", breaker.check("get_run", {"id": "RUN-842"}))

cross_tool = LoopBreaker(max_identical=2)
print("cross-tool first:", cross_tool.check("get_run", {"id": "RUN-842"}))
print("cross-tool repeat:", cross_tool.check("search", {"query": "where is run RUN-842"}))

Output

first: False
second: False
third: True
cross-tool first: False
cross-tool repeat: True

The thresholds include the current attempt. That detail matters: an off-by-one bug burns one more tool call, token round-trip, and latency spike before the breaker trips.

The task-level normalization makes the runnable guard catch get_run({"id": "RUN-842"}) versus search("where is run RUN-842") even though the tool names and argument keys differ. For broader production traffic, replace or augment this narrow normalization with embeddings over a compact task and state summary. Evaluate that semantic detector on both true loops and legitimate follow-up actions against the same entity.

Common mistake: Assuming that max_steps alone is enough to prevent loops. A step limit of 15 doesn't stop an agent from wasting 15 steps (and thousands of tokens) on a futile loop. Semantic loop detection stops the bleeding early, often after 2-3 repeated attempts.

Token budget exhaustion

A loop can stop making progress before it hits the hard step cap, while still consuming context and money. Consider a 20-step task whose runtime appends every tool call and observation to one transcript. Each prompt grows as history accumulates, and later turns resend most of what came before. The final step includes the previous 19 steps, so total input spend can grow roughly quadratically rather than like 20 isolated calls.

Left unchecked, that growth can overflow the context window, trigger provider rejection or truncation, and inflate the API bill. A subtle loop can burn through tokens long before an operator sees a clear error.

Use soft and hard budgets

Treat budget as two layers. A hard limit is a circuit breaker: if tokens or estimated cost cross the cap, the run stops. Soft management watches the window earlier and compact validated state before that stop is the only option.

TokenBudget.consume records the input and output tokens from a completed generation, then raises BudgetExhausted if a cap is crossed. Pair that post-call accounting with a preflight context estimate and a provider-side output cap so one generation can't overshoot too far.

defense-strategy-2.py

class BudgetExhausted(Exception):
    pass

class TokenBudget:
    def __init__(
        self,
        max_tokens: int = 100_000,
        max_cost_usd: float = 1.0,
        pricing: dict[str, dict[str, float]] | None = None,
    ):
        self.max_tokens = max_tokens
        self.max_cost = max_cost_usd
        self.used_tokens = 0
        self.estimated_cost = 0.0
        self.pricing = pricing or {}

    def consume(self, input_tokens: int, output_tokens: int, model: str):
        """Updates token counts and raises an error if budget is exceeded."""
        self.used_tokens += input_tokens + output_tokens
        self.estimated_cost += self._calculate_cost(input_tokens, output_tokens, model)

        # Hard stop to prevent runaway billing
        if self.used_tokens > self.max_tokens:
            raise BudgetExhausted(f"Token limit exceeded: {self.used_tokens}/{self.max_tokens}")
        if self.estimated_cost > self.max_cost:
            raise BudgetExhausted(f"Cost limit exceeded: ${self.estimated_cost:.2f}/${self.max_cost:.2f}")

    def _calculate_cost(self, input_tokens: int, output_tokens: int, model: str) -> float:
        rates = self.pricing.get(model)
        if rates is None:
            raise BudgetExhausted(f"Pricing missing for model: {model}")

        input_cost = (input_tokens / 1_000_000) * rates["input"]
        output_cost = (output_tokens / 1_000_000) * rates["output"]
        return input_cost + output_cost

budget = TokenBudget(
    max_tokens=1_000,
    max_cost_usd=0.01,
    pricing={"agent-model": {"input": 1.0, "output": 2.0}},
)
budget.consume(200, 50, "agent-model")
print("used tokens:", budget.used_tokens)
try:
    budget.consume(900, 20, "agent-model")
except BudgetExhausted as exc:
    print("blocked:", str(exc).split(":")[0])

Output

used tokens: 250
blocked: Token limit exceeded

Production tip: When the budget approaches a configured soft threshold, stop optional exploration and compact only validated facts and pending work. A generated summary is lossy and can't replace the durable record of writes, approvals, or idempotency keys.

Cascading failures in multi-agent systems

Budgets bound one run. A multi-agent graph adds another risk: a bad handoff can turn one local mistake into a chain of confident decisions. In a supervisor-worker DAG (directed acyclic graph), failures usually spread because later nodes trust unsupported output or because local state drifts from the source of truth after a partial side effect.

Here's a failure chain on RUN-842:

Monitor agent: "CI check passed" (invents a test result that never happened).
Gate agent: "Tests passed, so approve deployment" (treats the invented check as source-of-truth state).
Responder agent: "Run RUN-842 passed yesterday" (sends a confident user-facing answer grounded in false state).

A second version is worse because it looks operationally healthy. Suppose rollback_deploy times out after the deployment controller already committed the rollback. If the orchestrator records that step as failed and retries, the duplicate side effect leaves agent state out of sync with production.

Validate handoffs and reconcile writes

Pass agent output across a boundary only after verification, and never treat a timed-out write as "nothing happened."

Format and authorization checks should be deterministic. Operational facts should be checked against their source of truth. A model-based critic can flag candidates for review, but it can't prove that RUN-842 passed or that a rollback committed. If validation fails, halt and either request a corrected proposal or escalate. For side-effecting calls, add read-after-write reconciliation and idempotency keys before telling downstream agents the action succeeded.

validated_handoff runs those checks. Each validator returns a ValidationResult. If every check passes, the original output continues. If any check fails, the function returns a structured error for retry or review instead of poisoning the gate agent.

defense-strategy-3.py

from dataclasses import dataclass
from typing import Callable

@dataclass
class ValidationResult:
    valid: bool
    reason: str = ""

Validator = Callable[[dict[str, object]], ValidationResult]

def validated_handoff(
    output: dict[str, object],
    validators: list[Validator],
) -> dict[str, object]:
    """Validate agent output before passing it to the next agent."""
    for validator in validators:
        result = validator(output)
        if not result.valid:
            return {
                "status": "validation_failed",
                "error": result.reason,
                "fallback": "Request human review of this output",
            }
    return output

def require_ci_evidence(output: dict[str, object]) -> ValidationResult:
    if output.get("claim") == "ci_passed" and output.get("ci_status") != "passed":
        return ValidationResult(False, "CI claim lacks source-of-truth evidence")
    return ValidationResult(True)

blocked = validated_handoff(
    {"claim": "ci_passed", "run_id": "RUN-842", "ci_status": "missing"},
    [require_ci_evidence],
)
print(blocked["status"], blocked["error"])
passed = validated_handoff(
    {"claim": "ci_passed", "run_id": "RUN-842", "ci_status": "passed"},
    [require_ci_evidence],
)
print("handoff:", passed["claim"])

Output

validation_failed CI claim lacks source-of-truth evidence
handoff: ci_passed

External service failures

External faults split into transient failures (429, timeouts, brief 503s) and outages that persist after the retry window. An agent feels the difference more sharply than a single-request client because one user question can fan out into several model and tool calls. Late turns also carry more context, so a run can hit a token-per-minute quota even when request count looks normal.

Retry only classified transient faults

Before adding a retry, ask two questions: is the fault transient, and is the operation safe to repeat? For transient network and rate-limit errors, use exponential backoff with jitter. Immediate retries tend to hit the same overload; jitter spreads attempts across time instead of letting a fleet retry in lockstep.^{[5]Reference 5Exponential Backoff And Jitterhttps://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/}

Amazon Web Services (AWS)'s "full jitter" form sleeps a random time in [0, min(cap, base * 2**(attempt-1))]. A 429, 502/503, or timeout is only a retry candidate: provider guidance must permit the retry, and the operation must be safe to repeat. Respect Retry-After when available. Keep a 400 schema error or 401 auth failure off this path.

The retry helper classifies those faults, then retries with full jitter. Its fake clock exposes two retries without making you wait on real sleeps. Libraries such as Tenacity wrap the same idea; the point is the classification boundary, not the decorator.

retry-with-full-jitter.py

import random

class RetryableModelError(Exception):
    pass

class RateLimitExceeded(RetryableModelError):
    pass

class UpstreamTimeout(RetryableModelError):
    pass

class UpstreamUnavailable(RetryableModelError):
    pass

def normalize_provider_error(exc: Exception) -> Exception:
    status_code = getattr(exc, "status_code", None)
    message = str(exc).lower()
    if status_code == 429 or "rate limit" in message:
        return RateLimitExceeded(str(exc))
    if isinstance(exc, TimeoutError) or "timeout" in message:
        return UpstreamTimeout(str(exc))
    if status_code in {502, 503, 504} or "temporarily unavailable" in message:
        return UpstreamUnavailable(str(exc))
    return exc

def call_llm_with_retry(
    call,
    *,
    attempts: int = 3,
    base: float = 1.0,
    cap: float = 30.0,
    rng: random.Random | None = None,
    sleep=lambda _seconds: None,
):
    """Retry transient faults with full jitter. Deterministic failures raise immediately."""
    rng = rng or random.Random(0)
    last_error: Exception | None = None
    for attempt in range(1, attempts + 1):
        try:
            return call()
        except Exception as exc:
            normalized = normalize_provider_error(exc)
            last_error = normalized
            retryable = isinstance(normalized, RetryableModelError)
            if not retryable or attempt == attempts:
                raise normalized from exc
            delay = min(cap, base * (2 ** (attempt - 1)))
            sleep(rng.uniform(0, delay))
    raise last_error or RuntimeError("retry loop exited without a result")

class FakeClock:
    def __init__(self) -> None:
        self.slept: list[float] = []

    def sleep(self, seconds: float) -> None:
        self.slept.append(seconds)

def make_flaky(failures_before_success: int):
    remaining = {"n": failures_before_success}

    def call() -> str:
        if remaining["n"] > 0:
            remaining["n"] -= 1
            exc = Exception("rate limit")
            exc.status_code = 429
            raise exc
        return "RUN-842 failed in unit-tests"

    return call

clock = FakeClock()
result = call_llm_with_retry(
    make_flaky(2),
    attempts=3,
    rng=random.Random(1),
    sleep=clock.sleep,
)
print("result:", result)
print("retries:", len(clock.slept))

Output

result: RUN-842 failed in unit-tests
retries: 2

Notice what this helper doesn't repair. If the model keeps making the same schema mistake, the next attempt needs better information instead of more time. A concise validation error or tool-rejection reason is usually enough for that local repair. Reflexion is a broader, memory-backed pattern for learning from task feedback across trials, not a name for every corrected retry.

Prefer typed SDK exceptions and provider response headers in production. The normalizer above keeps a message fallback only to show the classification boundary without coupling the lesson to one SDK.

Failover must preserve the payload contract

A 429 or dead endpoint may route traffic to a backup model from the same provider or a second provider. That can improve availability, but it changes the correctness question: can the backup produce the same contract? Strict-schema support, JSON wrappers, field names, and function arguments vary across models and providers.

Validate primary and fallback responses against one canonical schema before dispatch. Give each route an adapter that maps its native output into that schema. Without that adapter, a malformed or plausible-but-wrong argument can reach a tool. If the fallback can't satisfy the contract, correct or escalate the validation failure. Never forward the payload unchanged.

Retry, resume, or roll back?

External faults are where retry logic usually starts, but the same decision tree applies everywhere. A retry is appropriate only when the failure is transient and nothing important has committed. A 429, 503, or dropped connection usually fits that pattern. A poisoned context or partial side effect doesn't.

Suppose the agent believes "rollback queued" even though the tool call timed out. Replaying the next step can duplicate production changes or make later reasoning depend on false state. The transport error tells you how the call ended, not what happened in the outside world.

Durable runtimes handle this with checkpoints rather than blind replay. LangGraph persists graph state as checkpoints keyed by thread_id and resumes from a saved super-step boundary.^{[6]Reference 6LangGraph Persistencehttps://docs.langchain.com/oss/python/langgraph/persistence} Temporal persists workflow execution state in event history and replays deterministic workflow code after failures.^{[7]Reference 7Temporal Workflow Execution Overviewhttps://docs.temporal.io/workflow-execution} Both patterns let you resume from the last confirmed-good boundary instead of restarting a long run from scratch.

Use three recovery paths:

Retry when the failure is transient and the step is side-effect free.
Resume from a checkpoint when prior state is still valid but expensive to recompute.
Reconcile or roll back when the failure happened around a non-idempotent side effect such as triggering a rollback, mutating a feature flag, or posting an incident update.

The small classifier below turns that distinction into an executable choice. An uncertain write never enters the ordinary retry path, even when its transport error looks transient.

choose-recovery-path.py

def recovery_path(error: str, side_effect_status: str, checkpoint_valid: bool) -> str:
    if side_effect_status == "uncertain":
        return "reconcile before replay"
    if checkpoint_valid and error == "worker_restarted":
        return "resume checkpoint"
    if side_effect_status == "none" and error in {"429", "503", "timeout"}:
        return "retry with backoff"
    return "stop or escalate"

print("lookup timeout:", recovery_path("timeout", "none", False))
print("rollback timeout:", recovery_path("timeout", "uncertain", True))

Output

lookup timeout: retry with backoff
rollback timeout: reconcile before replay

Two timed-out RUN-842 tool calls side by side. get_run has no side effect, so recovery retries with jitter. rollback_deploy is an uncertain write with idempotency key rb-842-1, so recovery reconciles against the deployment controller before any replay. — Both calls timed out on RUN-842. The lookup can retry because nothing committed. The rollback can't, because the deployment controller may already have applied rb-842-1.

Production tip: Pair checkpoints with idempotency keys for outbound side effects. Resume must be safe even if the previous attempt failed after the external system committed but before your agent recorded success.

Action-contract disconnect

Ask whether the action that will execute still matches the task the system accepted. A dangerous failure happens when the agent's proposed operation diverges from that contract. The two common states are a wrong tool choice despite a valid request and wrong argument serialization despite choosing the right tool.

Consider our deploy-status agent. Its structured intent says lookup_run for RUN-842. However, the emitted tool call might target a create_release tool or provide a different run ID, producing irrelevant results while the response text still sounds plausible.

Generated explanations don't constrain generated tool payloads. A model may describe a reasonable plan yet emit an unsupported parameter or a different identifier. Validate the executable payload against the task contract instead of asking for hidden reasoning or trusting a confident explanation.

Admit only actions that match the contract

The primary defense is execution verification: compare the proposed tool call to a structured task contract before execution. A critic model can help triage ambiguous output, but deterministic tool, identifier, permission, and schema checks should block clear violations.

validate-action-contract.py

class ActionMismatch(Exception):
    pass

def validate_action_contract(
    task_contract: dict[str, object],
    tool_name: str,
    tool_args: dict[str, object],
    allowed_tools: set[str],
) -> str:
    if tool_name not in allowed_tools:
        raise ActionMismatch("tool not allowed")
    if task_contract["intent"] == "lookup_run" and tool_name != "get_run":
        raise ActionMismatch("tool does not match intent")
    if tool_args.get("id") != task_contract["run_id"]:
        raise ActionMismatch("run ID changed")
    return "admitted"

contract = {"intent": "lookup_run", "run_id": "RUN-842"}
print("lookup:", validate_action_contract(contract, "get_run", {"id": "RUN-842"}, {"get_run"}))
try:
    validate_action_contract(contract, "create_release", {}, {"get_run"})
except ActionMismatch as exc:
    print("drift:", exc)

Output

lookup: admitted
drift: tool not allowed

When a repair becomes Reflexion

Action validation fixes a malformed call. What if the call is valid but the strategy still produces no new evidence? The Reflexion paper describes an agent that turns task feedback into a verbal reflection, stores that reflection in episodic memory, and uses it to guide later trials.^{[8]Reference 8Reflexion: Language Agents with Verbal Reinforcement Learning.https://arxiv.org/abs/2303.11366} Its defining feature isn't the word "critique." It's the feedback-to-memory loop across attempts: Attempt -> task feedback -> verbal reflection -> episodic memory -> next attempt.

The wrong-field example doesn't need this machinery because its validator already provides the fix. Reflexion becomes useful when a failure is safe to revisit but the diagnosis is strategic rather than syntactic. Suppose the deploy agent repeatedly reads the same summary endpoint and still can't explain a failure:

text

[Attempt] get_run({"id": "RUN-842"}) -> "failed in unit-tests"
[Feedback] No new evidence: failure cause still unsupported.
[Reflection] "The summary endpoint cannot reveal the assertion. Query the failed job logs next."
[Memory] Store that lesson for the next trial on this task.
[Next attempt] get_logs({"run_id": "RUN-842", "job": "unit-tests"})

The reflection changes strategy instead of merely repairing syntax. Scope memory carefully: a lesson learned for one repository, tool version, or incident can become stale or harmful elsewhere. Re-run tool allowlists, authorization, schema validation, and source-of-truth checks on the new proposal.

Reflection isn't proof: A verbal reflection remains generated guidance. It doesn't prove a factual claim or authorize a side effect.

Most deterministic failures need only a structured error. Use memory-backed reflection for repeated or ambiguous failures that are safe to revisit and whose lessons have a clear scope. High-stakes or potentially committed effects should stop for approval or reconciliation instead.

The circuit breaker pattern

A circuit breaker stops a failing dependency from taking the rest of the agent with it. For RUN-842, that usually means failing fast once get_run or the model endpoint crosses a known error threshold, instead of letting every remaining step rediscover the outage.

The breaker has three states in its state machine: Closed lets requests flow and counts failures, Open fails fast while the dependency is unhealthy, and Half-open admits one probe after a cooldown.

Diagram showing Closed, Open, and Half-open. — Closed, Open, and Half-open.

Only dependency-health failures move the circuit toward Open. A schema or authorization error follows a correction path instead.

The labels above map to the runtime states: Closed is normal operation, Open avoids spending tokens on a dependency already known to be unhealthy, and Half-open tests recovery with one request. If that probe succeeds, traffic returns to Closed; if it fails, the circuit returns to Open.

Half-open keeps recovery controlled. Jumping from Open straight to Closed after a timeout would dump every queued agent call onto a still-failing API (the thundering-herd problem). One probe is cheaper than discovering the outage again with a burst of billable tokens.

The implementation turns those two rules into state transitions. It gates Half-Open so only one probe runs at a time, then stamps each admitted call with a generation. Opening the circuit, or starting a new Half-Open generation, invalidates older in-flight completions. A stale success can't close a circuit that newer failures already opened.

the-circuit-breaker-pattern.py

import asyncio
import time

class CircuitOpenError(Exception):
    pass

class CircuitBreaker:
    """Prevents cascading failures by halting requests to failing services."""
    CLOSED = "closed"      # Normal operation
    OPEN = "open"          # All calls fail fast
    HALF_OPEN = "half_open"  # Test with one call

    def __init__(self, failure_threshold: int = 5, reset_timeout: float = 60.0):
        self.state = self.CLOSED
        self.failure_count = 0
        self.failure_threshold = failure_threshold
        self.reset_timeout = reset_timeout
        self.last_failure_time = 0.0
        self._lock = asyncio.Lock()
        self._half_open_probe_in_flight = False
        self._generation = 0

    async def call(self, func, *args, **kwargs):
        """Executes the function if the circuit is closed or half-open."""
        async with self._lock:
            now = time.monotonic()

            if self.state == self.OPEN:
                if now - self.last_failure_time > self.reset_timeout:
                    self.state = self.HALF_OPEN
                    self._half_open_probe_in_flight = False
                    self._generation += 1
                else:
                    raise CircuitOpenError("Circuit is open - failing fast")

            if self.state == self.HALF_OPEN and self._half_open_probe_in_flight:
                raise CircuitOpenError("Half-open probe already in flight")

            is_half_open_probe = self.state == self.HALF_OPEN
            if is_half_open_probe:
                self._half_open_probe_in_flight = True
            call_generation = self._generation

        try:
            result = await func(*args, **kwargs)
        except Exception as exc:
            async with self._lock:
                if self._is_dependency_failure(exc):
                    self._on_failure(call_generation, is_half_open_probe)
                elif call_generation == self._generation and is_half_open_probe:
                    self._half_open_probe_in_flight = False
            raise

        async with self._lock:
            self._on_success(call_generation, is_half_open_probe)
        return result

    def _on_success(self, call_generation: int, was_half_open_probe: bool):
        if call_generation != self._generation:
            return
        if self.state == self.HALF_OPEN and not was_half_open_probe:
            return
        self.failure_count = 0
        self.state = self.CLOSED
        self._half_open_probe_in_flight = False

    def _on_failure(self, call_generation: int, was_half_open_probe: bool):
        if call_generation != self._generation:
            return
        self.failure_count += 1
        self.last_failure_time = time.monotonic()
        if was_half_open_probe or self.failure_count >= self.failure_threshold:
            self.state = self.OPEN
            self._half_open_probe_in_flight = False
            self._generation += 1

    def _is_dependency_failure(self, exc: Exception) -> bool:
        # Add provider-specific 429 and 5xx exceptions in production.
        return isinstance(exc, (TimeoutError, ConnectionError))

async def verify_stale_success_cannot_close_newer_open_circuit():
    breaker = CircuitBreaker(failure_threshold=1)
    old_call_started = asyncio.Event()
    release_old_call = asyncio.Event()

    async def old_success():
        old_call_started.set()
        await release_old_call.wait()
        return "old success"

    async def newer_failure():
        raise TimeoutError("dependency failed")

    old_task = asyncio.create_task(breaker.call(old_success))
    await old_call_started.wait()

    try:
        await breaker.call(newer_failure)
    except TimeoutError:
        pass

    assert breaker.state == breaker.OPEN
    release_old_call.set()
    assert await old_task == "old success"
    assert breaker.state == breaker.OPEN

asyncio.run(verify_stale_success_cannot_close_newer_open_circuit())
print("stale success left circuit open")

Output

stale success left circuit open

Count only failures that indicate dependency health, such as timeouts, connection failures, and selected 5xx responses. A 400 schema error or 401 auth failure needs correction or escalation, but it shouldn't open a dependency circuit.

The generation check handles a race that the one-probe flag alone can't prevent. Several calls may already be running while the circuit is Closed. If their newer peer failures open the circuit, a slower success from the old generation may still return its own result, but it no longer has permission to reset shared breaker state. Only a success admitted in the current Closed generation or the current Half-Open probe can close the circuit.

Choose breaker scope deliberately. A per-process breaker protects only the worker that observed failures and may be enough for a local resource. A fleet-wide breaker needs coordination through shared state, a service mesh, or provider-side routing. If you build it with a store such as Redis, make state transitions atomic and decide how the system behaves when that store is unavailable.

Fallback chains: graceful degradation

What can you still say when the live path is down? Start with the most capable route, validate its evidence, and move to a narrower claim only when that route fails. The chain below makes that order explicit:

Diagram showing Live tools, Read-only tools, Timestamped cache, and Stop + handoff. — Live tools, Read-only tools, Timestamped cache, and Stop + handoff.

Each fallback narrows its claim contract. Cached context must expose freshness; the final stage admits that live status is unavailable.

Each step trades open-ended behavior for a narrower claim. If the full RUN-842 agent fails or the circuit opens, move to a read-only lookup, then a timestamped cache, then an honest "live status unavailable" message. Fallback isn't automatically safe. A cache from 40 minutes ago can't answer "did the rollback finish?"

Set requires_live_data=True and evidence becomes part of the result contract. In the example, live tools and the read-only path both fail. The cached answer is rejected because the question needs current data, so the chain returns a static handoff instead of a stale "looked healthy" sentence.

fallback-chains-graceful-degradation.py

from dataclasses import dataclass

@dataclass(frozen=True)
class StrategyResult:
    text: str
    has_live_evidence: bool

class FallbackChain:
    DEFAULT_RESPONSE = (
        "Live run status is unavailable right now. Please retry or contact on-call."
    )

    def execute(self, task: str, requires_live_data: bool = False) -> str:
        strategies = [
            ("primary_agent", self._full_agent_execution),
            ("backup_agent", self._simplified_agent),
            ("cached_context", self._cached_context),
            ("static_fallback", self._static_fallback),
        ]
        for name, strategy in strategies:
            try:
                result = strategy(task)
            except TimeoutError:
                continue
            if name == "static_fallback":
                return result.text
            if self._validate_result(result, requires_live_data):
                return result.text
        return self.DEFAULT_RESPONSE

    def _validate_result(
        self,
        result: StrategyResult,
        requires_live_data: bool,
    ) -> bool:
        if not result.text.strip():
            return False
        if requires_live_data and not result.has_live_evidence:
            return False
        return True

    def _full_agent_execution(self, task: str) -> StrategyResult:
        raise TimeoutError("get_run timed out")

    def _simplified_agent(self, task: str) -> StrategyResult:
        raise TimeoutError("read-only get_run timed out")

    def _cached_context(self, task: str) -> StrategyResult:
        return StrategyResult(
            "Cached: RUN-842 looked healthy 40m ago",
            has_live_evidence=False,
        )

    def _static_fallback(self, task: str) -> StrategyResult:
        return StrategyResult(self.DEFAULT_RESPONSE, has_live_evidence=False)

print(
    FallbackChain().execute(
        "What happened to run RUN-842?",
        requires_live_data=True,
    )
)

Output

Live run status is unavailable right now. Please retry or contact on-call.

Pinned reminders are not controls

Long traces create a recall problem before they create a policy problem. Long-context studies show a positional bias: models often do best when relevant information appears near the beginning or end of the context window, and noticeably worse when it's buried in the middle.^{[9]Reference 9Lost in the Middle: How Language Models Use Long Contextshttps://aclanthology.org/2024.tacl-1.9/} As tool output and scratchpad text accumulate, critical constraints can drift into that low-salience region.

A pinned reminder repeats a short set of important instructions near the current task. This can help recall when a trace is long, but it isn't an enforcement boundary. Authorization checks, tool allowlists, and output validation still need to live outside the model. The earlier guardrails lesson separates model guidance from deterministic controls in more detail.

For RUN-842, a pinned block can remind the model not to invent CI status and to confirm writes. Repeating those lines at the end of a long trace may improve recall, but it still isn't a security boundary. Authorization, allowlists, and output checks live in code.

the-pinned-constraints-pattern.py

class PinnedConstraintsAgent:
    CRITICAL_CONSTRAINTS = """
CRITICAL CONSTRAINTS (must follow):
1. Never disclose PII (Personally Identifiable Information)
2. Always confirm actions that modify data
3. Never invent a CI or deploy status
4. Maximum 10 tool calls per user request
"""

    def __init__(self, base_system_prompt: str):
        self.base_system_prompt = base_system_prompt

    def build_prompt(self, conversation_history: list, current_task: str) -> str:
        prompt_parts = [
            self.base_system_prompt,
            "",
            "=== CONVERSATION HISTORY ===",
            self._format_history(conversation_history),
            "",
            "=== CURRENT TASK ===",
            current_task,
            "",
            self.CRITICAL_CONSTRAINTS,
        ]
        return "\n".join(prompt_parts)

    def _format_history(self, history: list) -> str:
        return "\n".join(f"{msg['role']}: {msg['content']}" for msg in history[-10:])

agent = PinnedConstraintsAgent("You look up CI runs.")
prompt = agent.build_prompt(
    [{"role": "user", "content": "What happened to run RUN-842?"}],
    "Summarize RUN-842 without guessing.",
)
after_task = prompt.split("=== CURRENT TASK ===", maxsplit=1)[1]
print("pinned after task:", "CRITICAL CONSTRAINTS" in after_task)
print("ends with cap:", after_task.strip().endswith("Maximum 10 tool calls per user request"))

Output

pinned after task: True
ends with cap: True

Production tip: Keep the block short, prioritize task-critical reminders, and evaluate whether repeating it improves behavior. Moving more policy text to the end doesn't create a stronger security boundary.

Human-in-the-loop escalation

Some failures should end automation, not trigger another model call. When an agent encounters high-stakes ambiguity, repeated failures, or a potential safety issue, pause and route a bounded review packet to an authorized human reviewer.

The earlier human-in-the-loop architecture lesson introduced review checkpoints. Here, HITL is a recovery destination: pause a failed or risky run and send a bounded review packet to an authorized person. Review doesn't guarantee correctness. Approvals can become stale, and execution can drift from the reviewed proposal. Bind approval to the exact action and revalidate it at execution time.

When to escalate

Use measurable triggers rather than a vague feeling that the model is unsure:

A verifier or policy gate score crosses a documented review threshold
Repeated tool-call failures or validation rejections
A proposed write such as rollback, deploy, or delete
Step, budget, or circuit limits that stop automation

The fixture's three-retry limit and 0.7 risk threshold are examples, not universal defaults. Calibrate both against evaluated failures, reviewer load, and the cost of a missed escalation. Copy allowlisted fields into the review packet; don't forward raw model or tool payloads.

when-to-escalate.py

from dataclasses import dataclass
from enum import Enum

class EscalationReason(Enum):
    POLICY_REVIEW = "policy_review"
    REPEATED_FAILURES = "repeated_failures"
    SAFETY_CHECK = "safety_check"

@dataclass
class EscalationRequest:
    reason: EscalationReason
    context: dict[str, object]
    priority: int
    suggested_action: str

class HumanInTheLoop:
    def __init__(self, risk_review_threshold: float = 0.7, max_retries: int = 3):
        self.risk_review_threshold = risk_review_threshold
        self.max_retries = max_retries

    def should_escalate(
        self,
        agent_state: dict[str, object],
        failure_count: int = 0,
        policy_risk_score: float | None = None,
    ) -> EscalationRequest | None:
        if agent_state.get("action_type") in {"delete", "deploy", "rollback"}:
            return EscalationRequest(
                reason=EscalationReason.SAFETY_CHECK,
                context=agent_state,
                priority=1,
                suggested_action="Approve the exact action hash before execution",
            )
        if failure_count >= self.max_retries:
            return EscalationRequest(
                reason=EscalationReason.REPEATED_FAILURES,
                context=agent_state,
                priority=2,
                suggested_action="Review failed attempts and provide guidance",
            )
        if (
            policy_risk_score is not None
            and policy_risk_score >= self.risk_review_threshold
        ):
            return EscalationRequest(
                reason=EscalationReason.POLICY_REVIEW,
                context=agent_state,
                priority=3,
                suggested_action="Review policy-flagged output",
            )
        return None

review = HumanInTheLoop()
rollback = review.should_escalate(
    {
        "action_type": "rollback",
        "run_id": "RUN-842",
        "action_hash": "rb-842-1",
    }
)
lookup = review.should_escalate(
    {"action_type": "lookup", "run_id": "RUN-842"},
    failure_count=1,
)
print(rollback.reason.value if rollback else "none", rollback.priority if rollback else 0)
print("lookup escalate:", lookup is not None)

Output

safety_check 1
lookup escalate: False

Escalation beats false success: An agent that says "I need help" is better than one that silently hallucinates a "Success" message. Design your escalation UX to make it clear when and why the agent failed, preserving user trust.

Monitoring and alerting for agent systems

An agent can return 200 OK and still fail its task. Production systems therefore need specialized observability alongside standard APM (Application Performance Monitoring): latency and error rates matter, but they won't reveal a loop or an unsupported claim by themselves.

Track agent-specific metrics to catch technically successful responses that fail to deliver valid results. Semantic entropy techniques measure uncertainty across sampled answers and can help prioritize review for open-ended generations; they don't verify a tool result or replace source-of-truth checks.^{[10]Reference 10Detecting Hallucinations in Large Language Models Using Semantic Entropyhttps://www.nature.com/articles/s41586-024-07421-0}

Agent observability metrics

Metric	Type	What it measures	Example starting condition
Loop rate	Derived ratio	Share of traces where loop detection triggered	Sustained increase over task-specific baseline
Recovery rate	Derived ratio	Share of intervened trajectories ending in a safe answer, fallback, or escalation	Drops below recovery SLO
Fallback rate	Derived ratio	Share of requests routed to a lower-capability path	Burns degraded-mode SLO
Step count	Histogram	Tool calls per user turn	High percentile approaches configured step cap
Token usage	Histogram	Input plus output tokens per turn	High percentile crosses soft budget
Validation rejection rate	Derived ratio	Share of validated outputs rejected by factual or schema checks	Sustained increase over task-specific baseline

Counters track cumulative events like loops, fallbacks, and validation failures. Histograms record distributions like step counts and token usage. Validation rejection rate and recovery rate are usually derived from validation and incident counters rather than stored directly as gauges. Define recovery rate as:

\text{RecoveryRate} = \frac{\text{failed trajectories that ended safely}}{\text{failed trajectories that triggered an intervention}}

For example, if 100 deploy-status traces hit a validation error, loop breaker, timeout, or fallback path, and 72 still return a safe answer or clean escalation, the recovery rate is 72%. This metric tells you whether your defenses are helping users instead of only detecting failures.

OpenTelemetry's v1.41 GenAI conventions defined model-client duration and token-usage metrics and marked that GenAI surface as Development.^{[11]Reference 11OpenTelemetry GenAI metrics, v1.41.0https://github.com/open-telemetry/semantic-conventions/blob/v1.41.0/docs/gen-ai/gen-ai-metrics.md} Pin a convention version in your instrumentation. Don't treat those names as a stable contract, and keep agent-level signals such as loop and recovery rate in your own documented namespace.

Eval hygiene for recovery systems

Offline harnesses measure recovery, but they can also leak gold into the agent. Treat expected trajectories, gold tool results, and grader labels as eval-only artifacts:

Pin fixtures and keep them outside the agent's tool, memory, and prompt paths during measurement.
Never write gold answers or expected tool traces into episodic or archival memory from the harness.
Feedback channels used in eval must match production. No hidden oracle tools that only exist in the test loop.
If recovery rate jumps after a fixture change, report possible contamination before celebrating the metric.

A recovery system that "learns" the grader isn't recovering; it's cheating the measurement.

The ratio is ordinary arithmetic. Production stacks often export the underlying counters through Prometheus. The snippet records the table's 100-trace example:

agent-observability-metrics.py

class AgentMetrics:
    def __init__(self) -> None:
        self.interventions = 0
        self.safe_recoveries = 0

    def record_intervention(self, recovered: bool) -> None:
        self.interventions += 1
        if recovered:
            self.safe_recoveries += 1

    def recovery_rate(self) -> float:
        return self.safe_recoveries / self.interventions

metrics = AgentMetrics()
for recovered in [True] * 72 + [False] * 28:
    metrics.record_intervention(recovered)
print(f"recovery rate: {metrics.recovery_rate():.0%}")

Output

recovery rate: 72%

Example alert logic

Alert conditions must be calibrated by task and consequence. Useful starting conditions include:

Loop rate rises over baseline: Inspect traces for ambiguous tools, broken progress state, repeated dependency results, or an overly strict detector before assigning cause.
Fallback traffic burns its SLO: Check primary dependencies, validation changes, routing, and task mix. Separate an outage from an intentional product rollout.
High-percentile steps or tokens approach hard caps: Tighten optional exploration or compact validated state before user-facing stops dominate.
A circuit remains Open: Investigate dependency health, client and network paths, timeout budgets, and breaker sensitivity.

Send these agent-specific metrics to your observability and incident-response tooling alongside standard server metrics. Alert on a rising loop rate so operators can stop affected runs before they degrade service or drive runaway API costs.

Common misconceptions

Deterministic service habits become unsafe when the control flow is generated. Keep these four boundaries in view:

Blind retries: Retrying the same hallucinating LLM call often repeats the failure or produces a different wrong answer. Effective recovery changes the strategy by modifying the prompt, switching models, or reducing the task scope.

Timeouts: A timeout doesn't prove that a side effect failed. Replay can duplicate work or create inconsistent state, so use idempotency keys, checkpoints, and explicit reconciliation against the source of truth.

Step caps: A step limit is a crude safety net. It doesn't stop an agent from wasting 15 steps (and thousands of tokens) on a futile loop before the limit; semantic loop detection stops that waste earlier.

Generic exception handlers: Catching every exception silently creates "zombie agents" that continue with corrupted state. Keep failures explicit and route them through validation checks or circuit breakers instead of swallowing them.

Practice: diagnose the failure

Pause before reading the sketches. For each scenario, name the failed boundary, choose the first safe recovery path, and say what evidence would let the run continue.

Scenario 1: Your deploy-status agent calls get_run({"id": "RUN-842"}) three times in a row, gets the same answer each time, and keeps going.
Scenario 2: The agent's reasoning trace says "I will search the database" but the actual tool call is create_release({}).
Scenario 3: After a rollback tool times out, the orchestrator retries and the developer receives two rollback notifications.
Scenario 4: The agent has used 120,000 tokens on a single request and your limit is 100,000.
Scenario 5: The agent invents a tool called fetch_run_secret that doesn't exist in your tool registry.

Solution sketches

Scenario 1: Progress failure. The LoopBreaker would catch the third identical call with args_hash deduplication. Also inspect why the completion condition didn't stop the run after a sufficient answer.
Scenario 2: Proposal failure. Compare the emitted tool with the structured task contract and allowlist. Block create_release when the accepted intent is deploy status. A critic can add review signal but can't replace deterministic capability checks.
Scenario 3: External-state failure. The timeout didn't mean "nothing happened." Use an idempotency key and read-after-write reconciliation before deciding whether any retry is necessary.
Scenario 4: Progress-budget failure. TokenBudget should stop the run at its hard limit. A configured soft threshold should have stopped optional exploration and compacted validated state earlier.
Scenario 5: Proposal failure. A tool allowlist rejects fetch_run_secret before execution and returns structured feedback: Tool 'fetch_run_secret' not available. Available tools: get_run, get_logs, suggest_alternative.

Agent failure controls

The same few boundaries recur across every example. Use this list as a design review for a runtime, then check each control against a trace rather than treating it as a slogan.

In the independent, equal-probability toy model, n required steps succeed with probability p^n. Real trajectories add correlated faults and recovery boundaries, so measure task-level reliability directly.
Generated failures can look successful. Build validation checks for claims and actions, not exception handlers alone.
Classify the failed boundary: proposal, dependency, external state, progress, or result. Recovery follows evidence, not a generic "agent error."
Loop detection needs multiple signals: exact-call hashing, approximate intent similarity, repeated-tool heuristics, step limits, and token budgets.
Corrective feedback beats blind retry for deterministic mistakes. Reflexion stores task feedback as verbal memory for later trials; it doesn't authorize actions or prove claims.
Circuit breakers limit repeated calls to unhealthy dependencies; they don't establish correctness.
Fallback chains degrade capability explicitly. Live-data questions must stop or escalate when fallback paths lack evidence.
Checkpointed recovery beats blind replay when state may already be poisoned or partially committed.
Pinned reminders can improve recall in long contexts, but enforcement remains outside the model.
Human review must be bound to exact actions and revalidated at execution; escalation alone isn't a guarantee.
Agent-specific metrics such as loop rate, fallback rate, and token usage matter as much as latency and error rate.

Handoff to recursive long-context work

These controls bound a conventional agent loop: every proposal, tool result, checkpoint, and recovery action has a contract. The next lesson, Recursive Language Models, keeps long inputs outside the active window and delegates targeted sub-calls. Recursion changes how context is decomposed. It doesn't remove budgets, validation, or recovery. Each sub-call still needs a trusted input boundary and a bounded way to fail.

Next Step

Continue to Recursive Language Models (RLM)

Recovery policies keep one agent's state and actions bounded. RLM applies those controls to a programmable long-context loop that stores large inputs outside the active window and delegates targeted sub-calls under explicit budgets.

PreviousAgent Memory & Persistence

Share this article

X Facebook LinkedIn Bluesky Reddit Hacker News Email

References

ReAct: Synergizing Reasoning and Acting in Language Models.

Yao, S., Zhao, J., Yu, D., Du, N., Shafran, I., Narasimhan, K., & Cao, Y. · 2023 · ICLR 2023

https://arxiv.org/abs/2210.03629

Toolformer: Language Models Can Teach Themselves to Use Tools.

Schick, T., et al. · 2023 · NeurIPS 2023

https://arxiv.org/abs/2302.04761

Measuring AI Ability to Complete Long Tasks

Kwa, T., West, B., Becker, J., et al. (METR) · 2025

https://metr.org/blog/2025-03-19-measuring-ai-ability-to-complete-long-tasks/

Tau-Bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains

Yao, S., et al. · 2024 · arXiv preprint

https://arxiv.org/abs/2406.12045

Exponential Backoff And Jitter

Brooker, M. (AWS) · 2015

https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/

LangGraph Persistence

LangChain · 2026

https://docs.langchain.com/oss/python/langgraph/persistence

Temporal Workflow Execution Overview

Temporal Technologies · 2026

https://docs.temporal.io/workflow-execution

Reflexion: Language Agents with Verbal Reinforcement Learning.

Shinn, N., et al. · 2023

https://arxiv.org/abs/2303.11366

Lost in the Middle: How Language Models Use Long Contexts

Liu, N.F., et al. · 2024 · TACL 2024

https://aclanthology.org/2024.tacl-1.9/

Detecting Hallucinations in Large Language Models Using Semantic Entropy

Farquhar, S., et al. · 2024 · Nature

https://www.nature.com/articles/s41586-024-07421-0

OpenTelemetry GenAI metrics, v1.41.0

OpenTelemetry Authors · 2026

https://github.com/open-telemetry/semantic-conventions/blob/v1.41.0/docs/gen-ai/gen-ai-metrics.md

Discussion

Questions and insights from fellow learners.

Discussion loads when you reach this section.

Why is "fail transparently" a better goal than "never fail" for production agents?

Why is "fail transparently" a better goal than "never fail" for production agents?

What moves from test time to runtime when software becomes agentic?

What moves from test time to runtime when software becomes agentic?

An agent step succeeds 98% of the time. Why might a 40-step task still fail more than half the time?

An agent step succeeds 98% of the time. Why might a 40-step task still fail more than half the time?

A deploy agent says "deployment approved" because an earlier CI pass was hallucinated. Which boundary failed, and what should catch it before the reply reaches a user?

A deploy agent says "deployment approved" because an earlier CI pass was hallucinated. Which boundary failed, and what should catch it before the reply reaches a user?

Why is the second get_run({"id": "RUN-842"}) attempt different from a blind retry?

Why is the second get_run({"id": "RUN-842"}) attempt different from a blind retry?

The agent called get_run({"run_id": "RUN-842"}), and the tool returned Missing required parameter 'id'. What feedback should the next retry receive?

The agent called get_run({"run_id": "RUN-842"}), and the tool returned Missing required parameter 'id'. What feedback should the next retry receive?

Why should hallucinated tools be rejected before any execution attempt?

Why should hallucinated tools be rejected before any execution attempt?

Why does the loop breaker track both exact argument hashes and approximate intent text?

Why does the loop breaker track both exact argument hashes and approximate intent text?

Why does the loop breaker append a call only after checks pass?

Why does the loop breaker append a call only after checks pass?

An agent has a 100,000-token budget and reaches 82,000 tokens before finishing. Should the system wait for the hard limit, summarize, or retry from scratch?

An agent has a 100,000-token budget and reaches 82,000 tokens before finishing. Should the system wait for the hard limit, summarize, or retry from scratch?

Why can a 20-step agent run cost more than 20 separate one-step calls?

Why can a 20-step agent run cost more than 20 separate one-step calls?

A rollback tool times out after the deployment controller may have committed the rollback. Why is blind retry wrong, and what should the orchestrator do instead?

A rollback tool times out after the deployment controller may have committed the rollback. Why is blind retry wrong, and what should the orchestrator do instead?

Which failures are good retry candidates, and which failures need a different recovery path?

Which failures are good retry candidates, and which failures need a different recovery path?

Why is action-contract validation useful even if the model's explanation looks correct?

Why is action-contract validation useful even if the model's explanation looks correct?

What makes Reflexion different from a repair retry?

What makes Reflexion different from a repair retry?

When is a Reflexion loop overkill?

When is a Reflexion loop overkill?

Why should a circuit breaker use a Half-Open state instead of jumping directly from Open back to Closed after the cooldown?

Why should a circuit breaker use a Half-Open state instead of jumping directly from Open back to Closed after the cooldown?

When does a circuit breaker need coordinated state in a multi-server deployment?

When does a circuit breaker need coordinated state in a multi-server deployment?

In the fallback chain, why should the system return the first response that passes validation instead of trying every lower-capability strategy too?

In the fallback chain, why should the system return the first response that passes validation instead of trying every lower-capability strategy too?

What should each fallback stage validate before returning to the user?

What should each fallback stage validate before returning to the user?

Pinned constraints say "Never disclose PII." Is that enough to enforce privacy?

Pinned constraints say "Never disclose PII." Is that enough to enforce privacy?

Which constraints belong in a pinned block, and which belong in code?

Which constraints belong in a pinned block, and which belong in code?

Name two concrete triggers that should escalate an agent run to a human reviewer.

Name two concrete triggers that should escalate an agent run to a human reviewer.

What context should an escalation request preserve for the human reviewer?

What context should an escalation request preserve for the human reviewer?

Why is recovery rate more useful than validation-failure count alone?

Why is recovery rate more useful than validation-failure count alone?

Which scenario creates the greatest operational risk, and why?

Which scenario creates the greatest operational risk, and why?

Mastery Check

Discussion

Why is the second `get_run({"id": "RUN-842"})` attempt different from a blind retry?

The agent called `get_run({"run_id": "RUN-842"})`, and the tool returned `Missing required parameter 'id'`. What feedback should the next retry receive?