When the tool fails and the agent says the job is done

A failed request can leave the business in an unknown state

Imagine an agent submitting a replacement order. The request times out, so the agent tries again. The second attempt returns a confirmation. The customer hears that everything is handled, while the warehouse receives two orders because the first request succeeded before its response was lost.

This is a familiar distributed-systems problem with a conversational layer on top. The integration must handle uncertain execution, and the agent must explain the outcome without making a claim that the evidence cannot support.

A timeout can mean that nothing happened, that the operation is still running, or that it completed but the response never arrived. Treating those possibilities as the same error makes recovery dangerous. A retry may help a read operation and duplicate a write operation.

The product therefore needs more than a successful tool-call format. It needs a way to establish what happened in the business system. That might be an operation identifier, a status lookup, or a record that can be checked before another attempt.

The customer should receive the narrowest accurate statement. If an order was submitted but confirmation is pending, say that. If the result is unknown, explain what will be checked next. Polished certainty is particularly costly when it discourages the user from noticing an unfinished task.

The second failure is often the explanation

Failure-Transparent Agents, a September 2026 preprint, isolates what models say after receiving a failed tool observation. Across its controlled tests, false-success reports fell from 22.8% under the baseline policy to 0.8% under a structured evidence contract. These results apply to the paper’s blocked-task setup, not to end-to-end reliability in production. They do suggest that the rules connecting evidence to completion claims deserve direct testing. [1]

The application can give every action a small set of states: prepared, submitted, confirmed, failed, or unknown. The final response should be generated from that state and the supporting record. The model should not decide that a friendly confirmation is appropriate simply because the conversation has reached a natural ending.

This matters especially in workflows with several actions. An agent might update a shipping address successfully but fail to notify the carrier. “Your address has been changed” may be true in one system and misleading for the shipment the customer cares about.

Report partial completion at the level of the user’s goal. Explain which change is confirmed and which dependency remains unresolved. Preserve the identifiers needed for a person or background process to continue the work.

These states also help support teams. A ticket marked “unknown after timeout” points to a reconciliation task. A ticket marked “failed before submission” points to a different recovery path. A generic error message loses that distinction.

A successful tool response can still be wrong

Error codes are only part of the problem. Tools may return stale information, incorrect records, or plausible text from an unreliable source. An HTTP success response establishes that a request was handled, not that the returned content is correct.

Agents’ Overreliance on Unreliable Tools, revised in September 2026, tested 14 models using corrupted returns from search, sub-agents, and code execution. The researchers found substantial adoption of incorrect tool content. Verification prompts helped in the revised study, but the results do not support treating prompting as a complete solution. [2]

For an operational agent, validation should follow the meaning of the action. Before updating an account, check that the returned account identifier matches the requested customer. Before quoting availability, check freshness and scope. Before describing a refund as complete, distinguish an accepted request from a settled transaction.

Important checks should live in code where possible. If a tool returns a different currency or a record from another tenant, the application can reject the result without asking the model to notice. The model can then explain the problem or request the missing information.

Avoid building a second full system just to verify the first. Start with the properties whose violation would change the outcome: identity, authorization, amount, status, and freshness where relevant. The right checks depend on the workflow.

Recovery needs an owner and a limit

Inngest’s May 2026 report surveyed 130 engineers about production AI workflows and highlighted reliability work, observability, and confidence in scaling. It is a vendor-run, self-reported survey, so correlations in the report do not establish that a particular tool causes better outcomes. Its relevance is that production work extends well beyond model selection. [3]

A recovery policy should specify when to retry, how to avoid duplicate effects, and when to stop. Where an API supports idempotency keys, use one stable key for the same intended operation. Where it does not, the integration needs another way to check prior execution before repeating the action.

Longer workflows should keep a durable record of progress. If the worker restarts, it should resume from the last confirmed state rather than recreating every step. When reversing an operation is possible, define the compensating action and verify that it succeeds.

Some actions cannot be cleanly reversed. An email already delivered cannot be unsent by changing a database field. Those cases need tighter checks before execution and a recovery plan that acknowledges the actual consequence.

The user also needs a credible end to the waiting period. Assign unresolved work to a person or a monitored process, with a deadline appropriate to the service. An agent that keeps promising to check again without owning the follow-up is leaving the customer in a loop.

Make failure injection part of agent development

A development environment designed around these failures would let engineers deliberately interrupt tools, return stale records, and simulate a write that succeeds just before the connection drops. The test would inspect both the resulting business state and what the agent told the user.

Coding agents could run the same cases while changing integration code, with failures reported as specific mismatches between a claim and its evidence. That would make an unsupported “done” as visible as a failed assertion in an ordinary software test.

Future products could maintain reusable fault scenarios for common business APIs and generate reconciliation tasks from unresolved operations. They could also compare recovery policies by duplicate effects, customer waiting time, and staff effort. This would move reliability work closer to the conditions that cause real incidents, while giving teams a concrete way to verify that their agent knows when the job is actually finished.