Rodrigo Jorge · Preparado em 15 de outubro de 2026, às 06:02 (horário de Brasília, UTC-3). Horário de publicação a confirmar.
Um agente solicita a criação de um ambiente isolado para analisar um arquivo suspeito. O serviço aceita o pedido, mas a resposta não chega. O agente recebe um timeout e tenta de novo.
Quantos ambientes foram criados?
Esse cenário é hipotético. A resposta depende do contrato da API e de como a integração repetiu o pedido. Se cada tentativa representar uma nova criação, o retry pode gerar outro ambiente. Se houver deduplicação adequada, as tentativas podem corresponder à mesma operação.
Como CISO, eu perguntaria isso antes de discutir se o modelo interpretou bem o arquivo. A decisão pode estar correta e a execução produzir um efeito que ninguém autorizou duas vezes.
A Amazon Builders' Library, em texto de Malcolm Featonby, discute justamente a incerteza causada pela perda de uma resposta e o uso de identificadores de pedido para tornar retries seguros. O problema antecede agentes de IA. Eles precisam respeitar o contrato da ferramenta quando decidem chamá-la novamente.
Repetir o pedido ou criar outro?
Na documentação do EC2, RunInstances está entre as ações que aceitam um client token para idempotência. Repetir com o mesmo token e parâmetros, dentro do escopo previsto, evita nova execução. Esse escopo importa: a garantia pode ser regional ou por Availability Zone. Usar o mesmo token em outro escopo pode criar recursos adicionais.
Isso documenta um mecanismo específico. Não demonstra que toda API usada por um agente ofereça a mesma proteção, nem que o retry feito pelo modelo preserve o token usado pela integração.
Minha proposta é tratar a identificação da operação como responsabilidade da integração. O identificador deve persistir nas tentativas da mesma operação, inclusive quando houver reinício do processo. Trocar a chave a cada chamada pode transformar uma repetição em um pedido novo. Reutilizá-la para uma intenção diferente também é erro.
Antes de habilitar retry automático, a equipe precisa conferir onde a API reconhece duplicatas, por quanto tempo guarda essa informação e o que acontece se os parâmetros mudarem. Um campo chamado request_id pode servir apenas para rastreamento. O nome não comprova idempotência.
Ver o diagrama: a ação pode terminar antes de o timeout aparecer. Sequência hipotética, sem tempos ou resultados medidos.
Quando a API não oferece essa garantia, consultar o estado da operação pode ajudar. Mas uma consulta vazia também exige interpretação: o estado já deveria estar visível? Se ainda não é possível saber o que ocorreu, o fluxo pode precisar parar para reconciliação em vez de enviar outro pedido. Essa decisão depende do custo de duplicar a ação e do custo de esperar.
O teste que eu pediria é perder deliberadamente a resposta depois de o serviço aceitar o pedido, em laboratório, e observar a tentativa seguinte. Não basta contar chamadas: é preciso contar efeitos no serviço de destino e verificar o comportamento depois de reiniciar a integração.
Um retry autorizado deve continuar sendo a mesma operação autorizada. Se a integração não consegue demonstrar isso, o timeout precisa permanecer registrado como resultado desconhecido, até que haja evidência para resolver a incerteza.
Referências
- Malcolm Featonby, Amazon Builders' Library: Making retries safe with idempotent APIs, consultado em 15 de outubro de 2026.
- AWS EC2: Ensuring idempotency in Amazon EC2 API requests, documentação consultada em 15 de outubro de 2026.