Ações compensatórias são operações que corrigem efeitos de etapas já concluídas quando um fluxo de um agente de IA falha. Se o agente reservou um produto e depois descobriu que o pedido não pode prosseguir, a compensação pode liberar aquela reserva. Isso não significa voltar o mundo exatamente ao estado anterior.
Para implementar, defina antes da execução quais efeitos cada ferramenta produz, como confirmar o resultado e qual correção é possível. Grave o andamento fora da conversa do modelo. O agente pode propor o caminho, mas a aplicação precisa controlar permissões, repetição, recuperação e aprovação de ações irreversíveis.
Resumo rápido
- Rollback de banco e compensação entre sistemas resolvem problemas diferentes.
- Uma Saga organiza etapas locais e a recuperação de falhas em um processo distribuído.
- Timeout não prova que uma operação deixou de acontecer: consulte o resultado antes de repetir.
- Compensações também falham e precisam de estado persistente, novas tentativas e responsável.
- Mensagens enviadas e efeitos físicos exigem tratamento específico; não prometa desfazer tudo.
Rollback, compensação e Saga: o que muda
No banco de dados, uma transação agrupa operações segundo garantias do mecanismo. O tutorial do PostgreSQL sobre transações mostra como COMMIT confirma mudanças e ROLLBACK abandona alterações ainda não confirmadas. Essa fronteira não se estende automaticamente a um e-mail, outro serviço ou uma transportadora.
Uma compensação é uma nova operação de negócio. Cancelar uma reserva confirmada gera um fato novo, mesmo que o saldo disponível volte ao mesmo valor. A orientação da Microsoft sobre transações compensatórias destaca que a correção depende das regras do domínio e pode não restaurar o estado original.
Uma Saga coordena uma sequência de transações locais em serviços diferentes. Quando uma etapa falha, o processo usa as correções previstas para os efeitos anteriores. Isso não oferece a mesma atomicidade de uma única transação no banco.
| Mecanismo | Fronteira | Exemplo |
|---|---|---|
| Rollback transacional | Alterações de uma transação ainda não confirmada | Abandonar gravações locais após erro de validação |
| Ação compensatória | Efeito já confirmado, corrigido por outra operação | Liberar reserva identificada de estoque |
| Saga | Coordenação de várias etapas locais | Orquestrar reserva, aprovação e preparação de entrega |
| Tratamento de efeito irreversível | Consequência que não admite inversão completa | Corrigir mensagem já lida pelo destinatário |
Como recomendação de projeto, use o mecanismo mais simples que cobre a fronteira real do processo. Não introduza uma Saga para corrigir duas gravações que cabem numa transação local. Também não chame de rollback uma sequência de requisições independentes que pode ficar incompleta.
Descrever cada ferramenta como uma operação de negócio
Antes de habilitar ferramentas de escrita, crie um catálogo de efeitos. Para cada operação, informe pré-condições, identificador do recurso afetado, retorno esperado, possibilidade de consulta posterior e forma de compensação. Esse catálogo deve existir no código ou na configuração controlada, sem depender apenas do prompt.
Recomendamos um contrato com estes campos: nome da operação, versão, identificador do fluxo, chave de idempotência, parâmetros autorizados, estado anterior relevante e identificador do resultado remoto. Idempotência significa que repetir a mesma solicitação lógica não deve aplicar o efeito novamente quando o serviço oferece essa garantia.
Por exemplo, “liberar reserva” precisa receber o identificador da reserva criada por aquele fluxo. Uma operação ampla como “somar unidades ao estoque” pode devolver mercadoria que outra etapa já separou. O nome da ferramenta deve expressar a regra de negócio, evitando uma interface genérica que permita ao modelo improvisar correções.
Classifique as operações como reversíveis, compensáveis, irreversíveis ou desconhecidas. Essa classificação é uma recomendação editorial para organizar o projeto. “Desconhecida” deve bloquear automação de escrita até alguém definir o tratamento. A ausência de documentação sobre cancelamento não equivale a uma autorização para tentar exclusões.
Também defina quem tem autoridade para aprovar o plano. Uma ferramenta disponível não significa que toda sequência possível entre ferramentas esteja autorizada. A distinção entre agente e chatbot ajuda a explicar por que essas regras passam a importar quando o sistema começa a agir.
Persistir estado e resolver resultados incertos
Um processo recuperável precisa sobreviver à queda da aplicação. Nossa recomendação é gravar estados explícitos, como “preparado”, “solicitação enviada”, “efeito confirmado”, “resultado incerto”, “compensação pendente” e “encerrado”. A conversa do modelo pode explicar a decisão, mas não deve ser o registro operacional de quais efeitos aconteceram.
Considere a reserva enviada para um ERP. A conexão cai antes de a resposta chegar. A reserva pode ter sido criada. Repetir com outra chave pode duplicar o efeito; compensar supondo que falhou pode criar uma segunda inconsistência. Consulte o resultado pela chave ou pelo identificador de correlação antes de escolher o próximo passo.
Quando o serviço não permite essa consulta, recomendamos marcar o resultado como incerto e encaminhar a reconciliação. Isso é um estado de negócio válido. Ocultar a incerteza atrás de uma mensagem “tente novamente” deixa a equipe sem saber se precisa repetir, cancelar ou investigar.
Há ainda o intervalo entre atualizar o banco local e publicar uma mensagem. A documentação da AWS sobre transactional outbox explica o padrão de registrar a mudança e a mensagem na mesma transação local, para envio posterior. Ele trata o problema da dupla escrita; não transforma os efeitos externos em uma transação única.
Para o agente, recomendamos devolver estados estruturados em vez de uma frase vaga como “deu erro”. Uma ferramenta pode retornar “resultado incerto, consulta necessária” e impedir novas escritas naquele pedido até a situação ser esclarecida. A aplicação deve impor essa transição, independentemente da insistência do modelo.
Planejar a compensação e testar a recuperação
A ordem de correção depende das dependências entre efeitos e das regras do negócio. A Microsoft observa que compensar não precisa seguir exatamente o caminho inverso e que certas etapas podem ser tratadas em paralelo. A equipe precisa definir essa ordem explicitamente, sem deixá-la surgir de uma resposta improvisada.
Como proposta de procedimento, registre para cada correção: condição de acionamento, pré-condições atuais, ferramenta permitida, autorização necessária, limite de tentativas e verificação de conclusão. Uma reserva pode ser liberada automaticamente enquanto estiver apenas reservada; depois de separação física, o tratamento pode exigir conferência do depósito.
Não restaure uma cópia antiga sobre todo o cadastro. Outro operador pode ter atualizado o telefone do cliente enquanto o fluxo falhava. Recomendamos corrigir apenas o recurso que pertence à operação, verificando versão e estado atual quando a integração oferecer esses controles.
A compensação também pode sofrer timeout ou indisponibilidade. Grave sua tentativa e reconcilie o resultado antes de repetir. A Microsoft recomenda comandos idempotentes e uma recuperação que consiga retomar do ponto em que parou. Quando a automação não resolver, a pendência deve carregar contexto suficiente para intervenção.
Nos testes sugeridos, simule queda depois do efeito remoto e antes da confirmação local, execução duplicada do trabalhador, resposta atrasada, mudança concorrente e falha da própria correção. O critério de sucesso é preservar a regra do negócio e produzir uma pendência rastreável quando necessário, sem anunciar conclusão indevida.
Exemplo: reserva de materiais em uma loja de Campinas
Imagine uma loja de materiais de construção em Campinas que usa um agente para preparar pedidos recebidos por formulário. Este caso é ilustrativo. O fluxo consulta disponibilidade, cria uma reserva e solicita aprovação comercial antes de confirmar a preparação da entrega.
O agente cria a reserva de um conjunto de itens. A aprovação comercial é recusada porque a condição negociada não foi autorizada. O orquestrador registra a recusa e chama a ferramenta de liberação usando o identificador daquela reserva. Depois consulta o status para confirmar que a correção terminou.
Agora considere que a liberação foi enviada, mas a resposta se perdeu. O sistema marca a compensação como incerta. Uma consulta ao ERP verifica se a reserva ainda existe. A ferramenta de retomada reutiliza a mesma identidade lógica da correção quando isso é suportado, evitando que cada tentativa pareça uma nova operação.
Se o depósito já começou a separação, a regra muda. O agente abre uma pendência para o responsável conferir os itens. Não altera o estoque disponível supondo que a mercadoria continua na prateleira. O tratamento respeita o efeito físico do processo, que o histórico de chamadas não consegue desfazer sozinho.
O cliente recebe apenas uma comunicação compatível com o estado confirmado. Se uma confirmação incorreta já foi enviada, será necessária uma correção de mensagem. Para conectar o fluxo ao atendimento desse setor, veja IA para lojas de material de construção. A recomendação é manter a reserva e a promessa comercial como decisões distintas.
Erros comuns
Prometer desfazer qualquer ação. Apagar um registro não faz uma pessoa esquecer um e-mail nem recolhe uma encomenda entregue. Identifique o ponto após o qual o processo exige reparação ou negociação, com aprovação antes da passagem quando apropriado.
Deixar o modelo inventar a ação inversa. “Criei, então posso excluir” ignora dependências e regras de retenção. Nossa recomendação é oferecer ferramentas compensatórias específicas, com validação no servidor e vínculo ao efeito original.
Usar novas chaves a cada tentativa. Isso pode transformar uma repetição técnica em operações de negócio distintas. Defina a identidade da ação lógica no começo e preserve-a nas retomadas, conforme o contrato da integração.
Encerrar o fluxo com correção pendente. Recomendamos separar “operação principal interrompida” de “recuperação concluída”. Mostre à equipe responsável o recurso afetado, o último resultado confirmado e a próxima ação necessária.
Guardar apenas o antes e depois narrado pela IA. Uma boa explicação não comprova que uma ferramenta executou. Use identificadores e respostas dos sistemas envolvidos como evidência, com acesso restrito aos dados necessários.
Refazer o plano inteiro após uma falha. Recomeçar pode duplicar efeitos confirmados. A retomada sugerida parte do estado persistido e reconcilia os pontos incertos antes de permitir qualquer nova etapa.
Perguntas frequentes
Compensação garante que nada ficou diferente?
Não. Ela aplica uma correção definida pelo negócio. Podem permanecer registros, custos, tempo decorrido e mensagens recebidas. Defina o estado final aceitável antes de automatizar a recuperação.
Preciso de uma Saga para todo agente?
Não. Agentes somente leitura podem não ter efeitos para compensar. Operações dentro de uma única transação local podem usar os controles do banco. Considere Saga quando houver várias etapas confirmadas em fronteiras independentes.
Quem decide a correção: agente ou aplicação?
Recomendamos que a aplicação imponha o conjunto de correções e as regras de transição. O agente pode interpretar o caso e propor uma decisão dentro dessas regras, com aprovação humana para exceções relevantes.
Como tratar uma mensagem enviada por engano?
Considere o envio um efeito que pode ser irreversível. Uma mensagem corretiva é outra ação e exige verificar destinatário, conteúdo e autorização. Não declare que apagar uma cópia local cancelou a comunicação externa.
Qual é o primeiro passo para implementar?
Escolha um fluxo pequeno e liste seus efeitos confirmados, estados incertos e ações de correção. Teste a recuperação com falhas simuladas antes de liberar ferramentas de escrita para uso real.
