
Key facts.
- SWE-bench-Live shows agent scores drop on fresh, uncontaminated tasks, so many failures reflect a real capability gap that retrying the same step will not close.source
- MCPTox shows tool calls can be subverted through tool-description poisoning, so a naive retry can re-run a compromised path not recover.source
Why does blind retry fail for agents?
Retry logic borrowed from networking assumes failures are transient. Request timed out, try again, it'll probably work. Some agent failures are like that. Many aren't. If an agent can't complete a step because the task is genuinely beyond it, re-running produces the same failure at twice the cost. SWE-bench-Live shows real capability gaps are common once contamination is stripped out. Retrying a step the model fundamentally can't do is not resilience. It's paying for the same wrong answer twice, sometimes while the compounding cost climbs.
There's a sharper version. If the step failed because a tool was subverted, MCPTox shows this is possible through poisoned tool descriptions, a blind retry re-triggers the compromised path. Turns one bad call into a repeated one. Sound error handling diagnoses before retrying. Was this transient? A capability gap? A bad input? A compromised tool? Transient failures get a bounded retry with backoff. Capability gaps and bad inputs get a different approach or a fallback. Compromised paths get stopped and escalated. Recovery is a decision based on the cause. Not a reflex of running the same step again.

What does sound recovery look like?
| Failure type | Blind retry | Diagnosed recovery |
|---|---|---|
| Transient | Retry (works) | Bounded retry with backoff |
| Capability gap | Retry (fails again) | Change approach or fall back |
| Bad input | Retry (fails again) | Fix input or escalate |
| Compromised tool | Re-runs the attack | Stop and escalate |
Choosing the right recovery depends on recognizing the failure's cause, which is a pattern-level judgment the Pattern Intelligence Layer supports. VibeModel makes the agent's expected behavior on a step legible. A deviation can be classified, transient, capability, input or compromise and routed to the recovery that fits, instead of every failure getting the same blind retry that often just fails again at higher cost.
Frequently asked questions
Isn't retrying the standard fix?
Only for transient failures. Many agent failures are capability or input gaps that re-running cannot fix, so it just doubles the cost of the same wrong answer.
When is a retry actually dangerous?
When the step failed because a tool was compromised. MCPTox shows tool calls can be subverted, so a blind retry can re-run the attack.
What should replace blind retry?
Diagnosis first: classify the failure, then retry transient ones, change approach for capability gaps and stop and escalate compromised paths.

