---
title: "A timeout does not prove the action failed"
slug: "timeout-nao-e-falha"
date: "2026-10-15"
publishedAt: "2026-10-15T06:02:00-03:00"
author: "Rodrigo Jorge"
summary: "The agent never received a response. That does not mean the service never executed the request. Before retrying an action, the integration needs to handle that uncertainty."
origem: "Analysis"
status: "published"
---

**Rodrigo Jorge** · Prepared October 15, 2026, at 6:02 a.m. Brasília time (UTC-3). Publication time to be confirmed.

An agent requests an isolated environment to analyze a suspicious file. The service accepts the request, but the response never arrives. The agent gets a timeout and tries again.

How many environments were created?

This is a hypothetical scenario. The answer depends on the API contract and how the integration retried the request. If each attempt counts as a new creation request, the retry may create another environment. With appropriate deduplication, the attempts may resolve to the same operation.

As a CISO, I would ask that question before discussing whether the model correctly interpreted the file. The decision may be sound, yet the execution may produce an effect no one authorized twice.

In the Amazon Builders' Library, Malcolm Featonby examines exactly this uncertainty when a response is lost, and how request identifiers can make retries safe. The problem predates AI agents. When they decide to call a tool again, they need to respect its contract.

## Retrying a request or creating a new one?

The EC2 documentation lists `RunInstances` among the actions that accept a `client token` for idempotency. Retrying with the same token and parameters, within the defined scope, prevents another execution. That scope matters: the guarantee can be regional or limited to an Availability Zone. Using the same token in a different scope can create additional resources.

This documents one specific mechanism. It does not establish that every API an agent uses offers the same protection, or that a retry initiated by the model preserves the token used by the integration.

I propose making operation identity the integration's responsibility. The identifier should persist across attempts for the same operation, including after a process restart. Changing the key with every call can turn a retry into a new request. Reusing it for a different intent is also an error.

Before enabling automatic retries, the team needs to check the scope in which the API recognizes duplicates, how long it retains that information, and what happens if the parameters change. A field named `request_id` may be used only for tracing. Its name does not prove idempotency.

[View the diagram: the action may complete before the timeout appears](/assets/artigos/timeout-nao-e-falha-en.svg). A hypothetical sequence, with no measured timings or results.

When the API does not provide this guarantee, querying the operation's state may help. But an empty result also needs interpretation: should the state be visible by now? If the outcome is still unknown, the workflow may need to pause for reconciliation rather than send another request. That decision depends on the cost of duplicating the action and the cost of waiting.

The test I would ask for is to deliberately drop the response after the service accepts the request, in a lab, and observe the next attempt. Counting calls is not enough: the team needs to count effects in the destination service and check what happens after the integration restarts.

An authorized retry must remain the same authorized operation. If the integration cannot demonstrate that, the timeout needs to stay recorded as an unknown outcome until evidence resolves the uncertainty.

### References

- [Malcolm Featonby, Amazon Builders' Library: Making retries safe with idempotent APIs](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/), accessed October 15, 2026.
- [AWS EC2: Ensuring idempotency in Amazon EC2 API requests](https://docs.aws.amazon.com/ec2/latest/devguide/ec2-api-idempotency.html), documentation accessed October 15, 2026.