Retrying a failed agent step usually just fails again, more expensively

Design error handling that diagnoses the failure and changes approach or falls back, and retries earn their cost. Blindly retry the same step and you pay twice for the same wrong answer.

B

Balagei G Nagarajan

3 MIN READ


An agent blindly retrying a failed step versus diagnosing and changing approach
SWE-bench-Live shows real capability gaps are common once contamination is stripped out.
— from “Retrying a failed agent step usually just fails again, more expensively”

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.

A retry decision ladder diagnosing failure type before choosing retry, fallback, or escalate

What does sound recovery look like?

Failure typeBlind retryDiagnosed recovery
TransientRetry (works)Bounded retry with backoff
Capability gapRetry (fails again)Change approach or fall back
Bad inputRetry (fails again)Fix input or escalate
Compromised toolRe-runs the attackStop 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.


Share this post

Join the discussion

Have a take, a war story, or a question? Sign in with GitHub to comment and react. Comments are powered by GitHub Discussions, ad-free and yours to moderate.

Continue Reading

Find where your agent breaks, before you build it

Faultmap maps where your agent will fail from the goal and your data, then hands you the first test suite it has to pass.