An agent calls a system, but the response never arrives. A tool returns an error. Or the action was executed, but the agent receives no confirmation. For classic software, such cases can be defined fairly precisely: timeout, error code, retry, abort. The behaviour is fixed in code and identical on every run.
For an AI agent, one more question arises: what does the agent do next? Try again? Use a different method? Abort the operation? Or notify a person? That answer is no longer made solely by the developer at design time. Part of it is made by the system at runtime.
The more autonomously an agent works, the more important it becomes to define not only what it should do in the normal case, but also how it should handle failure. Error handling thus becomes a central part of agentic architecture.
Why Classic Error Handling Is Not Enough
In a conventional integration, the flow is deterministic. A process calls step A, then step B, then step C. For every step, it is defined what happens on failure. Anyone reading the code can trace every possible path.
An agent works differently. It receives a goal, a set of tools, and context. Which tools it calls, and in which order, it decides itself. That is its strength: it can handle situations nobody fully modelled in advance. It is also the reason errors take on a new quality with agents.
When a tool call fails, the agent interprets the error message and derives its next step from it. It may get that right. But it may also repeat a call that must not be repeated. It may choose a detour that bypasses permissions. Or it may read the error message as a success and carry on as if nothing had happened.
The problem is not that agents make mistakes. The problem is that, without clear rules, their reaction to mistakes becomes unpredictable.
Four Kinds of Errors an Agent Has to Handle
Not every error is the same. For the architecture, it helps to distinguish four categories:
| Error type | Example | Typical risk |
|---|---|---|
| Technical error | Timeout, HTTP 500, system unreachable | Agent retries without control |
| Business error | Tool responds, but the result is implausible or violates a rule | Agent continues with wrong data |
| Unclear state | Action was triggered, confirmation is missing | Duplicate execution or false abort |
| The agent's own error | Wrong tool, wrong parameters, wrong conclusion | Error goes unnoticed and propagates |
Technical errors are the easiest to handle because they are familiar from classic integration. Business errors and unclear states are considerably harder. And the fourth category is new: an agent can make mistakes that no system reports as an error, because the call itself was technically correct.
The Most Dangerous Case: The Action Happened, but Nobody Knows
Of the four categories, the unclear state deserves particular attention. An agent creates a ticket, places an order, or sends a quote. The call goes out. Then the connection drops, or the target system responds after the timeout. The agent does not know whether the action took place.
What happens now? If the agent repeats the call, the ticket may now exist twice. The order is placed twice. The customer receives two quotes with different numbers. If, on the other hand, the agent aborts even though the action was carried out, the process has failed from the agent's point of view but succeeded from the target system's. The two sides now disagree about what happened.
This problem is not new. In system integration, it has been solved for years through idempotency: a call with the same idempotency key does not trigger a second action the second time around, but returns the result of the first. For agents, this principle is not optional. Every writing action an agent is allowed to trigger should be idempotent, or allow a status check before any retry.
Rule for agents: before a writing call is repeated, it must be clear whether the first execution took place. If that cannot be checked, the call must not be repeated.
Retrying Is Not a Strategy
"On error, try again" sounds like a reasonable instruction. Without rules, it is dangerous. An agent that repeats a failing call ten times generates load on a system that is already struggling. An agent that treats a business error like a technical one keeps trying with the same wrong data.
A robust retry strategy answers at least four questions:
- What may be retried? Reads almost always. Writes only if they are idempotent.
- How often, and at what interval? A fixed upper limit with increasing spacing between attempts, never an endless loop.
- Which errors justify a retry? A timeout, yes. A validation message, no, because the same call will fail again.
- When does it stop? A retry budget per operation, after which a different path takes over.
Crucially, these rules are not set by the agent itself. They belong to the tool layer that sits between the agent and the target system.
Alternative Paths: Where Flexibility Helps and Where It Hurts
The ability to choose a different path when something fails is one of the reasons companies deploy agents in the first place. If the live stock query fails, the agent can fall back to a cached value and flag it as such. If a search service does not respond, it can use a second data path.
This flexibility needs boundaries, though. An agent that responds to a permission error by looking for another route to the same data is circumventing a rule that exists for good reason. An agent that executes the action anyway after a failed approval step is undermining a control point.
The difference lies in the nature of the error. Technical unavailability justifies alternatives. A business rejection, a missing permission, or a validation error are not obstacles to be worked around. They are decisions made by the system, and the agent has to respect them. Which fallbacks are allowed should therefore be defined explicitly, not left to the model's discretion. How such boundaries translate into governance rules is something we have covered separately.
Aborting and Escalating: Stopping Cleanly Is a Skill
At some point, the agent reaches a state where it should not continue. Retry budget exhausted, no permitted alternative path, or a situation that requires a human decision. Then the agent has to abort and escalate.
A clean abort is harder than it sounds. If the agent has already completed three of five steps, simply stopping leaves a half-finished state: the ticket exists, but the customer was never informed. The order was created, but the warehouse reservation is missing. Such cases require compensating steps that either complete the state or roll it back in a controlled way. Anyone coming from the integration world knows this pattern as a saga.
Escalating to a person only helps if it comes with context. "Processing error" helps nobody. A useful handover contains:
- What the goal of the operation was
- Which steps were already executed, and which were not
- Which error occurred, and at which point
- Which retries and alternatives were already attempted
- What state the involved systems are in now
A person who receives this information can decide within minutes. A person who receives only an error message first has to reconstruct the situation.
Error Handling Belongs in the Architecture, Not in the Prompt
A common approach is to give the agent behavioural rules for failure cases in the system prompt: "If a tool fails, retry at most twice, then inform the user." That is better than nothing. But it is not reliable error handling.
Prompt instructions are interpreted by the model. They can lose weight over a long conversation, compete with other instructions, or be read differently than intended in an unexpected situation. For non-critical flows, that may be acceptable. For writing actions in core systems, it is not.
A more robust approach is to separate responsibilities:
| Layer | Responsibility | Implementation |
|---|---|---|
| Tool and integration layer | Timeouts, retries, idempotency, circuit breakers, permissions | Deterministic code, API gateway, integration platform |
| Orchestration | Retry budget, permitted fallbacks, abort criteria, compensation | Configured rules per action type |
| Agent | Business decision within the permitted options | Model with a clearly bounded action space |
The agent decides whether it makes sense, from a business perspective, to use a second data path. Whether that path is available at all, how often a call is repeated, and whether a write is protected by idempotency is not decided by the model. It is decided by the infrastructure. This preserves the agent's flexibility without making reliability depend on how a model interprets an instruction on a given day.
For companies that already run an integration platform, this is good news. Much of what agents need for error handling already exists there: retry policies, circuit breakers, dead-letter queues, idempotency handling. The task is to make these mechanisms binding for agents as well, instead of giving every agent direct access to the target systems. The requirements this places on enterprise APIs are a topic of their own.
Making Errors Visible
Error handling without observability is blind. If nobody knows how often an agent retries calls, how frequently it falls back to alternatives, and how often it escalates, it is impossible to judge whether the rules fit, or whether behaviour is changing over time.
At least three things should be captured for every productive agent:
- Every tool call with its result, including error code, duration, and number of attempts. This is the basis for any analysis.
- Metrics per tool and action type: error rate, retry rate, fallback rate, escalation rate. A sudden rise is often the first signal of a problem in the target system.
- Full traceability per operation: which steps did the agent execute, in which order, and why? Without this trail, misbehaviour cannot be explained after the fact.
This data matters beyond operations. It is also the basis for adjusting retry budgets, permitted fallbacks, and escalation rules over time. Error handling is not a one-off design. It is a set of rules that matures with use. What this means for the step from pilot to production is covered in a separate article.
What Should Be Settled Before Going Live
Before an agent gets write access to enterprise systems, these questions should be answered:
| Area | Guiding question |
|---|---|
| Idempotency | Can every writing action be safely repeated, or is there a status check before any retry? |
| Retry rules | Which errors justify a retry, how often, and where is the upper limit? |
| Fallbacks | Which alternative paths are permitted, and which errors must explicitly not be bypassed? |
| Abort | Which compensating steps apply when a multi-step operation fails midway? |
| Escalation | Who is informed, when, and what context does that person receive? |
| Responsibility | Which rules live in the infrastructure, and which decisions remain with the agent? |
| Observability | Are retries, fallbacks, and escalations measured, and who looks at those numbers? |
These questions do not have to be answered for every conceivable agent at once. It is more sensible to start with the actions a specific agent is actually allowed to trigger. For that subset, the answers should be in place before the rollout.
Conclusion
The discussion about AI agents usually revolves around capabilities: what can the agent do, which tools does it use, how autonomously does it work? The question of what it does when something goes wrong usually comes later. Yet that is precisely what decides whether an agent builds trust in production or squanders it.
An agent that retries uncontrollably on every error, circumvents rules, or leaves half-finished states behind is not viable in an enterprise, no matter how good its model is. An agent whose failure behaviour is defined, anchored in the architecture, and measurable, on the other hand, can work reliably even when the systems around it do not.
The more autonomously an agent works, the less the question is whether errors will happen. They will. The question is whether the architecture ensures that an error does not become damage.