Agentes de IA duráveis: uma checklist de seleção de runtime para fluxos de trabalho em produção em 2026

Por que agentes de IA duráveis são uma decisão de runtime, não apenas uma decisão de modelo

Agentes de IA duráveis não são prompts mais fortes com algumas ferramentas anexadas. São fluxos de trabalho de produção que conseguem sobreviver a atrasos, falhas parciais, eventos duplicados, revisão humana, mudanças de provedor e reinicializações de workers. Essa distinção importa porque a maioria das demonstrações de agentes esconde a parte mais difícil. O modelo responde, uma ferramenta é executada e a página parece convincente. A produção faz uma pergunta menos lisonjeira: o que acontece quando a aprovação volta amanhã, o worker morre no meio do caminho ou o mesmo webhook chega duas vezes?

Minha opinião: muitas equipes escolhem a infraestrutura de agentes tarde demais. Elas escolhem um modelo, constroem um loop de chat, conectam algumas ferramentas internas e então descobrem que o produto real é um mecanismo de fluxo de trabalho usando uma interface de IA. Nesse ponto, o estado já está espalhado por prompts, logs, memória temporária e efeitos colaterais. O runtime já foi escolhido por acidente.

Para o planejamento de 2026, a pergunta mais segura não é qual modelo deve executar o agente. É qual runtime deve ser dono do estado, das novas tentativas, das permissões, das aprovações e da recuperação. A documentação Durable AI da Temporal começa a partir de conceitos de orquestração de workflows. Cloudflare Agents e Durable Objects são relevantes para agentes com estado e coordenação em aplicações hospedadas na Cloudflare. Convex agents se encaixam em equipes que já estão construindo backends de aplicações reativos. Val Town se encaixa em automação programável leve. Uma stack customizada pode funcionar quando controle importa mais do que velocidade, mas isso também significa que a equipe assume as partes incômodas.

A Matriz de Adequação de Agentes Duráveis

Um processo prático de seleção precisa de menos adjetivos de fornecedores e mais testes de falha. A Matriz de Adequação de Agentes Duráveis compara runtimes em cinco eixos.

Temporal é uma candidata forte quando o fluxo de trabalho é longo, com estado e cheio de arestas de processo de negócio. Sua documentação de IA vale a leitura se a equipe já pensa em termos de workflows, activities, signals e novas tentativas: https://docs.temporal.io/ai. A troca é que as equipes precisam aprender o modelo de workflow e tratar o comportamento do agente como parte de um sistema distribuído maior.

Cloudflare Agents, em conjunto com Durable Objects, atende equipes que querem agentes com estado em aplicações web hospedadas na Cloudflare. A documentação relevante é https://developers.cloudflare.com/agents/ e https://developers.cloudflare.com/durable-objects/. Esse caminho pode ser atraente para sessões de agentes voltadas ao usuário, coordenação e estado de baixa latência dentro da plataforma Cloudflare. A ressalva é a adequação à plataforma. Se o restante do sistema vive longe da Cloudflare, as escolhas de integração importam.

Convex agents se encaixam em equipes de produto que já usam Convex ou querem o estado do agente próximo aos dados reativos da aplicação: https://docs.convex.dev/agents/overview. A vantagem é menos cola entre o estado da aplicação e o estado do agente. O risco é o mesmo de qualquer runtime nativo da aplicação: ele pode ser perfeito para fluxos de trabalho de produto e menos natural para orquestração entre sistemas.

Val Town é melhor tratado como uma camada rápida de automação, não como uma plataforma universal de agentes: https://docs.val.town/. É útil para pequenas ferramentas internas, scripts, tarefas agendadas, protótipos e código de ligação. É menos apropriado quando o fluxo de trabalho precisa de auditabilidade rigorosa, aprovações em várias etapas, permissões complexas ou resposta profunda a incidentes.

Um runtime customizado, construído com filas, bancos de dados, workers, agendadores e gateways de modelo, pode ser a resposta certa para ambientes regulados ou restrições incomuns de arquitetura. Ele dá controle sobre armazenamento, rede, roteamento de modelos e políticas. Também significa que a equipe deve projetar diretamente idempotência, novas tentativas, observabilidade, replay, avaliações, fluxos de aprovação e controles de custo. Isso não é um projeto de fim de semana.

Um playbook prático de avaliação

Não avalie runtimes de agentes duráveis com uma demonstração de caminho feliz. Escolha um fluxo de trabalho real e faça-o se comportar mal de propósito. Por exemplo, use um fluxo de triagem de suporte que lê um ticket, verifica o contexto da conta, redige uma resposta, espera aprovação, atualiza um CRM e envia uma mensagem. Depois teste as partes que normalmente quebram.

Mate o worker depois da chamada ao modelo, mas antes da ação de escrita. Entregue o mesmo webhook duas vezes. Altere o schema de resposta de uma ferramenta. Atrase a aprovação humana por 24 horas. Retorne um timeout parcial do CRM. Rode a chave de um provedor de modelo. Peça ao agente para retomar do meio. Se o runtime não consegue tornar esses casos rotineiros, ele não está pronto para esse fluxo de trabalho.

Uma pequena prova de durabilidade deve responder a estas perguntas:

1. Onde o estado do fluxo de trabalho é armazenado, e quem é dono dele?
2. O fluxo de trabalho consegue retomar após a reinicialização de um processo sem refazer ações inseguras?
3. As chamadas de ferramentas são idempotentes ou protegidas por chaves de idempotência?
4. Um humano consegue aprovar, rejeitar ou editar uma ação proposta sem quebrar a execução?
5. Um operador consegue inspecionar o histórico e explicar por que o agente agiu?
6. Prompts, schemas de ferramentas, versões de modelos e saídas são registrados bem o suficiente para avaliação?
7. O que acontece quando o modelo dá uma resposta ruim, mas o runtime se comporta corretamente?

Essa última pergunta é fácil de pular. Também é onde muitos programas de agentes ficam caros. Um runtime durável pode tornar a falha recuperável, mas não consegue transformar um desenho fraco de tarefa em algo bom. As equipes ainda precisam de conjuntos de avaliação, verificações de política e caminhos claros de escalonamento.

Segurança e governança mudam a decisão de runtime

Segurança de agentes não é apenas uma questão de prompt. É uma questão de arquitetura de runtime. O enquadramento da trifeta letal de Simon Willison é uma lente útil porque conecta três condições: acesso a dados privados, exposição a conteúdo não confiável e uma forma de exfiltrar informações: https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/. Quando as três aparecem no mesmo fluxo de agente, o risco de prompt injection fica mais concreto.

A seleção de runtime deve, portanto, separar caminhos de leitura, caminhos de escrita e caminhos de comunicação externa. Um agente de pesquisa que lê documentos internos não deve ter automaticamente permissão para enviar e-mails a destinatários arbitrários. Um agente de compras que pode redigir um pedido de compra não deve conseguir aprová-lo sem verificações de política. Um agente de desenvolvedor que lê código-fonte deve ter regras estreitas para publicar dados fora do workspace.

A aprovação humana ainda é útil, mas apenas se for específica. Aprovar esta execução é vago. Aprovar o envio deste e-mail exato para estes destinatários com estes anexos é melhor. O runtime deve preservar a ação proposta, o revisor, a decisão e a chamada final da ferramenta. Caso contrário, a aprovação é apenas governança fraca com um timestamp.

O que as equipes erram

O primeiro erro é tratar novas tentativas como inteligência. Repetir uma chamada de ferramenta ruim pode corrigir uma falha transitória. Repetir um plano ruim pode fazer o dano se repetir mais rápido. Runtimes duráveis precisam de políticas de nova tentativa, mas também precisam de condições de parada, escalonamento humano e registros que mostrem o que foi tentado novamente e por quê.

O segundo erro é confundir memória com fonte da verdade. Memória de conversa é contexto útil. Ela não deve ser o único lugar onde aprovações, estado do cliente, ações financeiras ou decisões de conformidade vivem. Workflows duráveis precisam de uma fonte real da verdade, e o runtime deve deixar esse limite claro.

O terceiro erro é pular a proteção contra duplicidade. Webhooks se repetem. Usuários clicam duas vezes. Agendadores se sobrepõem. Provedores dão timeout depois de concluir uma solicitação. Qualquer fluxo de trabalho que escreve em sistemas externos precisa de chaves de idempotência, IDs externos ou outro padrão de controle de duplicidade.

O quarto erro é construir uma plataforma antes de provar um fluxo de trabalho. Trabalho de plataforma parece produtivo porque cria abstrações. O melhor primeiro movimento é um fluxo de trabalho estreito com arestas dolorosas. Se o runtime lida bem com isso, as abstrações serão baseadas em evidências em vez de gosto.

O quinto erro é ignorar custo e latência até o lançamento. Agentes duráveis podem chamar vários modelos, ferramentas, bancos de dados e verificações de política. Alguns fluxos de trabalho precisam disso. Outros precisam de um caminho mais simples, como recuperação mais uma recomendação redigida. Meça a execução inteira, não apenas a latência do modelo.

Caminhos recomendados

Para equipes de produto que adicionam agentes a uma aplicação existente, comece pelo runtime mais próximo do estado da aplicação. Convex pode se encaixar se o produto já usa Convex. Cloudflare pode se encaixar em sessões com estado voltadas ao usuário dentro de aplicações hospedadas na Cloudflare. O fator decisivo geralmente é a propriedade operacional: as pessoas que entregam a funcionalidade também devem conseguir inspecionar e depurar o agente.

Para equipes de plataforma que orquestram processos de negócio longos, Temporal merece avaliação séria. Ele torna duração, novas tentativas, signals e histórico de workflow preocupações de primeira classe. Isso é útil quando agentes se tornam parte de processos de onboarding, finanças, operações, compras ou suporte.

Para equipes de desenvolvedores que constroem automações internas, Val Town pode ser um bom ponto de partida quando a tarefa é pequena e reversível. Mantenha o escopo honesto. Se a automação começar a tocar dados sensíveis, aprovações ou escritas irreversíveis, mova o fluxo de trabalho para um runtime com controles mais fortes.

Para equipes com conformidade rigorosa, rede incomum ou necessidades customizadas de roteamento de modelos, uma stack customizada pode se justificar. A equipe deve orçar mais do que workers e filas. Ela precisará de aplicação de políticas, trilhas de auditoria, armazenamento de avaliações, ferramentas de replay, procedimentos de incidente e manutenção contínua.

A checklist de planejamento

Antes de começar o trabalho de produção, escreva as respostas em linguagem simples:

O melhor runtime não é aquele com mais branding de agentes. É aquele que torna a falha compreensível, limita ações inseguras e dá aos operadores um caminho limpo de volta a um estado conhecido. Escolha-o com um fluxo de trabalho real, não com uma apresentação.