Por que os agentes de IA precisam de evidências antes de tentar novamente

Como impedir que uma resposta perdida leve a uma ação duplicada

Um agente de suporte autorizado a emitir um único reembolso envia a solicitação, mas perde a conexão. O agente não recebe confirmação de que a operação foi concluída e tenta enviar o reembolso novamente. Se a solicitação original tiver sido processada com sucesso, a nova tentativa do agente poderá resultar em um segundo reembolso.

Isso é puramente hipotético. O exemplo representa um problema que não pode ser resolvido apenas com a precisão do modelo. Que ações um agente deve tomar se não conseguir determinar se sua ação anterior alterou o estado do ambiente?

A Unite.AI já explorou a confiabilidade dos agentes para além dos modelos. Os problemas de recuperação merecem regras próprias nessas discussões. Antes de tentar novamente uma ação com consequências, o agente deve confirmar o que aconteceu ou contar com uma garantia válida contra efeitos duplicados.

A ausência de uma resposta não comprova que houve falha

A ausência de uma resposta não comprova que uma ação falhou. Ela não indica se ocorreu um erro antes da execução, se a ação foi concluída sem confirmação ou se o processo ainda está em andamento.

Esse é um problema comum em sistemas distribuídos, como explica a Amazon. A Amazon explica por que os mecanismos de nova tentativa precisam de salvaguardas específicas contra efeitos colaterais repetidos. Os agentes acrescentam uma nova entidade decisória ao processo de recuperação do sistema. Eles podem tomar decisões adicionais sobre como se recuperar de erros.

Essas decisões podem mudar a forma como os negócios são conduzidos. Por exemplo, tentar novamente um reembolso com um valor diferente não é apenas repetir a mesma solicitação. Da mesma forma, escolher um segundo serviço de pagamento quando o primeiro deixou de responder não é simplesmente repetir a mesma solicitação.

As equipes precisam distinguir entre conceder permissão para executar uma ação e conceder permissão para se recuperar de um resultado desconhecido. A aprovação original não significa que seja seguro executar a ação novamente.

Pesquisas recentes medem o risco

Um pré-print de setembro de 2026, “Onde se situa a execução exatamente uma vez?”, apresentou o benchmark LIMBO e testou 25.930 episódios em nove modelos. Os serviços simulados foram testados com confirmações perdidas, processamento atrasado e entregas duplicadas.

Dos 1.279 episódios em que foi gerado um efeito duplicado no teste principal dos autores, os agentes relataram a conclusão bem-sucedida em 90% dos casos. Portanto, um agente pode relatar sucesso mesmo quando ocorreu um processamento incorreto.

Esses resultados se baseiam em benchmarks controlados e não estimam as taxas de falha em produção. Os serviços foram simulados, e várias análises foram exploratórias. As equipes devem avaliar os resultados das ações dos agentes separadamente dos relatos de execução bem-sucedida.

O artigo também aborda por que verificar o estado atual pode não ser suficiente. Uma solicitação que ainda está sendo processada pode produzir efeito depois da verificação. Mesmo uma resposta de status vazia não significa que a solicitação não produzirá efeito mais tarde.

As tentativas repetidas devem corresponder à mesma intenção

Um serviço que recebe solicitações pode usar uma chave de idempotência para reconhecer tentativas repetidas de realizar uma operação. Quando há suporte adequado, esse método garante que as tentativas repetidas não produzam efeitos adicionais. A chave de idempotência deve permanecer a mesma em todas as tentativas.

A documentação da API da Stripe apresenta exemplos tanto dos mecanismos quanto das limitações das chaves de idempotência. Na API v1, as chaves podem ser excluídas após pelo menos 24 horas. Usar novamente uma chave excluída resultará em uma nova solicitação. A Stripe também verifica se os parâmetros fornecidos por quem fez a solicitação correspondem aos da solicitação inicial.

Na prática, a idempotência precisa estar presente na camada de integração, não apenas em um prompt. Antes de enviar uma operação, registre a operação aprovada. Armazene seu identificador, os parâmetros exatos, a referência do provedor, se aplicável, e o status da operação.

No caso de um reembolso, armazene a associação entre a aprovação e a transação original, bem como quaisquer identificadores de reembolso fornecidos pelo provedor. Procurar qualquer reembolso do mesmo valor é uma prova menos convincente, pois duas solicitações legítimas podem ter o mesmo valor. Também pode haver um atraso entre a solicitação de reembolso e sua aparição nos resultados da busca. A solicitação original ainda pode estar em andamento.

Quando um agente ou processo de trabalho é reiniciado, a camada de execução deve preservar essa identidade. Ela deve rejeitar uma solicitação modificada enviada como se fosse a mesma operação. Essa alteração representa uma nova ação, que exige uma nova decisão de aprovação de acordo com as regras do fluxo de trabalho.

Descrições de ferramentas não são suficientes

Além de consultar as descrições das ferramentas, verifique o contrato do serviço que recebe as solicitações para confirmar se há suporte à idempotência. Teste a implementação para confirmar quais garantias são realmente cumpridas.

Trate a incerteza como um estado operacional

Figura 1. Um fluxo de recuperação proposto para ações com consequências. Cada nova tentativa também exige autorização vigente.

A conclusão confirmada significa que o fluxo de trabalho registrará o resultado e continuará sem repetir a ação. A confirmação de que a ação não foi executada permite uma nova tentativa somente se não houver nenhuma solicitação original ainda pendente e a autorização continuar válida.

Há muito mais a considerar quando o resultado não é conclusivo. Se houver uma garantia válida, respaldada pelo provedor, contra efeitos duplicados, você poderá permitir que a solicitação original seja repetida com a mesma chave. Caso contrário, suspenda as operações de escrita e esclareça a situação por meio de uma consulta de status, do suporte do provedor ou de um operador autorizado. Uma verificação inconclusiva não é motivo suficiente para autorizar outra tentativa.

Também pode ser justificável pausar quando o provedor documenta os limites de processamento e de visibilidade. Sem esses limites, o simples tempo decorrido não confirmará que a ação não foi executada. É preciso definir quem será responsável pelos casos não resolvidos e quando essas pessoas deverão analisá-los.

A recuperação de uma falha pode exigir um processo de negócio diferente

Se um reembolso for realizado com sucesso, mas a notificação subsequente ao cliente falhar, repetir todo o fluxo de trabalho poderá gerar outro reembolso. A recuperação deve se concentrar em concluir a etapa inacabada, preservando as evidências do trabalho já concluído.

Se forem necessárias ações corretivas para ações já concluídas, a Microsoft oferece orientações sobre transações compensatórias. Cada aplicação determina a maneira correta de compensar erros. A compensação pode não necessariamente restabelecer a situação inicial, e ela própria pode falhar.

Além disso, cancelar uma transação pode gerar uma cobrança. Corrigir uma mensagem não garante que alguém não tenha visto uma versão anterior. Portanto, qualquer atividade de recuperação deve limitar explicitamente o que o agente pode desfazer, alterar ou se comprometer a fazer. Decisões que ultrapassem esses limites devem ser encaminhadas a uma pessoa com a autoridade necessária.

Teste a segunda tentativa antes da implantação

Escolha uma ferramenta com consequências relevantes e faça testes deliberados de recuperação em um ambiente de teste. Após uma execução bem-sucedida, descarte a resposta à solicitação original. Adie a execução da primeira solicitação até depois de uma consulta de status. Durante a recuperação, reinicie o processo de trabalho. Aguarde a expiração do período de retenção da chave antes de tentar novamente. Altere um parâmetro durante as tentativas repetidas.

Avalie os registros de negócio resultantes, em vez de confiar apenas nas respostas das ferramentas. Registre efeitos duplicados, operações não resolvidas, tarefas não realizadas, tempo de recuperação e intervenções manuais adicionais. Calcule o custo por tarefa concluída corretamente com base nos custos totais do fluxo de trabalho, incluindo estornos de transações e medidas de reparação para os clientes.

Além disso, teste uma segunda solicitação genuína, semelhante à original. Certifique-se de que o sistema evite criar duplicatas sem impedir a realização de novas tarefas. Avalie separadamente a prevenção de duplicatas e a conclusão das tarefas. Caso contrário, um agente que encerre todas as tarefas poderá parecer seguro, embora gere pouco ou nenhum valor.

A pergunta da avaliação deve ser formulada com clareza. O sistema foi capaz de explicar:

• Qual operação foi autorizada?
• Que evidências havia para demonstrar o resultado?
• Por que era permitido fazer outra tentativa?

Um agente que pausa diante de uma incerteza não resolvida pode parecer menos eficaz durante demonstrações. No entanto, em ambientes de produção, pausar pode preservar a intenção original do cliente. Uma persistência útil significa que o sistema conclui as tarefas autorizadas sem executá-las silenciosamente em duplicidade.