Temporal ou Inngest: recuperar o agente não garante efeito único

Temporal e Inngest permitem retomar o trabalho de um agente de IA após uma falha, mas a recuperação não garante que uma cobrança ou mensagem enviada a outro serviço tenha efeito único. No Temporal, a documentação da plataforma descreve a recuperação do workflow a partir de seu histórico de eventos. Esse histórico preserva o progresso registrado pela plataforma, não o resultado de toda ação externa.

No Inngest, os resultados de etapas concluídas são salvos e reutilizados quando a função é retomada; a execução durável do Inngest também permite esperar um evento sem manter um worker ocupado. A escolha, portanto, passa pelo modelo de recuperação, pela forma de hospedar o código e pela proteção das operações que o agente executa fora da plataforma.

O que cada plataforma recupera

No Temporal, o worker reproduz o histórico de eventos para reconstruir o estado do workflow. Uma Activity já concluída e registrada devolve seu resultado durante essa reprodução, sem executar novamente a operação. A lógica do workflow precisa continuar compatível com as decisões registradas: uma alteração de código que produza outra sequência de comandos pode impedir a retomada de uma execução aberta.

Chamadas a APIs, consultas externas e invocações de modelos que dependem do mundo fora do workflow pertencem às Activities. Essa separação permite que o histórico reconstrua as decisões do fluxo enquanto cada Activity executa trabalho com seus próprios erros e tentativas. Para um agente, a fronteira entre decidir qual ferramenta usar e efetivamente chamar a ferramenta determina o que pode ser reproduzido com segurança.

No Inngest, a fronteira explícita é o passo, como uma chamada a step.run(). Quando a função volta a rodar, o handler percorre novamente seu código, mas um passo concluído devolve o resultado salvo em vez de repetir seu callback. Código colocado fora dos passos pode executar outra vez. Separar a obtenção de contexto, a chamada ao modelo e a ferramenta em passos distintos permite recuperar os resultados já registrados e identificar qual operação ficou pendente.

Implantações também afetam execuções longas. O Temporal exige que a lógica reproduzida permaneça compatível com o histórico existente. No Inngest, os identificadores dos passos associam resultados salvos ao código em execução; mudar um identificador pode fazer uma operação antiga parecer trabalho novo. Nos dois casos, alterações no fluxo merecem atenção quando ainda há agentes aguardando resposta.

A falha entre a chamada externa e o registro

Considere um exemplo hipotético: o agente solicita a cobrança de um pedido, o provedor aceita a operação e o processo cai antes de registrar a resposta. Na retomada, a plataforma vê uma etapa sem conclusão registrada e pode tentar a cobrança outra vez. O estado durável do agente informa o que o orquestrador conseguiu salvar; a confirmação do pagamento pertence ao provedor.

No Temporal, uma Activity pendente pode ser tentada novamente após uma falha. A orientação para Activities recomenda idempotência para que tentativas repetidas não produzam efeitos duplicados. A proteção oferecida pelo replay a uma Activity cuja conclusão já está no histórico é diferente da proteção necessária enquanto uma tentativa ainda tem resultado incerto.

No Inngest, a chamada externa também pode terminar antes de o resultado do passo ser salvo. As boas práticas de execução durável recomendam uma chave de idempotência, ou outro meio de detectar sucesso anterior, para pagamentos, mensagens e gravações. A chave deve identificar a operação de negócio e permanecer igual nas tentativas; uma chave criada a cada nova tentativa permitiria repetir o efeito.

Essa lacuna vale mesmo quando a chamada está corretamente encapsulada em uma Activity ou em um passo. Uma resposta perdida deixa o orquestrador sem saber se o serviço externo concluiu o trabalho. Se esse serviço não aceitar uma chave estável nem permitir consultar a operação pelo mesmo identificador, a aplicação precisará tratar o resultado como incerto em vez de presumir sucesso ou reenviar a ação sem critério.

Esperas e observabilidade

Um agente pode precisar aguardar uma aprovação humana antes de agir. No Temporal, uma mensagem dirigida ao workflow pode alterar seu estado e entrar no histórico usado na retomada. No Inngest, uma espera por evento suspende a função até chegar uma ocorrência correspondente, sem manter a execução ativa durante a pausa. Em ambos, a aplicação precisa relacionar a resposta ao pedido correto e decidir como lidar com uma espera que expira.

Os registros ajudam a investigar falhas em pontos diferentes. O histórico do Temporal permite acompanhar os eventos e as operações registrados pelo workflow; os traces do Inngest mostram passos, esperas e tentativas. Para uma cobrança de resultado incerto, esses registros localizam a tentativa do agente, mas a confirmação do efeito exige consultar também o sistema de pagamentos. Um identificador de negócio compartilhado entre o fluxo e o serviço externo facilita essa correlação.

Quem hospeda e mantém a execução

O Temporal separa o serviço que conserva as execuções dos workers que rodam o código da aplicação. A equipe opera seus workers e pode usar o Temporal Cloud ou hospedar o serviço por conta própria. Na instalação própria, persistência, atualizações e monitoramento do orquestrador passam a fazer parte do trabalho operacional da equipe.

Com o Inngest, o código das funções permanece na infraestrutura da aplicação, enquanto a plataforma coordena execuções e esperas. Existe uma opção de instalação própria para o servidor do Inngest; a documentação classifica o modo de servidor único como beta e recomenda conferir versão e suporte a recursos antes de uma implantação em produção. A comparação operacional precisa incluir onde rodam as funções, quem mantém o serviço de coordenação e quais limites o ambiente de hospedagem impõe a cada chamada.

Checklist de idempotência para ações do agente

A proteção deve seguir a operação de negócio, e não a tentativa de execução. Um mesmo pedido pode ser processado após a queda de um worker, a retomada de uma espera ou a chegada repetida do evento inicial. Deduplicar esse evento reduz inícios repetidos, mas não resolve a chamada externa que terminou sem ter seu resultado registrado.

Pagamentos: associe a cobrança a uma chave estável derivada do pedido e da operação pretendida. Se a resposta se perder, consulte o provedor por essa referência antes de solicitar uma cobrança nova.
Mensagens: identifique cada envio pretendido pelo destinatário e pelo evento de negócio. Quando o serviço de entrega não oferece idempotência, registre o envio e trate separadamente o caso em que não é possível saber se a mensagem chegou.
Gravações externas: use um identificador estável e, quando disponível, uma restrição de unicidade ou uma atualização que atinja o mesmo registro em tentativas repetidas. A regra deve distinguir uma repetição técnica de uma alteração legítima.
Eventos de entrada: relacione o identificador do evento ao trabalho iniciado. Isso evita confundir a prevenção de duas execuções para o mesmo pedido com a segurança de uma operação repetida dentro de uma única execução.

Temporal se encaixa em fluxos modelados como decisões de workflow e Activities, com o histórico de eventos como base da recuperação. Inngest oferece um modelo centrado em passos salvos e esperas por eventos para funções da aplicação. A escolha entre eles muda como o agente é retomado e operado; a prevenção de uma segunda cobrança, mensagem ou gravação continua dependendo da fronteira com o serviço que recebe a ação.