How do we handle agent failures, retries and error recovery?

Handling agent failures well requires distinguishing between transient errors, such as a timed-out API call, which should be retried automatically with backoff, and logical errors, such as the agent choosing a wrong action, which retrying blindly will not fix and can make worse. For transient failures, wrap each tool call with a retry policy that includes a maximum attempt count and exponential backoff, and make tool calls idempotent wherever possible so a retry after a partial failure does not double-charge a customer or duplicate a record. For logical errors, give the agent visibility into the failure, such as returning a structured error message from the tool rather than a raw exception, so it can reason about what went wrong and try a different approach rather than repeating the same mistake. Setting a maximum number of steps or a time budget per task prevents an agent from looping indefinitely, and any task that exceeds its budget or fails validation should fall back to a human queue rather than silently failing. Comprehensive logging of every step, including failed ones, is what makes post-incident debugging and continuous improvement possible. Nanobase AI builds this retry and fallback logic into the orchestration layer as a standard part of every agent deployment, not as an afterthought.

One retry policy for every failure type is the mistake

The most common error-handling bug in production agents is applying the same retry logic to every failure regardless of cause. A timed-out API call and a wrong tool choice are both "failures," but retrying them the same way either wastes attempts on a problem retrying cannot fix or repeats a harmful action. The fix starts with classifying failures into distinct types and matching each to a specific recovery mechanism, not a single generic retry wrapper.

Idempotency is what makes retries safe

A retry policy is only safe to apply automatically if the underlying tool call is idempotent, meaning calling it again with the same input produces the same result rather than a duplicated side effect. Without this property, retrying a payment or a record-creation call after a partial failure, where the first attempt may have actually succeeded before the error was reported, risks charging a customer twice or creating a duplicate record. Designing tools to be idempotent, typically through a request identifier the underlying system deduplicates on, is a prerequisite for safe automatic retries, not an optional refinement.

Giving the model useful failure information

For logical errors, the recovery mechanism is not retrying the same action; it is giving the model enough information to try something different. A raw exception message or a generic "error occurred" tells the model nothing actionable, while a structured error response, such as "invalid date format, expected YYYY-MM-DD" or "no matching record found for this customer ID," lets the model reason about what went wrong and adjust its next attempt accordingly. Tool design deserves as much attention to its error paths as to its success path, since a well-designed error response often resolves a logical failure faster than a human intervention would.

Bounding the blast radius of a stuck agent

A budget enforced outside the model's own judgment is what actually stops a stuck agent, since the model has no reliable way to notice it is looping.

1. Set a maximum step count and time budget per task.
2. Track consecutive failures on the same action; a fixed number of repeated failures on an identical step should trigger escalation rather than another retry.
3. Route any task that exceeds its budget or fails validation to a human queue instead of silently failing or looping further.
4. Log every step, including failed ones, with enough detail to reconstruct exactly what the agent attempted and why it failed.

Circuit breakers for degraded dependencies

When a downstream system the agent depends on, such as a specific API or database, starts failing at an elevated rate, continuing to retry against it at the individual task level wastes time and can worsen the underlying problem, similar to how a struggling service can be pushed further into failure by a flood of retries from many callers at once. A circuit-breaker pattern, where the orchestration layer temporarily stops sending requests to a dependency after its failure rate crosses a threshold and routes affected tasks to a fallback or a human queue instead, protects both the agent's task success rate and the health of the dependency itself during an outage.

Frequently asked questions

How many retry attempts is reasonable for a transient failure?

A common starting point is three attempts with exponential backoff, though the right number depends on the dependency's typical recovery time and how costly a delay is. What matters more is that retries are bounded and the task escalates rather than looping indefinitely once the limit is reached.

Should the model see that a retry happened?

For transient errors handled automatically, the model typically does not need visibility, since the retry logic resolves the issue transparently. For logical errors, the model should see the structured failure explicitly, since that information is what lets it choose a different approach on its next attempt.

What is the risk of not making tools idempotent?

Without idempotency, a retry after a partial failure can duplicate a side effect, such as sending a customer notification twice or creating two records for one event, which is often worse than the original failure it was meant to fix. This risk grows specifically as automatic retry logic is added, making idempotency a prerequisite rather than a nice-to-have.

How do we know if our agent is stuck in a loop versus making slow progress?

Track whether the agent's state, such as which step it is on or what new information it has gathered, is actually changing between attempts. A step count or time budget with no observed state progress is a reliable signal to escalate, while progress toward the goal, even if slow, generally should not trigger the same intervention.

How Nanobase AI helps

Nanobase AI builds this retry, idempotency and circuit-breaker logic into the orchestration layer as a standard part of every agent deployment, not as an afterthought discovered after a production incident. This work is closely tied to agent observability for diagnosing failures and to the cost controls that prevent a stuck agent from also becoming an expensive one.

Ready to discuss your project? Contact Nanobase AI or email hello@bumu.tech.