Como executar agentes de IA de longa duração sem recomeço

O agente de IA de longa duração não falha no primeiro passo. Falha no passo 40, quando já abriu o ticket no sistema de atendimento, avisou o cliente por e-mail e lançou o provisionamento no ERP. O processo inteiro já aconteceu. Aí o provedor de modelo cai, o run morre, e alguém no time de operações digita a frase mais cara da automação corporativa: roda de novo do começo.

O contrato de operação que elimina essa frase tem cinco itens: checkpoint por etapa, classificação de erro entre retomável e fatal, idempotência dos efeitos externos, parada por aprovação humana e versionamento de execuções em andamento. Escreve-se no design do agente, verifica-se no piloto, e entrega um resultado mensurável: a falha que retoma em vez de recomeçar.

A indústria acabou de admitir que a durabilidade é decisão de arquitetura. Em 27 de agosto de 2026, a Vercel publicou The best workflow engine is a programming language, de Pranay Prakash, o argumento de que a execução durável pertence ao próprio código. A decisão ganhou manifesto. O que falta é a camada seguinte: o contrato que faz a execução durável sobreviver ao terceiro mês, quando o run estaciona numa aprovação de quatro dias e o código já subiu três versões.

O que é um agente de IA de longa duração?

Agente de IA de longa duração é o que executa um processo que atravessa horas, dias ou semanas: onboarding de cliente, aprovação de procurement, cobrança recorrente, disputa de pagamento. Não é uma conversa longa. É um processo com estado, que mexe em sistemas externos e precisa sobreviver a falhas parciais sem perder o que já fez.

Um chatbot erra e repete a resposta. Um agente de longa duração erra e o processo fica pela metade: o cliente avisado, o ticket aberto, o provisionamento lançado, o pagamento ainda pendente. A arquitetura de pergunta e resposta vive de requisições de segundos; o run de um agente de IA em produção vive mais que a conexão e, quando o deploy chega antes do fim, mais que a versão do código que o iniciou.

O contrato de operação tem cinco itens, um por passo deste guia:

1. Checkpoint por etapa. O estado que cada passo compromete antes do próximo: entradas, saídas e decisão. A retomada parte do último checkpoint, nunca do zero.
2. Classificação de erro. Cada falha ganha destino escrito antes de acontecer: retomável volta com backoff dentro de um orçamento; fatal encerra com estado consistente.
3. Idempotência dos efeitos externos. Pagamento, e-mail e ticket já podem ter saído quando a falha chega; nenhum deles repete na volta.
4. Parada por aprovação humana. O run estaciona por minutos ou semanas e continua vivo, retomando pelo mesmo checkpoint quando a decisão chega, sem perder o comprometido.
5. Versionamento de execuções em andamento. O código muda; o run em voo termina na versão que o iniciou.

Sem os cinco, cada falha cobra o processo inteiro.

Com eles, a falha custa um desvio.

O mapa da adoção está no guia de agentes B2B. A fatia que quase nenhum piloto testa é esta: o que acontece quando o run quebra no meio.

O que precisa estar decidido antes do passo 1?

Antes do primeiro checkpoint, quatro decisões precisam existir: o inventário de efeitos externos do processo, o estado mínimo que cada etapa carrega, quem aprova o quê e onde o estado vive. Sem esse mapa, o checkpoint registra o que não interessa e ignora exatamente o que a retomada precisaria.

Primeira decisão, o inventário de efeitos externos: tudo que o processo faz fora da própria máquina, chamada de API, pagamento, e-mail, ticket, provisionamento. Cada linha vira candidato a idempotência no Passo 3 e mostra onde a falha dói.

Segunda decisão, o estado mínimo por etapa: o que o passo seguinte precisa saber para começar. Guardar mais cria log enorme e problema de versionamento; guardar menos quebra a retomada.

Terceira decisão, quem aprova o quê: a matriz de permissões do processo, definida antes do design, nunca durante o incidente. Quarta, onde o estado vive.

A decisão de onde a execução durável vive, motor dedicado ou execução escrita no próprio código, já tem dona neste blog: o post Execução durável para agentes de IA: o motor vive no código cobre o debate inteiro. Este guia não reargumenta. Assume a decisão tomada e constrói a camada que ela não entrega sozinha: a operação que transforma durabilidade prometida em durabilidade observada.

Passo 1: defina o checkpoint de cada etapa

O checkpoint é o estado que cada etapa compromete antes de chamar o passo seguinte: entradas recebidas, saídas produzidas, decisão tomada. Definido por etapa, ele transforma falha em retomada. O run volta do último checkpoint, não do zero, e o que já foi feito continua feito.

A regra de commit é simples e não negociável: o checkpoint grava antes do efeito externo, e o resultado do efeito grava assim que volta. Entre os dois, o run está em voo, e é esse intervalo que os dois passos seguintes protegem.

O estado comprometido carrega, por etapa, as entradas recebidas, as saídas produzidas e a decisão tomada, incluindo o dado que o time de negócio audita seis meses depois. Estado mínimo não é estado pobre: é o que a retomada consome, não o que o log coleciona.

Pense no checkpoint como o autosave de um editor de texto. Ninguém escreve 40 páginas sem autosave. A diferença: aqui o autosave não guarda rascunho, guarda compromisso, o registro do que o agente já prometeu ao resto da empresa.

Esse mesmo registro por etapa é a matéria-prima para medir as etapas intermediárias quando o agente entra em produção: o dado que serve à retomada serve à avaliação.

Passo 2: classifique cada erro entre retomável e fatal

Cada falha de um run precisa de destino escrito antes de acontecer: erro retomável volta com backoff dentro de um orçamento de tentativas, erro fatal encerra com estado consistente e sinalização. Transiente que esgota o orçamento é reclassificado como fatal. Nenhum run fica em loop sem teto: todo run termina em retomada, conclusão ou encerramento sinalizado.

Taxonomia antes de código. Erro transiente é o que a repetição resolve: timeout de rede, limite de taxa do provedor, indisponibilidade momentânea. Erro fatal é o que a repetição agrava: entrada inválida do sistema de origem, regra de negócio violada, dado inconsistente que nenhuma tentativa conserta.

O orçamento de retry é a peça que o desenho apressado pula. Backoff exponencial sem limite não é política de erro, é esperança com cronômetro. O orçamento declara quantas tentativas e quanto custo o transiente ganha; esgotado o orçamento, o erro vira fatal e o run encerra com estado consistente e sinalização. Erro não sai do sistema por silêncio.

O contrato fica auditável quando cada classe ganha uma linha:

A classificação mora no código do agente, uma decisão por tipo de exceção. Erro novo em produção entra na tabela antes de entrar no tratamento. Classe não declarada é classe decidida pelo acaso.

Passo 3: torne cada efeito externo idempotente

Efeito externo idempotente é o que produz o mesmo resultado executado uma vez ou duas: o pagamento único, o e-mail único, o ticket único. A chave de idempotência deriva de forma determinística do par run mais etapa e nunca se regenera por tentativa, e o agente consulta o efeito anterior no sistema externo antes de regravar.

O buraco fica entre duas operações: a chamada externa sai, a rede cai, o checkpoint não chegou a gravar. Do lado de lá, o pagamento aconteceu. Do lado de cá, o estado diz que nada aconteceu. A retomada reexecuta a etapa, e o cliente recebe a segunda cobrança da mesma compra.

A chave de idempotência fecha o buraco, e aqui idempotência em agentes de IA deixa de ser jargão de pagamentos. Ela deriva do par run mais etapa, de forma determinística: mesmo run, mesma etapa, mesma chave, em toda tentativa. Chave regenerada por tentativa derrota o mecanismo, porque cada tentativa parece um efeito novo para o sistema externo. Com a chave estável, a repetição vira pergunta: o efeito com esta chave já existe? Existe, o agente consome o resultado gravado e segue. Não existe, executa uma vez e registra.

A conferência do efeito externo antes de regravar complementa a chave, não a substitui. A chave decide a identidade do efeito; a conferência cobre o sistema externo sem deduplicação nativa. Cobrança duplicada e estornada é prejuízo operacional. Cobrança duplicada e não detectada é prejuízo contábil, do tipo que aparece no fechamento de mês com sobrenome de ninguém.

Passo 4: projete a parada por aprovação humana

A parada por aprovação humana é um estado do run, não uma exceção: o agente de IA de longa duração estaciona por minutos ou semanas, o processo continua vivo e retoma pelo mesmo checkpoint quando a decisão chega. O design define quem aprova o quê, prazo de expiração e rota de escalação, com trilha de auditoria de cada decisão.

O run estaciona. Isso é o projeto funcionando, não um travamento: processos B2B reais esperam aprovação de crédito, validação jurídica, confirmação do cliente. A diferença entre parada projetada e run perdido está em três decisões: como os dados entram e saem de um run em execução, como a retomada acontece e o que acontece quando a decisão não chega.

Os dados passam pelo mecanismo de retomada que a plataforma expõe, webhook ou hook. O contrato do callback não muda: a decisão chega assinada, com identidade de quem aprovou, timestamp e o payload que a etapa seguinte consome. Essa trilha é a auditoria do processo, desenhada junto com a permissão, não depois. A camada de aprovações e rastreio das ações do agente detalha quem autoriza o quê e como cada ação fica registrada.

O prazo existe porque aprovação sem expiração é processo em limbo. O design declara quanto tempo a parada aguarda e para onde escala quando o prazo vence: outro aprovador, outro canal, um run de lembrete. É a correção da falha clássica de aprovação humana em agentes de IA, a aprovação estacionada sem caminho de volta.

Passo 5: versionize sem quebrar execuções em andamento

Mudar o código de um agente com execuções em andamento quebra a retomada quando o código novo reinterpreta o estado gravado pelo antigo. O run em voo precisa terminar na versão que a iniciou. Cada run fica fixado à versão que o criou, e a versão nova vale para os runs que começarem depois.

O mecanismo por trás é o replay determinístico: a retomada reconstrói o caminho percorrido a partir do estado comprometido, e a reconstrução só faz sentido com o código que gravou. Versão A grava um checkpoint com três campos. Versão B espera cinco. O replay não quebra com estrondo; deriva, e decide com campo que não existia. Estado corrompido em silêncio é o pior estado que um sistema produz.

A indústria convergiu para a mesma resposta, com nomes diferentes. O conceito é genérico. Fixar cada execução na versão que a iniciou: o run carrega a marcação da versão, a versão antiga continua executável enquanto houver run nela, e a migração de runs estacionados é decisão explícita, com teste de replay entre versões. O deploy afeta apenas os runs que ainda vão nascer.

Como testar se o agente retoma de verdade?

O teste que prova retomada é a injeção de falha: matar o run no meio de uma etapa, confirmar que ele volta do último checkpoint, conferir que nenhum efeito externo duplicou e que a saída final é a esperada. O teste inclui verificar que a chave de idempotência é a mesma antes e depois da falha injetada.

Confiabilidade de agentes de IA não se declara, se demonstra. A suíte abaixo roda no ambiente de teste antes do piloto e volta a rodar depois de cada mudança de versão. O run morre de propósito:

1. Mate o run no meio de uma etapa que já chamou um sistema externo, com o checkpoint ainda não gravado.
2. Confirme a retomada do último checkpoint comprometido, sem reexecutar etapas anteriores.
3. Verifique zero efeito duplicado: um pagamento, um e-mail, um ticket, cada efeito existindo exatamente uma vez.
4. Confira a estabilidade da chave de idempotência: a chave gerada antes da falha injetada é a mesma depois dela.
5. Injete um erro fatal e confirme encerramento com estado consistente e sinalização correta.
6. Injete uma parada por aprovação, retome pelo callback e valide a saída final esperada.

Um agente que passa nos seis testes retoma de verdade. Um agente que falha no item 3 não tem contrato de operação; tem uma função longa com esperança embutida. Recuperação de falha em agentes de IA é essa suíte rodando a cada versão, não parágrafo na documentação.

Quais falhas ainda quebram agentes de longa duração?

Quatro modos de falha sobrevivem quando o contrato é mal aplicado: efeito executado duas vezes após a retomada, aprovação estacionada sem caminho de volta, atualização de código que quebra o run em voo e deriva silenciosa de estado quando o sistema externo muda entre a falha e a retomada. Cada modo tem correção conhecida.

Efeito duplicado após a retomada. A causa clássica é a chave regenerada por tentativa, o anti-padrão do Passo 3, ou um checkpoint gravado depois do efeito sem chave nenhuma. Correção: chave determinística do par run mais etapa, mais a conferência do efeito externo antes de regravar.

Aprovação estacionada sem caminho de volta. O run parou, o aprovador mudou de time, e ninguém sabe que a espera virou abandono. Prazo de expiração e rota de escalação, definidos no Passo 4, transformam espera indefinida em fila com dono.

Atualização de código que quebra o run em voo. O deploy sobe, o checkpoint da versão anterior chega para a versão nova, e o replay decide com campo que não existia. Correção do Passo 5: fixar o run na versão que o iniciou, com teste de replay entre versões.

Deriva silenciosa de estado. O sistema externo mudou entre a falha e a retomada. O estoque acabou. A política de crédito mudou. O cliente cancelou o pedido. O checkpoint descreve um mundo que não existe mais, então a correção é revalidar as pré-condições da etapa na retomada e tratar a divergência como erro classificável, não como exceção solta.

O que exigir de uma plataforma de agentes B2B?

O contrato de operação vira checklist de compra: pergunte como a plataforma guarda o estado por etapa, como classifica e reclassifica erros, como sustenta efeitos idempotentes, como mantém um run vivo durante uma aprovação de dias e como protege runs em voo durante uma atualização. A resposta que conta é a que se verifica no piloto, não a do folheto.

Na prática, o comprador B2B tem dois ambientes de implementação dentro do Nexforce Agents. O Nexforce Work é o workspace de desktop para o time de negócio: orquestração multi-workspace, camada de aprovações e permissões, execução em sandbox, runs agendados, templates de workflow reutilizáveis e conectores MCP. O Nexforce Code é o runtime para o time de engenharia: agentes no terminal e na IDE, runs headless para automação e CI, agentes e subagentes por projeto, skills e suporte a MCP, em macOS, Windows e Linux.

Por baixo dos dois, o Nexforce Router opera a camada de modelos: roteamento, failover e governança de custo de cada chamada. A plataforma cuida do acesso ao modelo; o contrato de operação continua sendo design do processo, porque aprovação com prazo, chave de idempotência e fixação de versão pertencem ao desenho do agente e se verificam com injeção de falha.

O resto é folclore de vendas.

FAQ: agentes de IA de longa duração

As perguntas que aparecem na hora de desenhar o contrato, respondidas sem rodeio:

O que é um agente de IA de longa duração?

É o agente que executa um processo com estado que atravessa horas, dias ou semanas, tocando sistemas externos em cada etapa: onboarding, aprovações, cobrança, disputas. Diferente de uma conversa, o run precisa sobreviver a falhas parciais e a paradas de aprovação sem recomeçar o processo inteiro.

Como provar que o agente retoma em vez de recomeçar após uma falha?

Com teste de injeção de falha: mate o run no meio de uma etapa, confirme a retomada do último checkpoint, verifique que a chave de idempotência é a mesma antes e depois da falha e confira que nenhum efeito externo duplicou. Prova é resultado observado, não promessa.

Agentes de IA podem esperar uma aprovação humana por dias?

Podem. A espera é um estado projetado do run, não um travamento: o processo continua vivo, com checkpoint, trilha de auditoria e retomada pelo callback quando a decisão chega. Prazo de expiração e rota de escalação evitam que a espera vire abandono silencioso.

O que é idempotência e por que agentes de IA precisam dela?

Idempotência é a propriedade do efeito que produz o mesmo resultado executado uma vez ou duas. Agentes de IA precisam dela porque a retomada após falha nunca sabe se o pagamento, o e-mail ou o ticket já saíram; a chave determinística do par run mais etapa impede o efeito duplicado.

Como atualizar o código de um agente com execuções em andamento?

Fixando cada execução na versão que a iniciou: o run em voo termina na versão antiga, com replay testado entre versões, e a versão nova vale apenas para os runs que começarem depois. Sem isso, o código novo reinterpreta estado gravado pelo antigo e corrompe a decisão.

Referências e Leitura Complementar

• Pranay Prakash, "The best workflow engine is a programming language", Vercel Blog, 27 de agosto de 2026. Post original.
• Execução durável para agentes de IA: o motor vive no código
• Permissões e acesso de agentes de IA: defina e rastreie
• Avaliação de agentes: o que medir além da resposta final
• ROI de agentes de IA: como medir antes de escalar o piloto
• Agentes de IA no B2B: o guia completo para 2026
• Nexforce Agents

O contrato vem antes do piloto

A posição cabe numa linha: em agentes de IA de longa duração, a falha não é o problema, o recomeço é. O recomeço é decisão de design, não azar: cinco itens de contrato, uma suíte de injeção de falha e um piloto que testa o meio do processo.

A assimetria de custo decide o resto. Retomar custa a escrita de um checkpoint e a disciplina de testar com falha injetada. Recomeçar custa o processo inteiro, os três sistemas já tocados e a paciência do cliente que recebeu a segunda cobrança. Quando o piloto não injeta falha, ele mede o caminho feliz e esconde o custo do recomeço no ROI do piloto, a conta que aparece depois da decisão de escalar.

Por isso o contrato vem antes do piloto: na hora em que o run cai, já não existe tempo de costurar o paraquedas.