Execução durável para agentes de IA: o motor vive no código

Um agente de produção não costuma morrer no fim. Mora no meio. A décima etapa de um fluxo de vinte, uma aprovação humana pendente há duas horas, um sistema externo fora do ar, uma sessão de API que expirou no intervalo. A conta do desastre não está na falha em si. Está na pergunta seguinte: refazer tudo do começo, ou retomar do último ponto válido?

A diferença entre refazer e retomar é o que a engenharia chama de execução durável, e ela voltou ao centro do debate com o anúncio do Workflow Development Kit da Vercel: durabilidade como conceito de linguagem, código assíncrono comum que persiste o próprio progresso e retoma depois de crash ou deploy, sem fila e sem máquina de estados em YAML. A posição deste texto vai além do anúncio: para agentes de IA de longa duração, o motor de execução pertence ao código, como propriedade do fluxo, com checkpoint onde o time decide, e não como um produto distribuído alugado ao lado dele.

O argumento não depende do SDK nem do fabricante. Descansa em fontes que nenhum pitch substitui: o paper que descreveu transações de longa duração em 1987, o que formalizou a execução durável em serverless na ASPLOS 2022 e um postmortem público de 2018 em que 43 segundos de partição de rede viraram 24 horas e 11 minutos de serviço degradado. No fim das contas, execução durável é decisão de contabilidade: quem paga as etapas repetidas paga a arquitetura que as repete.

Agentes de longa duração não falham como perguntas de chat

Uma pergunta de chat que falha custa um redigitado. Um fluxo de agente que falha custa as etapas já executadas: tokens cobrados, chamadas feitas, horas de espera por aprovação. Agentes de IA de longa duração carregam esse custo acumulado, e a execução durável é a propriedade que transforma refazer em retomar. Sem ela, cada falha recobra a fatura inteira.

O padrão de falha de um fluxo de horas é de outra natureza. O agente atravessa etapas sequenciais, algumas com efeito externo difícil de desfazer, e para exatamente onde o mundo externo participa: a aprovação do gestor, o retorno do ERP, o webhook do parceiro. Enquanto espera, ele paga. Cada token de contexto reenviado é faturado, e a espera por um humano não é tempo ocioso, é tempo de exposição.

A falha nunca é questão de se, é questão de onde.

Entre duas etapas quaisquer existe uma camada que decide quem chama o quê, com qual permissão e qual rastro, e ela já tem tratamento dedicado na camada de controle do tráfego de ferramentas dos agentes. A camada de execução é outra e é a menos discutida das três: decide o que acontece com a etapa que morreu no meio. A confusão é velha: a mesma palavra cobre as duas camadas, e o comprador sai da sala achando que comprou recuperação de falhas em agentes de IA quando comprou uma fila.

O que é execução durável em um agente de IA

Execução durável é a propriedade de um fluxo que grava checkpoint a cada etapa e retoma do último ponto válido depois de uma falha ou de um reinício. O estado persiste fora da memória do processo, e a retomada executa apenas o que ficou pendente. Refazer vira exceção; retomar vira o comportamento padrão.

Três peças definem o mecanismo. O checkpoint grava, antes do passo seguinte, o resultado da etapa concluída, as variáveis do fluxo e a posição exata dentro da sequência. O runtime reconstrói o estado a partir desse registro, não da memória de um processo vivo. A retomada executa então a etapa pendente, e só ela.

A formalização acadêmica é recente, e o conceito é velho. Sistemas em lote de mainframe dos anos 1960 já gravavam checkpoint e reiniciavam o job do último ponto válido. O paper Durable Functions: Semantics for Stateful Serverless, publicado na ASPLOS 2022, deu ao conceito semântica formal no mundo serverless: o fluxo escreve um log de eventos, o runtime reexecuta esse log de forma determinística para reconstruir o estado, e a retomada sobrevive a deploy, a crash e a mudança de escala.

O detalhe que separa a definição da prática é a ordem entre gravar e agir. Um checkpoint gravado antes do efeito externo abre espaço para um retry que aplica o efeito duas vezes. Um checkpoint gravado depois perde a etapa inteira quando o processo morre entre o efeito e a gravação. Janela de perda e duplicação de efeito: aqui a execução durável deixa de ser recurso pronto e vira desenho.

Onde vive o estado do agente entre as etapas

O estado vive no log de execução do fluxo, não na memória de um processo: o resultado de cada etapa, as decisões tomadas e a posição atual são gravados como checkpoint antes do passo seguinte. Retomar do último ponto válido significa executar só a etapa pendente, sem recobrar as chamadas de modelo já pagas.

A pergunta de quem paga a fatura é mais estreita do que a de quem desenha arquitetura: o que acontece com as chamadas já pagas quando o fluxo morre? Com checkpoint, a resposta é nada. O resultado delas está no log, e a retomada não repete a chamada. Sem checkpoint, a resposta é tudo: o fluxo não sabe o que já rodou e roda de novo. A diferença entre as duas respostas é a fatura de tokens do mês.

O estado traz um segundo problema, o efeito externo. O paper Sagas, de Hector Garcia-Molina e Kenneth Salem, publicado na SIGMOD de 1987, descreveu o problema antes de existir agente: uma transação de longa duração se divide em etapas, e quando uma falha, as concluídas não se desfazem sozinhas, exigem ações compensatórias. Quarenta anos depois, a tradução é direta: a etapa que emitiu um pagamento precisa de mecanismo idempotente, porque um retry aplica o efeito duas vezes, e a ação compensatória é o plano B caro.

O terceiro problema é o estado que diverge. O postmortem do GitHub de 30 de outubro de 2018 é o caso de estudo: 43 segundos de perda de conectividade entre dois data centers viraram 24 horas e 11 minutos de serviço degradado, não porque a partição fosse grave, mas porque dois clusters passaram a conter escritas que o outro não tinha. A reconciliação manual de poucos segundos de escritas seguiu em curso dias depois, e um dos clusters mais movimentados tinha 954 escritas na janela afetada. Ao retomar a fila, cerca de 200 mil payloads de webhook haviam expirado e foram descartados. Estado mal administrado cobra juros: a falha original durou 43 segundos, as consequências dela duraram dias.

Motor de orquestração dedicado ou execução no código: onde está o custo real

Um motor de orquestração dedicado entrega fila, agendamento e visibilidade centralizada, e cobra por isso um sistema distribuído inteiro para operar. A execução durável no código entrega checkpoint e retomada como propriedade do fluxo, com a granularidade que o time escolher, e cobra disciplina de escrita. A diferença aparece na primeira falha, na fatura e na adaptação do fluxo.

A palavra herdada confunde: orquestração de agentes de IA cobre, no mesmo fôlego, a fila que distribui trabalho e a lógica que recupera falha, e são problemas diferentes. As três diferenças de custo moram em lugares distintos. A primeira é a granularidade da retomada. Quando um fluxo orquestrado por um motor dedicado falha no meio de uma etapa, a retomada acontece na granularidade que o motor define: nos casos em que ele não carrega o estado da etapa no ponto da falha, o trecho volta a rodar inteiro, chamadas já pagas incluídas. A execução no código coloca o checkpoint onde o desenvolvedor decide, e a retomada refaz só o pendente.

A segunda é o custo das etapas ociosas. Um fluxo de agente passa a maior parte da vida esperando: aprovação humana, retorno de sistema externo, janela de processamento. O motor dedicado é infraestrutura que roda, e custa, mesmo com todo fluxo sob a sua guarda em espera. Runtimes de execução durável projetados para suspender o fluxo entre etapas não gastam recurso com a espera, e a infraestrutura que sobra é a que a empresa já operava. Em escala, vira linha no orçamento.

A terceira é a curva de adoção. Um fluxo escrito como código comum entra no repositório, no code review, nos testes e no CI que a empresa já opera. Um fluxo escrito na semântica de um motor dedicado carrega um segundo sistema distribuído para operar, com versão própria, topologia própria e incidentes próprios. O postmortem de 2018 mostra o modo de falha característico dessa transferência: o mecanismo de failover agiu exatamente conforme configurado, e foi a aplicação que não suportou a topologia resultante. Ferramenta dedicada atrai a semântica para dentro dela; código deixa a semântica com quem a escreve.

Resta a linha da observabilidade, a mais mal lida da tabela. O painel de um motor dedicado mostra a fila: quantas execuções, em qual estado, há quanto tempo esperando. Mostra que o fluxo parou. Não mostra se a decisão da etapa corrente foi boa, e é isso que a avaliação de agentes cobre: o que medir além da resposta final. Fila visível não é comportamento auditado.

Quando um motor dedicado ainda ganha

Em cargas de milhares de fluxos paralelos com garantias contratuais de nível de serviço, um motor de orquestração dedicado entrega o que código puro não dá sozinho: visibilidade centralizada de frota, agendamento comprovado em produção e um produto com rastro de auditoria pronto para o compliance. Nessa configuração, o custo de operar o motor se paga.

O lado contrário tem versão forte. Um time de plataforma que opera centenas ou milhares de fluxos em produção precisa ver a frota inteira num só lugar, responder a incidente com procedimento conhecido e mostrar a um auditor uma superfície de controle reconhecível. Um motor dedicado maduro vende exatamente isso, e a empresa que tem esse time e essa carga compra um produto em vez de construir plataforma interna. É a compra certa para quem tem problema de frota.

O argumento cai para a maioria das cargas de agentes B2B, e cai por aritmética. Fluxo de agente em empresa típica é contado, não frota: uma conciliação, uma triagem de contratos, uma aprovação de compras. Muda toda semana, porque a regra de negócio, o prompt e o conector mudam. O time por trás raramente é uma plataforma dedicada. Para esse perfil, a frota é pequena demais para justificar o produto e muda rápido demais para a rigidez da semântica alheia. O critério prático: frota de milhares com time de plataforma compra motor; frota de poucos com time enxuto escreve o checkpoint no código.

O que essa decisão muda para quem compra agentes B2B

Execução durável deixa de ser detalhe de engenharia e entra no contrato: onde vive o checkpoint, o que acontece com a etapa no meio, quem paga as chamadas repetidas e como auditar a retomada. Um agente sem resposta para essas quatro perguntas não está pronto para produção, por melhor que seja o modelo por baixo.

As quatro perguntas, com o que cada resposta compromete:

1. Onde vive o checkpoint? Quem é o dono do estado: o fluxo, no armazenamento que a empresa opera, ou a estrutura interna do produto. A resposta decide quem mexe na granularidade da retomada.
2. O que acontece com a etapa no meio? Qual é a unidade de retomada: a etapa, o trecho ou o fluxo inteiro. A resposta aparece na fatura da primeira falha.
3. Quem paga as chamadas repetidas? Se a retomada refaz chamadas de modelo já pagas, o custo da falha duplica, e ninguém orçou essa linha.
4. Como auditar a retomada? O rastro pós-falha precisa mostrar o que rodou de novo, o que foi compensado e o que chegou duas vezes ao cliente.

Na pilha da Nexforce Agents, a decisão tem endereço nas duas pontas. O Nexforce Code é o runtime do desenvolvedor: agentes e subagentes definidos por projeto, com skills, regras de projeto e suporte a MCP para ferramentas e dados externos, rodando no terminal e na IDE e também em execuções headless para automação e CI, em macOS, Windows e Linux. O Nexforce Work é o espaço de trabalho do time de negócio: desktop onde times não técnicos rodam agentes nos próprios arquivos, ferramentas e conectores, com orquestração multi-workspace, camada de aprovações e permissões, templates de workflow reutilizáveis, execução sandboxada e execuções agendadas para rotinas recorrentes.

As aprovações do Work são o ponto exato onde um fluxo de longa duração pausa. As execuções agendadas são o lado recorrente. Os conectores MCP são os sistemas externos que falham no meio. E onde vive o checkpoint segue sendo desenho de fluxo: quem escreve o agente decide a granularidade da retomada.

Por baixo, a camada de modelo é o Nexforce Router: centenas de modelos atrás de uma única API, com failover automático entre provedores quando um deles sai do ar, porque a retomada de um fluxo precisa de modelo disponível para voltar.

A decisão de arquitetura também entra no caso de negócio: o ROI de agentes de IA se mede antes de escalar o piloto, e o custo de refazer é uma das linhas que quase ninguém inclui na planilha.

FAQ

Como um agente de IA se recupera de uma falha no meio de um fluxo longo?

O agente lê o último checkpoint válido e executa apenas a etapa pendente. O checkpoint carrega o resultado das etapas concluídas e a posição no fluxo, então a retomada não repete chamadas já pagas. Para efeitos externos sensíveis, como um pagamento emitido, a etapa precisa ser idempotente, porque um retry aplica o efeito duas vezes.

Como validar que a execução durável do meu agente funciona antes de escalar?

A validação é falhar de propósito: a falha é injetada entre duas etapas, a retomada é conferida no checkpoint correto, nenhuma chamada repetida aparece na fatura e o rastro mostra o que rodou de novo. O postmortem do GitHub de 2018 terminou em iniciativa formal de fault injection. Execução durável não demonstrada é execução durável suposta.

Um agente que roda em minutos também precisa de execução durável?

Depende do custo de refazer. Um fluxo de uma única chamada refaz barato, e checkpoint ali é burocracia sem retorno. Fluxo com aprovação humana, sistema externo no meio ou fatura por token paga a retomada desde a primeira falha. O critério é o custo do retrabalho, não a duração cronológica do fluxo.

Execução durável substitui a camada de controle e a de avaliação?

Não. A recuperação de falhas em agentes de IA é uma das três camadas da operação: o controle decide quem chama o quê e com qual permissão, a avaliação decide se o comportamento é bom, e a execução durável decide o que acontece quando o fluxo morre no meio. Agente que retoma perfeitamente e decide mal segue decidindo mal.

A execução durável exige um motor dedicado?

Não é requisito. O checkpoint pode ser gravado pela própria rotina do fluxo, no armazenamento que a empresa já opera, com a granularidade que o time escolher. Um motor dedicado agrega fila, agendamento e visibilidade centralizada, e cobra um sistema distribuído inteiro pela conveniência. A escolha é de custo de operação, não de possibilidade técnica.

Referências e Leitura Complementar

Quatro fontes primárias sustentam o argumento.

• Built-in durability: Introducing Workflow Development Kit, anúncio da Vercel: a ocasião do debate sobre onde vive a execução durável.
• Durable Functions: Semantics for Stateful Serverless, ASPLOS 2022: a formalização da semântica de execução durável em serverless.
• Sagas, Hector Garcia-Molina e Kenneth Salem, SIGMOD 1987: transações de longa duração, etapas e ações compensatórias.
• October 21 post-incident analysis, GitHub, 30 de outubro de 2018: o postmortem público em que 43 segundos de partição viraram 24 horas e 11 minutos de serviço degradado e reconciliação manual de estado.

A decisão que fica

A próxima conversa sobre agentes, na mesa de arquitetura ou na de compra, muda de pergunta. Em vez de "qual motor vocês usam", a pergunta que decide é "mostre o checkpoint": onde ele vive, quando é gravado e o que acontece com a etapa seguinte à falha. Refazer é a resposta cara. Disfarçada de simplicidade, chega com a primeira queda de sistema externo no meio de um fluxo de vinte etapas. A execução durável escrita no próprio fluxo é a versão em que o agente retoma o turno da madrugada sem ninguém de plantão. E a retomada tem endereço: o código é o único lugar onde a granularidade da retomada pertence a quem paga a conta.