Retries, timeouts and dead agents: reliability in practice
An agent can stall or repeat an action unexpectedly. Learn how timeouts, bounded retries, resumable steps, status monitoring and human escalation make these failures manageable.
A reliable agent is not one that never fails. It is one that fails in a manageable way: with clear timeouts, bounded retries, safely repeatable actions and visible status. That way, a stalled task does not remain unnoticed, and an action is not repeated without control.
This requires rules for each step and for the task as a whole. Decide how long the agent waits for a response, when it tries again, how you check whether an action has already happened and when a person should step in. These measures do not make failure impossible, but they make it visible and easier to recover from.
Why agents get stuck
An agent often performs several steps in sequence and depends on models, network connections and external tools. A tool may respond slowly, a connection may drop, or a model may keep generating without producing a useful answer. An agent may also wait for a result that never arrives, or repeatedly schedule a step without making progress.
From the outside, these situations can look the same: nothing is happening. The cause matters, though, because it determines what response is safe. A temporary network error may justify another attempt; an uncertain payment or sent email needs checking first. So do not only check whether a process is still running. Check whether the work is progressing. See agent observability for ways to make behaviour and progress visible.
Timeouts for each step and the whole task
A timeout sets a limit on waiting. Where needed, set a limit for each step, such as a model response or an external tool call. Also set a maximum duration for the complete task. Without that second limit, an agent may stay within the limit for each individual step but still continue indefinitely through a long sequence.
The right duration varies by task and dependency. A quick data lookup usually calls for a different expectation from processing that waits on an external system. Set limits based on what the task requires, and make clear what happens when a limit is reached: the step may be retried, the task may be marked as failed, or the work may be sent to a staff member.
A timeout does not always mean the action failed. The connection may have dropped after the external service processed the request. Treat an uncertain outcome differently from a confirmed failure. For actions with consequences, check the status before trying again.
Retries without repeating harm
A retry is another attempt after a temporary failure. Limit the number of attempts and add a delay before trying again. Increasing the delay can keep an agent from immediately sending another request to an overloaded service. The right delay depends on the service, the error and the task; there is no universal retry setting.
Not every error is temporary. Invalid input does not become valid when you submit the same request again. Retry only errors for which another attempt may help, and stop after a defined maximum. Decide what happens next so the task does not keep trying silently.
Idempotency matters for actions with consequences. It means that performing the same operation more than once produces the same final result as performing it once. If an agent sends a request but loses the response, it might otherwise create two requests by mistake. Where possible, use a unique key or first check whether the action has already been processed. Some external systems do not support this well. In that case, handle the uncertainty explicitly, for example by asking a staff member to check.
Status, heartbeats and resuming work
A status field shows what the agent is doing: for example, started, working on a particular step, waiting, completed or stalled. A heartbeat is a periodic signal that the process is still active. If that signal stops, a monitoring system can investigate whether the agent has actually stopped. A heartbeat alone does not prove progress: a process may still be alive while repeating the same step. Combine status with the last completed step and the time it was completed.
Save intermediate steps when a task needs to continue after an interruption. Store enough to know what is complete, which input was used and what comes next. Resuming should not blindly repeat the same action: first check whether it has already taken effect. Also store only the information needed to perform and verify the task.
Clear status also helps people. They need to see whether a task is running, waiting on an external service, stopped or in need of attention. For more on retaining and retrieving context for agents, see continuous memory for agents.
When to stop and alert a person
Have the agent stop and alert a person when it has run out of attempts, the outcome of an action remains uncertain, or the next step could have consequences that are difficult to reverse. Examples include a payment, a legal commitment or a message to a customer. Conflicting information, missing consent or a repeated pattern with no progress are also reasons to escalate.
The alert should provide enough context to take over: which task stalled, which step was in progress, what error occurred, what has already been tried and whether an external action may already have happened. That saves a staff member from having to investigate the agent's work from scratch. Guardrails for AI agents explains how to set up such limits in advance.
Logging, failure testing and checklist
Log events that help explain failures: the start and end of steps, timeouts, retries, status changes, external actions and escalations. Also record the relevant task or correlation ID so you can find related events. Limit sensitive information in logs and decide who may access them. Set alerts for situations that need action, such as tasks reaching their time limit or processes whose heartbeat has stopped. A log is useful only when someone knows which signals need follow-up.
Test failure handling deliberately. Simulate a slow tool, a dropped connection, a missing response and an agent that keeps running without progress. Then check whether the timeout takes effect, retries stay bounded, actions are not duplicated, the status is accurate and a staff member receives the right alert. Repeat these checks when the task or an important dependency changes.
Use this checklist when designing or reviewing an agent:
- Does each step have a suitable timeout, and does the whole task have a maximum duration?
- Are retries limited, delayed and reserved for errors that may be worth trying again?
- Can you safely check whether an external action has already happened before repeating it?
- Do status and heartbeat together give enough visibility into progress and stalls?
- Can the task resume from saved steps without doing work twice?
- Do you know when the agent stops and what information a staff member receives?
- Are logs useful, access to them restricted and failures deliberately tested?
Reliability comes from making these parts work together. Timeouts limit waiting, retries handle temporary failures, status makes stalls visible and resuming prevents interrupted tasks from being lost. When the outcome is uncertain or the impact is significant, a person should decide the safe next step.