O Agente criou o pedido, mas o pagamento falhou: o que fazer quando só metade da tarefa foi concluída?

Imagine que um Agente recebeu a seguinte tarefa:

Criar o pedido do cliente, reservar o produto, gerar a cobrança, registrar a venda no CRM e enviar a confirmação pelo WhatsApp.

As duas primeiras etapas funcionaram. O pedido foi criado e o estoque foi reservado. Na terceira, a API de pagamento retornou um erro.

O que deveria acontecer agora?

Executar tudo novamente parece simples. Só que isso pode criar um segundo pedido e reservar o mesmo produto duas vezes.

Ignorar o erro também não resolve. Existe agora um pedido criado, talvez com estoque comprometido, mas sem pagamento e sem conclusão do processo.

Esse problema aparece quando Agentes deixam de apenas responder perguntas e passam a executar processos reais dentro da operação.

O desafio não é somente fazer o Agente chegar ao resultado quando tudo funciona. É saber até onde o processo chegou e o que fazer quando apenas parte dele foi concluída.

Os princípios de confiabilidade do Agentic AI Lens, da AWS, tratam diretamente desse cenário. Entre as recomendações estão responsabilidades menores, mensageria durável e recuperação a partir do último estado conhecido como correto, em vez de reiniciar toda a execução.

“Finalizar uma venda” pode esconder várias mudanças de estado

Para o cliente, “finalizar a compra” parece uma única tarefa.

Para os sistemas da empresa, pode ser uma sequência como:

1. identificar o cliente;

2. consultar disponibilidade;

3. criar o pedido;

4. reservar estoque;

5. criar a cobrança;

6. confirmar o pagamento;

7. atualizar o CRM;

8. enviar a confirmação.

Cada etapa pode modificar um sistema diferente.

Isso significa que uma falha na sexta etapa não apaga automaticamente as cinco anteriores.

O pedido pode continuar existindo.

A reserva pode continuar ativa.

A cobrança pode ter sido criada.

E o CRM ainda pode não saber de nada.

Por isso, workflows longos precisam ser tratados como uma sequência de estados verificáveis. A AWS recomenda workflows em estágios com recuperação incremental, com saídas persistidas entre etapas e retomada a partir do último estágio concluído.

A pergunta deixa de ser apenas:

“A tarefa funcionou?”

E passa a ser:

“Qual foi o último estado confirmado desse processo?”

Essa segunda pergunta é muito mais útil quando alguma coisa dá errado.

O erro mais perigoso pode ser executar tudo novamente

Considere este fluxo:

Pedido criado → estoque reservado → pagamento processado → CRM atualizado → confirmação enviada

Se o pagamento apresentar erro, reiniciar o processo inteiro pode criar outro pedido e reservar novamente o estoque antes de chegar a uma nova tentativa de pagamento.

O risco aumenta porque uma resposta de erro nem sempre significa que a operação não aconteceu.

Imagine que o Agente envie uma requisição de cobrança.

O provedor recebe a solicitação, processa o pagamento e, antes de devolver a resposta, a conexão é interrompida.

Do ponto de vista do Agente, houve um timeout.

Do ponto de vista do sistema financeiro, talvez o cliente já tenha sido cobrado.

O resultado pode estar em três estados diferentes:

• a operação não aconteceu;
• a operação aconteceu e falhou;
• a operação aconteceu com sucesso, mas a resposta não chegou.

Tentar novamente sem descobrir em qual desses estados a operação se encontra pode transformar uma falha de comunicação em uma cobrança duplicada.

Esse cenário se conecta ao problema mais amplo de definir o comportamento do Agente quando CRM, agenda ou sistema de pagamento sai do ar. A diferença é que, em uma falha parcial, algumas etapas anteriores já produziram efeitos reais e precisam ser preservadas ou compensadas.

Cada etapa precisa deixar um estado observável

Um processo importante não deveria existir apenas dentro do raciocínio momentâneo do Agente.

O sistema precisa registrar o que aconteceu.

Em vez de manter somente:

Processo: em andamento

o workflow pode registrar estados específicos:

• Pedido: criado
• Estoque: reservado
• Pagamento: pendente
• CRM: aguardando atualização
• Mensagem: aguardando envio

Se a operadora recusar a cobrança:

Pagamento: falhou

Se houver um timeout e o sistema ainda não souber o resultado:

Pagamento: resultado desconhecido

Essa distinção muda a recuperação.

“Falhou” permite tomar uma nova decisão.

“Resultado desconhecido” exige primeiro descobrir o que realmente aconteceu.

Antes de repetir uma cobrança cujo resultado é desconhecido, por exemplo, o sistema pode consultar o provedor utilizando o identificador da transação. Depois dessa reconciliação, decide se continua, repete ou interrompe o processo.

É também por isso que memória não pode virar fonte de verdade operacional.

O Agente pode lembrar que tentou cobrar o cliente. Quem precisa confirmar se a cobrança existe é o sistema responsável pelo pagamento.

Checkpoints permitem continuar sem reconstruir o passado

Pense em checkpoints como pontos de salvamento da execução.

Depois que o pedido é criado, o sistema persiste o resultado.

Depois da reserva de estoque, registra outro checkpoint.

Depois da confirmação do pagamento, registra novamente.

A AWS descreve essa abordagem em sua orientação sobre gestão de estado e recuperação por checkpoints.

Se uma etapa posterior falhar, o sistema não precisa perguntar ao modelo quais ações ele acredita ter executado.

Ele possui evidências.

Em nosso exemplo, um checkpoint poderia armazenar algo semelhante a:

• pedido `12345` criado;
• reserva `RES-908` confirmada;
• pagamento aguardando reconciliação;
• atualização do CRM ainda não iniciada.

Se o processo precisar ser retomado, criação do pedido e reserva não precisam acontecer novamente.

A execução continua a partir do próximo ponto válido.

Isso reduz retrabalho e, principalmente, diminui o risco de repetir efeitos que já aconteceram no mundo real.

Retomar do checkpoint não basta se repetir a etapa ainda for perigoso

Agora suponha que o workflow tenha registrado:

Pedido criado: concluído

Estoque reservado: concluído

Pagamento: pendente

A execução é retomada diretamente no pagamento.

Melhor do que começar tudo outra vez.

Mas existe outra pergunta:

É seguro chamar a cobrança novamente?

Se a tentativa anterior tiver sido processada antes da conexão cair, uma nova chamada pode cobrar o cliente duas vezes.

É aqui que entra a idempotência.

A AWS considera retries sem proteção contra duplicidade um antipadrão de alto risco e recomenda execução idempotente de tarefas.

Uma operação idempotente pode ser repetida para a mesma operação lógica sem criar um novo efeito.

Em vez de o sistema enviar simplesmente:

`criar cobrança de R$ 500`

ele associa uma identificação estável àquela cobrança, como:

`pagamento-pedido-12345`

Se o mesmo passo precisar ser repetido, a chave continua representando a mesma operação.

A documentação de idempotent requests da Stripe mostra uma aplicação prática desse princípio. Uma requisição pode ser reenviada com a mesma chave de idempotência para evitar que um erro de conexão resulte acidentalmente em uma segunda operação.

A lógica também pode ser aplicada a outras ações:

• criação de pedidos;
• geração de propostas;
• abertura de chamados;
• criação de reservas;
• emissão de documentos;
• disparo de determinadas mensagens;
• atualização de registros;
• criação de tarefas.

Checkpoint responde onde retomar.

Idempotência responde como retomar sem duplicar o que já aconteceu.

Os dois mecanismos precisam funcionar juntos.

Nem toda falha deve gerar retry

Recuperação não significa repetir automaticamente toda operação que apresenta erro.

Os tipos de falha são diferentes.

Uma indisponibilidade temporária do serviço pode justificar uma nova tentativa depois de alguns segundos.

Uma credencial expirada dificilmente será corrigida com dez chamadas consecutivas.

Um timeout pode exigir reconciliação antes do retry.

Um cartão recusado é uma falha de negócio. Repetir a mesma cobrança várias vezes não resolve a causa.

Um produto que deixou de existir exige uma nova decisão.

Uma resposta inválida de uma integração pode exigir intervenção antes que o processo continue.

Uma política de recuperação pode separar pelo menos quatro situações:

1. Falha transitória: uma nova tentativa controlada pode resolver.

2. Falha persistente: o serviço continua indisponível ou a configuração está incorreta.

3. Falha de negócio: o sistema funcionou, mas a operação foi recusada pelas próprias regras do negócio.

4. Resultado desconhecido: não há evidência suficiente para saber se a operação aconteceu.

Retries também precisam de limites.

Se uma API estiver indisponível, centenas de Agentes repetindo chamadas continuamente podem piorar o problema. Backoff, número máximo de tentativas e filas ajudam a impedir que uma dependência instável provoque uma nova falha em cascata.

Um Agente confiável não deveria possuir apenas uma função de “tentar novamente”.

Ele precisa operar dentro de uma política de recuperação.

Quando continuar e quando desfazer o que já aconteceu?

Depois de identificar o último estado confirmado, surge outra decisão:

Preservamos o progresso ou compensamos as etapas anteriores?

Voltemos ao cenário inicial.

O pedido foi criado.

O estoque foi reservado.

O pagamento falhou.

Uma empresa pode decidir manter o pedido e a reserva durante 30 minutos e enviar uma nova opção de pagamento ao cliente.

Nesse caso, queremos recuperação para frente.

O progresso já realizado continua válido e o processo tenta chegar ao estado final por outro caminho.

Outra empresa pode determinar que nenhuma reserva continue ativa sem pagamento confirmado.

Nesse caso, será necessário:

1. liberar o estoque;

2. cancelar o pedido;

3. registrar o motivo do cancelamento.

Essa lógica aparece no padrão Saga, usado para coordenar processos distribuídos compostos por várias transações. Se uma etapa falha, o processo pode seguir por recuperação para frente ou executar transações compensatórias.

Compensar, porém, não significa fingir que a ação anterior nunca aconteceu.

Se uma nota fiscal já foi emitida, talvez exista um procedimento formal de cancelamento.

Se uma mensagem já chegou ao cliente, não existe um comando que apague o que ele leu. Pode ser necessário enviar uma correção.

Se um pagamento foi confirmado, o caminho pode ser um estorno, não a exclusão da transação.

Processos reais deixam efeitos reais.

Por isso, cada etapa importante deveria responder previamente a duas perguntas:

Qual evidência confirma que esta etapa terminou corretamente?

Se uma etapa posterior falhar, o que precisa acontecer com este efeito?

Um playbook para falhas parciais

Quando um Agente para no meio de um processo, uma política prática de recuperação pode seguir esta sequência.

1. Identifique o último estado confirmado

Não parta da intenção do Agente.

Procure os efeitos registrados nos sistemas envolvidos.

O pedido existe? A reserva está ativa? A cobrança foi criada? O CRM recebeu a atualização?

2. Determine o estado da etapa interrompida

Diferencie três situações:

• sucesso confirmado;
• falha confirmada;
• resultado desconhecido.

A terceira situação merece atenção especial porque um retry imediato pode duplicar uma ação que já aconteceu.

3. Reconcilie resultados desconhecidos

Consulte o sistema responsável.

Se uma cobrança ficou sem resposta, procure a transação pelo identificador conhecido.

Se a criação de um pedido terminou em timeout, verifique se o pedido já existe antes de criar outro.

4. Verifique se repetir a operação é seguro

Use idempotência, identificadores determinísticos ou consulta prévia quando a ferramenta permitir efeitos duplicados.

Quanto maior o impacto da ação, menos aceitável é um retry cego.

5. Classifique a falha

Defina se o problema é transitório, persistente, relacionado às regras de negócio ou resultado de um estado ainda desconhecido.

A classificação define a estratégia seguinte.

6. Escolha entre continuar ou compensar

Preserve o que já foi concluído quando esse progresso ainda tiver valor.

Execute ações compensatórias quando as regras da empresa exigirem que o processo volte a outro estado consistente.

7. Registre o resultado da recuperação

A própria recuperação também precisa produzir estado.

Se a reserva foi cancelada, isso deve ficar registrado.

Se o pagamento foi reconciliado e estava aprovado, o workflow precisa persistir essa descoberta antes de avançar.

8. Escale quando a decisão ultrapassar a autonomia permitida

Nem todo estado precisa ser resolvido automaticamente.

Impacto financeiro alto, divergência entre sistemas, cancelamentos sensíveis ou situações impossíveis de reconciliar com segurança podem exigir revisão humana.

Quando isso acontecer, logs e traces precisam permitir ao operador reconstruir o caminho que levou ao erro, em vez de analisar apenas a última mensagem exibida ao cliente.

Responsabilidades menores diminuem o tamanho da falha

Existe uma escolha arquitetural anterior a toda política de recuperação: não concentrar responsabilidades demais em uma única operação.

“Finalize a venda” é um objetivo de negócio válido.

Internamente, porém, esse resultado deveria ser dividido em tarefas menores e verificáveis.

Por exemplo:

Criar pedido

Reservar estoque

Criar cobrança

Confirmar pagamento

Atualizar CRM

Enviar confirmação

Quando essas fronteiras são explícitas, cada tarefa pode possuir:

• entrada definida;
• resultado esperado;
• timeout;
• política de retry;
• chave de idempotência;
• checkpoint;
• ação compensatória;
• regra de escalonamento.

Isso torna muito mais simples dizer:

“A etapa de pagamento falhou. Retome a partir dela.”

Do que dizer:

“O Agente de vendas parou em algum momento. Descubra tudo o que ele já fez.”

Responsabilidades menores criam pontos claros de confirmação, falha e recuperação.

Mensageria durável ajuda o processo a sobreviver às interrupções

Processos com várias integrações também podem falhar porque uma etapa depende imediatamente da disponibilidade da seguinte.

Imagine que o pedido foi confirmado, mas o CRM está fora do ar.

Se toda a cadeia depender de chamadas síncronas, essa indisponibilidade pode derrubar o processo completo.

A orientação da AWS sobre camada de mensageria resiliente recomenda persistência, retries e tratamento de mensagens que falham repetidamente para evitar que uma indisponibilidade temporária se transforme em perda da tarefa.

Em vez de depender de:

`pagamento confirmado → CRM precisa responder agora`

o sistema pode registrar uma tarefa durável:

`atualizar CRM para pedido 12345`

Se o CRM estiver indisponível, a tarefa continua existindo e pode ser processada posteriormente de acordo com a política definida.

Esse desenho também é útil quando é necessário separar conversa e execução em processos longos. O cliente não precisa permanecer esperando enquanto cada sistema termina sua parte.

Mensageria, checkpoints e idempotência resolvem problemas diferentes:

mensageria durável evita perder a tarefa;

checkpoints evitam perder o progresso;

idempotência evita duplicar os efeitos.

Uma plataforma de orquestração precisa conhecer o progresso da execução

Em uma demonstração, é fácil mostrar um Agente recebendo uma solicitação, chamando ferramentas em sequência e chegando ao resultado.

Produção é diferente.

APIs ficam indisponíveis.

Conexões caem.

Credenciais expiram.

Uma etapa demora mais que o esperado.

Um sistema confirma uma operação enquanto outro rejeita a seguinte.

O usuário altera uma informação enquanto o processo ainda está em andamento.

Por isso, plataformas de orquestração durável mantêm o histórico da execução e permitem recuperar uma tarefa do ponto em que ela parou.

O redrive do AWS Step Functions, por exemplo, permite continuar determinadas execuções malsucedidas a partir da etapa que falhou, preservando os resultados das etapas anteriores que já foram concluídas.

A tecnologia específica pode mudar.

O princípio não:

um processo confiável precisa conhecer seu próprio progresso.

Antes de delegar um processo inteiro à IA, desenhe também o caminho da falha

Ao projetar uma automação, é natural perguntar:

“O que deve acontecer quando tudo funcionar?”

A pergunta seguinte deveria ser:

“O que acontece se o processo parar exatamente aqui?”

Faça essa pergunta depois da criação do pedido.

Depois da reserva.

Depois da cobrança.

Depois da confirmação do pagamento.

Depois da atualização do CRM.

Depois do envio da mensagem.

Para cada etapa, defina:

• qual evidência representa sucesso;
• onde esse estado será persistido;
• como descobrir o resultado em caso de timeout;
• se a operação pode ser repetida;
• qual chave identifica aquela tentativa lógica;
• quantos retries são aceitáveis;
• quando o fluxo deve parar;
• quando deve seguir por outro caminho;
• se existe uma ação compensatória;
• quando uma pessoa precisa assumir.

Essas decisões parecem aumentar a complexidade da automação.

Na prática, a complexidade já existe no processo de negócio.

Ignorá-la apenas significa descobrir suas consequências quando a primeira falha acontecer.

Agentes capazes de executar tarefas tornam automações muito mais úteis porque conseguem participar de processos que antes dependiam integralmente de pessoas.

Essa autonomia também aumenta a responsabilidade da arquitetura.

Um processo delegado à IA precisa definir não apenas como começa e como termina, mas também como se recupera quando para no meio.

Em operações reais, saber continuar corretamente depois de uma falha pode ser mais importante do que executar o caminho perfeito na primeira tentativa.