An AI Agent Timed Out. The Shipment May Still Be Moving

Consider a support agent handling a replacement laptop. It verifies the customer’s entitlement, confirms the delivery address, checks inventory, then reaches step four: calling a warehouse tool to create the shipment.

The warehouse receives the request and starts writing the shipment record. Before its response reaches the agent, a gateway closes the connection. The tool runner reports a timeout.

At that point, two outcomes remain plausible. The warehouse may have rejected or never received the request, leaving no shipment to fulfill. It may also have committed the shipment and returned too late, in which case a laptop is already moving through the warehouse even though the agent’s log shows no success response.

A blind retry turns that uncertainty into a business error. If the first call finished, the second can create another shipment, reserve another laptop and generate another tracking number. If the agent refuses to retry, a customer whose first request never arrived gets nothing.

This is not primarily a model reasoning problem. The surrounding orchestration layer needs a protocol for ambiguous actions.

A timeout marks the caller’s limit

A timeout is the point at which a caller stops waiting for a result. It does not cancel work unless the receiving system supports cancellation, receives that request in time and can still reverse the operation.

The failure can occur at several boundaries. The agent’s tool runner may give up while the gateway continues waiting. A gateway may close its connection after passing the request to a queue. The warehouse service may commit its database transaction, then lose the response on its way back.

From the agent’s position, these cases look similar: no confirmed result arrived before the deadline.

Longer timeouts reduce some false failures, but they do not remove the ambiguity. They also keep agent runs and worker capacity occupied for longer, which raises latency and infrastructure cost while making genuinely stuck calls slower to detect. The safer design assumes that any network call can end without revealing the final business outcome.

One business action keeps one identity

The first control is an idempotency key, a client-generated identifier that tells a tool repeated requests belong to the same intended action. For the replacement laptop, the orchestrator creates a key before step four and stores it with the replacement case. Every attempt to create that shipment uses the same key.

On the first request, the warehouse tool records the key and the result under a uniqueness constraint. If the request arrives again, the tool does not create a second shipment. It returns the stored result or reports that the original operation is still running.

The key must survive more than one model turn. Keeping it only in a prompt or temporary agent memory is fragile because a restarted run may regenerate the plan and produce a new key, which the warehouse correctly interprets as a new action. The durable workflow record should bind the replacement case, intended operation, request payload and idempotency key before the external call begins.

Payload handling matters too. If the agent retries the same key with a different address or laptop configuration, the tool should reject the mismatch rather than guess which request is authoritative. A stored hash of the original payload can support that check without treating a changed request as an innocent retry.

Idempotency has limits. The receiving tool must honor the key across concurrent requests, and its retention period must cover the longest plausible retry window. If keys expire after a short interval while an agent can resume days later, an old retry may create a fresh shipment. Scope also matters: the warehouse should compare keys within the correct customer account and operation, not across unrelated actions.

Exactly-once execution, the guarantee that one requested business action happens one time, is difficult across separate systems. Idempotency gets closer by making repeated delivery safe, but only if the side effect and the key record cannot drift apart.

Status checks resolve the common cases

After the step-four timeout, the agent should not immediately repeat the shipment request. It should query a status endpoint using the same client-generated identifier, even if the timeout happened before the warehouse returned its own operation ID.

A useful status response distinguishes work that was never accepted from work that is pending, completed or conclusively failed. “Not found” needs special care. It may mean the original request never arrived, but it can also reflect delayed indexing or a status store that has not caught up with the transactional system. The orchestrator can wait and check again, using progressively longer intervals to avoid hammering the tool.

Once the warehouse reports a completed shipment, the agent records the tracking reference and moves to the notification step. A conclusive failure before shipment creation permits another attempt with the original key. A pending result keeps the workflow paused. An unavailable or inconsistent status response leaves the outcome unknown.

That last state must be explicit. If a tool adapter reduces every call to a success-or-failure Boolean, the agent will eventually interpret “failure” as permission to try again, even though the adapter only knows that it stopped waiting.

Reconciliation catches what polling misses

Some ambiguous calls outlive the agent run. A warehouse status service can be unavailable, a callback can go missing, or the support workflow can restart after its temporary context has been discarded. Reconciliation, a later comparison between records that should describe the same operation, closes that gap.

For the laptop case, a scheduled worker scans replacement cases whose shipment outcome remains unknown. It looks up the idempotency key or replacement case identifier in the warehouse system, then attaches any matching shipment to the support record. If no shipment appears after the system’s defined uncertainty window, the worker can retry with the original key. Conflicting records go to a human queue instead of being handed back to the model as an open-ended puzzle.

This adds database writes, status reads and delayed completion. Polling also consumes tool capacity, while a manual review queue costs staff time. Those costs should be compared with the consequence of duplication: an extra calendar event may be reversible, but a second laptop shipment creates inventory, logistics and recovery work.

Reconciliation needs its own audit trail. The record should show the original request identity, each attempt, every observed status and the rule that authorized a retry. Without that history, operators can see two shipments but cannot determine whether the agent changed its goal, the tool ignored a key or a recovery worker acted on stale information.

The model should not own retry permission

The language model can decide that creating a replacement shipment is the next appropriate step. It should not infer from a timeout message that the step is safe to repeat.

Put that decision in deterministic orchestration code, where the same recorded state produces the same retry behavior. The tool contract can expose confirmed success and confirmed failure as distinct outcomes; any response that does not establish either becomes unknown. The workflow then allows only status checks, cancellation attempts or escalation until that unknown state is resolved.

This boundary also protects the workflow from persuasive but unsupported model output. An agent may write that the shipment “probably did not go through” after seeing a timeout, yet probability is not evidence that the warehouse lacks a record. The orchestrator should require a machine-verifiable status or a human decision before releasing another side effect.

Teams adopting agent tools can test this behavior without evaluating the model’s prose. Delay the warehouse response after committing a shipment, drop the response entirely, restart the agent and send concurrent retries with the same key. The passing result is one shipment linked to one replacement case, with the recovered status visible in the run history.

If the underlying tool offers neither idempotency nor lookup by a stable client identifier, full automation is a poor fit for consequential writes. The practical fallback is to stop after an ambiguous result and place the replacement case in a review queue. That is slower than another POST request. It is also cheaper than mailing the same laptop twice.

Questions people ask

Should an

AI agent retry every timed-out tool call?

No. Read-only calls are often safe to repeat, but a call that creates, sends, charges, books or deletes something may already have finished. The agent should retry only when the tool makes repetition idempotent or another status check confirms that the side effect did not occur.

Does an idempotency key guarantee there will be no duplicate action?

Not by itself. The receiving system must store the key with the business result, reject changed payloads and retain the record through the retry window. A key generated only inside the agent’s temporary context also fails after a restart because the next run may create a different identity.

What if the tool has no status endpoint?

Look for another authoritative record, such as a shipment search keyed to the replacement case. If no reliable lookup exists, treat the result as unknown and send it to human review. Repeating an irreversible action based only on elapsed time does not resolve the original uncertainty.

How long should an agent keep an idempotency record?

Keep it at least as long as the workflow can retry or resume, including delayed recovery jobs and human approvals. The tool and orchestrator need compatible retention rules; otherwise, the agent may present an old key after the receiving system has forgotten the original shipment request.