An AI tool error should send work to the person or process that can resolve it. A malformed date may need a correction; a refused permission may need an owner’s decision. Treating both as “try again” wastes time and can turn a recoverable problem into an unauthorized action.
This reference separates sixteen response cases into four routes: repair, inspect, decide and wait. The routes are our operating recommendations. A response code provides evidence about what happened; the task’s scope and the destination’s actual state determine what the agent may do next.
- 01Classify the decision.A repairable input, an unknown outcome and a permission refusal need different responses.
- 02Keep partial success.Record successful items before deciding what can safely resume.
- 03Escalate with a choice.Tell the owner what is blocked, what already happened and which decision unlocks progress.
01 — Choose the next routeChoose the next route #
Start with the most specific trustworthy response available. The group names describe the next kind of work, not severity. A case can move from inspect to decide once the missing evidence is recovered. Apply the table only within the permissions and budget already granted.
| Digital Applied editorial classification, reviewed September 7, 2026; source anchors linked in the next section. | ||
|---|---|---|
| Response and route | Evidence to inspect | Recommended next step |
| --- | --- | --- |
| Repair: Missing required field | Check the request against the documented input | Fill from verified task context; ask if the value is unknown. |
| Repair: Invalid date or number | Locate the rejected value and accepted format | Correct representation without changing the user’s intended value. |
| Repair: Unsupported file type | Check accepted formats and conversion losses | Convert only if the requested content survives; otherwise offer an alternative. |
| Repair: Wrong object identifier | Resolve the identifier against the authorized target | Correct a known mismatch; never substitute a similar customer or document. |
| Inspect: Version conflict | Read the current object and proposed change | Determine whether a safe merge exists before resubmitting. |
| Inspect: Unmet precondition | Identify the condition that no longer holds | Refresh the prerequisite; do not remove the protection to force success. |
| Inspect: Empty result | Check filters, access scope and expected existence | Treat no matches as data until evidence establishes a failure. |
| Inspect: Partial batch result | List successful, failed and unknown items separately | Continue only from item-level outcomes; do not repeat the whole batch. |
| Inspect: Missing completion receipt | Look up the operation or destination state | Keep completion unknown until corroborated; avoid duplicate side effects. |
| Decide: Access refused | Read the refusal and current authorization | Ask the authorized owner if access should change; do not widen it automatically. |
| Decide: Expired login | Determine whether reauthentication is required | Request reconnection when needed; then verify whether earlier work completed. |
| Decide: Spending limit reached | Identify the approved ceiling and remaining work | Offer reduced scope or request an explicit budget decision. |
| Decide: Business rule blocks action | Preserve the violated condition | Ask for a permitted alternative; a technical workaround is not authorization. |
| Wait: Documented rate limit | Read the service’s retry timing and task deadline | Wait within the existing run budget; escalate if the deadline becomes impossible. |
| Wait: Temporary unavailability | Check service guidance and operation status | Use bounded recovery only where repeating the action is known to be safe. |
| Wait: Job still processing | Find a valid job identifier and next status check | Track the existing job; a pending result does not justify creating another. |
02 — What the standards actually establishWhat the standards actually establish #
RFC 9110 distinguishes access refusal, resource-state conflict and failed preconditions. A 403 response should not be automatically repeated with the same credentials. A 409 can require resolving a state conflict. Those meanings do not establish that every occurrence needs a human.
RFC 9457 provides a structured format for API problem details. Its type identifier and defined extensions are more suitable for machine routing than parsing the human-readable detail sentence. Our four routes are a synthesis layered above those protocol concepts.
An application may use a different error format or put domain failures inside an otherwise successful response. Inspect its documented contract. Do not infer the meaning of a vendor-specific code merely because its wording resembles an HTTP status.
03 — Separate failure from an unknown outcomeSeparate failure from an unknown outcome #
Imagine an illustrative agent exporting a set of approved documents. The connection drops after the destination starts processing. The agent has evidence of a communication failure, but no evidence that the export failed. Its next useful action is a read-only lookup of the job or destination, not another export request.
Save the operation identifier, attempted target, last confirmed state and any completed item identifiers. If no lookup is possible, report the uncertainty plainly: the request may have completed, and repeating it may create another copy. The owner can then choose whether waiting or reconciliation is appropriate.
This is a different problem from choosing a backoff interval. Our long-running tool-call guide covers keeping track of an ongoing call; this table determines what its response means for the task.
04 — Give the owner a decision they can makeGive the owner a decision they can make #
A useful escalation names the blocked action, the relevant constraint and the available choices. “The approved spending ceiling is reached; the remaining files are untouched. Reduce the scope or approve a revised ceiling” is actionable. “The tool failed” leaves the owner to reconstruct the whole run.
Include evidence without copying secrets or a full diagnostic dump into the conversation. Preserve a reference to the restricted log if someone needs deeper investigation. The owner needs the reason and consequences, not every implementation detail.
Do not make the owner approve corrections already covered by the request. Reformatting an unambiguous date is ordinary execution. Choosing which of two clients the date belongs to changes the target. The distinction follows the ask-versus-guess decision rubric.
05 — Add recovery rules to one real workflowAdd recovery rules to one real workflow #
Choose a workflow with a clear destination and list its actual failure responses. Map each to the table, then record the evidence that permits recovery. Where the mapping is unknown, leave it unresolved until the tool contract or a controlled test supplies the missing information.
Give every recovery route an end condition: verified completion, a preserved partial result, an explicit decision request or a documented stop. “Keep trying” has no useful completion boundary. The background-work cancellation guide explains what to check when the run must end.
Original editorial classification informed by inspected primary sources.
- What was collected
- 16 response cases across 4 decision routes. One row per check or response case; multiple rows can apply to the same artifact or task.
- As-of date
- Sources inspected and classification assembled September 7, 2026. The assigned publication date is September 5; this is not a claim of collection on that date.
- Sources and evidence
- The linked primary documents provide conceptual anchors. Row selection, grouping and recommended actions are Digital Applied editorial analysis, not a checklist issued by those sources.
- Counting method
- Count each table body row once and group by the label before its colon. The chart renders those counts with a common linear scale; units are checklist entries.
- Exclusions and gaps
- No vendor census, model ranking, live experiment or prevalence estimate. UNVERIFIED means the required evidence was not inspected. Not applicable means the property is outside the agreed task.
- Limitations and updates
- This is a bounded reference, not an exhaustive standard or certification. Review the same URL when source guidance or use cases change; a passed checklist does not establish every aspect of correctness.
06 — DecisionWhat to do next #
Recover from the meaning of the response.
Start with the failures your workflow can actually return. A small set of explicit recovery rules is easier to review than a general instruction to persist until success.
For implementation support, explore our AI transformation services.