Agente enterprise deve sobreviver a um restart sem pagar a fatura duas vezes. SDK Go durável da AWS em GA

Um agente de contas a pagar lê uma fatura, faz a correspondência com um pedido de compra, pede a um gerente para aprovar uma exceção e, uma vez aprovada, dispara o pagamento. O gerente aprova na segunda-feira. Na noite de segunda-feira, o processo que hospeda o agente é reiniciado. Quando ele volta, o que o agente lembra? Se a resposta for “nada”, ele começa de novo a partir da fatura. Se a etapa de pagamento já tiver sido executada, o fornecedor recebe duas vezes.

Essa falha não tem nada a ver com o quão inteligente o modelo é. É uma propriedade do ambiente de execução, e é a razão pela qual o anúncio da AWS em 15 de outubro importa para qualquer um que coloque agentes em processos de negócio: o SDK de execução durável para Go do Lambda está agora em disponibilidade geral (GA).

O que a execução durável oferece

Funções duráveis permitem que um workflow mantenha seu progresso através de interrupções. O SDK Go, agora em disponibilidade geral (GA), oferece:

• Etapas com checkpoints automáticos, para que o trabalho concluído seja registrado e não repetido após um restart;
• Callbacks para workflows human-in-the-loop e agent-in-the-loop, para que um processo possa esperar por uma aprovação sem manter computação;
• Invocação durável para encadeamento confiável de funções;
• Esperas que suspendem a execução por até um ano enquanto aguardam um evento externo.

A AWS também fornece um pacote durabletest para testar workflows completos localmente, sem acesso à rede ou credenciais, e um analisador durablelint que sinaliza código que pode se comportar mal quando um workflow é retomado. A disponibilidade regional e os preços seguem as próprias páginas do Lambda. Este GA se aplica especificamente ao SDK Go, e uma espera suspensa de até um ano não significa computação em execução por um ano.

Por que agentes precisam disso mais do que workflows comuns

Motores de workflow clássicos oferecem durabilidade há anos. Agentes tornam isso mais urgente por três razões:

1. Eles rodam por muito tempo. Tarefas de agente abrangem de minutos a dias, o que é tempo suficiente para deploys, reinicializações e timeouts acontecerem no meio. Escrevemos sobre testar o que acontece na terceira hora de uma execução longa de agente; a durabilidade decide se a terceira hora pode ser retomada.
2. Eles esperam por pessoas. Portões de aprovação são onde agentes enterprise passam a maior parte do tempo de relógio. Um design que mantém um processo vivo enquanto um gerente está de férias é frágil e caro. Um callback que retoma o workflow quando a aprovação chega não é nenhum dos dois.
3. Suas etapas não são determinísticas. Reproduzir uma chamada de modelo após um restart pode produzir uma resposta diferente da que foi aprovada. A execução durável faz checkpoint do resultado da etapa, então o workflow continua a partir do que foi realmente decidido, não de um novo palpite.

O que o SDK não faz por você

Durabilidade é necessária e não suficiente. Três deveres de design permanecem com o time:

• Ações idempotentes. Um checkpoint registra que uma etapa terminou. Se o processo morre depois que a API de pagamento aceitou a requisição mas antes que o checkpoint fosse salvo, a etapa pode rodar de novo. Use chaves de idempotência em toda chamada consequente, para que uma repetição seja reconhecida e ignorada pelo sistema de registro.
• Autorização no momento da retomada. Uma aprovação concedida na segunda-feira pode não ser válida na sexta-feira: o aprovador pode ter saído, o valor pode ter mudado, as permissões do agente podem ter sido revogadas. Verifique novamente a autoridade quando uma espera longa termina. Este é o problema da autorização temporal em outra forma.
• Compensação. Algumas etapas não podem ser desfeitas, apenas revertidas por outra ação. Defina a etapa compensatória para cada ação consequente antes que o workflow seja lançado, o que também é o que transforma um freio de emergência em um plano de incidente.

Onde se encaixa em uma arquitetura de agente

O padrão que vale a pena adotar é uma divisão: o modelo decide dentro de uma etapa, e o workflow durável decide o que acontece entre as etapas. Chamadas de modelo são envolvidas como etapas com checkpoint; aprovações são callbacks; ações consequentes são chamadas idempotentes ao sistema de registro; e o workflow, não o modelo, mantém o estado do processo.

O SDK da AWS é uma implementação, e não é uma plataforma geral de agentes. Temporal, Step Functions e outros motores de workflow oferecem garantias similares. A escolha do motor importa menos do que a decisão de ter um. Um agente que mantém seu progresso na janela de contexto do modelo vai, mais cedo ou mais tarde, pagar a fatura duas vezes.