Why "agent failed" doesn't tell you enough

An agent asked to cancel an order and issue a refund can fail in several different ways. The order service might be temporarily unavailable, the customer might not have permission to cancel, or the order may already have shipped. Cancellation might succeed before the refund service fails. A refund request might be submitted successfully but time out before the agent receives confirmation. The agent itself might choose the wrong operation, or it might reach a point where human approval is required before it can continue.

All of those runs could end with the same top-level status: failed.

For someone operating the system, that status is not enough to decide what should happen next. The useful questions are where the problem occurred, what had already happened, whether another attempt is appropriate, and what the task now needs in order to continue.

Retry depends on the kind of failure

Some failures are temporary. If an external service is unavailable, retrying after a delay may be reasonable. Other failures will persist until something changes. Repeating a request with unchanged invalid input or insufficient authorization is unlikely to help.

Temporal recommends treating conditions such as invalid input, business-rule violations, and authorization failures as non-retryable when repeating an Activity will not resolve them. AWS Step Functions also allows different errors to be handled with different retry and catch behavior, including retries for transient service failures.

Agent failures add other cases. An agent can often recover from invalid input, because the model can correct its own arguments once it sees the error. Under the MCP specification, servers report input validation errors inside the tool result, with isError set to true, and clients should pass those errors to the model so it can retry with adjusted parameters. If the model cannot proceed because important information is missing, repeating the same call with the same context may not improve the result. The agent may need to retrieve more information or ask the user a question. If policy prevents an action, the next step may be approval rather than another attempt.

A useful failure record should therefore distinguish a condition that may improve with another attempt from one that requires something to change first.

Partial and uncertain outcomes need different handling

Failure becomes more complicated when an agent performs several actions as part of one task.

Suppose an agent creates a support ticket and updates a customer record before failing while sending a notification. Treating the entire run as if nothing happened could cause completed actions to be repeated when the task is retried.

The harder case is an operation whose outcome is unknown. An agent may submit a refund request and then lose the connection before receiving a response. The agent knows that confirmation was not received, but it does not necessarily know whether the refund happened.

For external actions, it can therefore be useful to distinguish among three conditions:

• the action is confirmed to have occurred
• the action is confirmed not to have occurred
• the outcome is unknown

An operator can then choose a different recovery path for each case. An unavailable service that rejected a request before doing any work may be safe to retry. A lost response after submitting a payment or refund may require checking the external system first. If the refund API supports idempotency keys, the agent can resend the request with the same key, and the provider returns the result of the first attempt instead of processing a second refund. That only works if the key was generated and saved before the first attempt, the request parameters remain unchanged, and the provider still retains the key.

A task can also be partly useful without being complete. If an agent is asked to research five suppliers and gathers the required information for four, a later execution may only need to continue from the unresolved part.

Waiting for something is not always failure

Some agent runs stop because continuing requires information or authority that the agent does not have.

A user may need to provide a missing account number. A purchase above a threshold may need human approval. A security-sensitive change may require review before execution.

Those conditions are operationally different from a service crash or invalid tool request. Repeatedly retrying an operation that is waiting for approval will not resolve it, and reporting the task simply as failed can also give the user an inaccurate picture of its state.

The system does not need a large collection of statuses to preserve that distinction. It does need enough information to show whether execution stopped because something broke, because required information was unavailable, or because a deliberate control prevented further action.

What should a failure record tell us?

There is no need to define a universal taxonomy before retaining more useful failure information. A practical starting point is to make four questions answerable:

• Where did the problem occur? Model, context, tool, authorization, orchestration, external dependency, or overall task outcome.
• What happened to the requested action? Did it occur, not occur, partly occur, or is the outcome unknown?
• Is another attempt appropriate? Could retrying help, or does something need to change first?
• What does the task need now? Can it continue, does it need more information or approval, or should it stop?

OpenTelemetry defines error.type so instrumentations can identify predictable error types rather than relying only on free-form error messages. Agent systems may represent richer failure information differently, but the same general principle applies: retain the distinctions that affect diagnosis and recovery.

For example, two failures from the refund scenario might be recorded conceptually like this:

Tool unavailable
Location: refund tool
External effect: no refund submitted
Retry: reasonable after delay
Next step: retry

Refund response lost
Location: refund tool / external service
External effect: unknown
Retry: not until status is checked
Next step: verify refund status

Both operations failed from the agent's point of view, but they should not trigger the same next action.

Test what your failure records preserve

A useful way to assess an agent system is to take several unsuccessful production or evaluation runs and imagine that the surrounding logs and developer knowledge are unavailable.

For each run, can the failure record tell you where the problem occurred and whether any external action had already taken effect? Can you determine whether another attempt was safe, whether different information or permission was required, and whether the task stopped because of an error or because it was correctly waiting for human input?

If those answers require reconstructing several logs, interpreting a free-form exception, or asking the developer who built the integration, the top-level failure status is carrying too little information.