Kubernetes dá onde rodar aos agentes de IA, mas não como se recuperar de falhas

O argumento central é simples: reiniciar um agente não é recuperar o trabalho dele. O Kubernetes e as camadas novas de sandbox restauram o ambiente (filesystem, snapshot, identidade), mas não registram quais etapas já foram concluídas. O texto dá o exemplo de um agente de reembolso. O nó falha depois de a API de pagamento aceitar a chamada, mas o último snapshot é de antes dela. O agente volta, não sabe que pagou e paga de novo.

A proposta é colocar durable execution acima do sandbox. O runtime grava cada passo (chamadas de LLM, chamadas de ferramentas, decisões, entradas e saídas) e, após uma falha, um novo processo retoma da próxima etapa não concluída. O Dapr Workflow, que roda como sidecar e persiste cada passo num state store, aparece como opção open source. O autor diferencia isso de checkpointing de framework: no checkpoint, o time ainda cuida de detectar falha, decidir retries e garantir idempotência de cada ferramenta. Na durable execution, o runtime assume isso. Há ainda o ganho de custo (uma falha no passo 30 não obriga a pagar de novo os tokens dos 29 anteriores) e o de auditoria, já que o histórico pode ser assinado criptograficamente e atrelado à identidade do workload.

Em 23 de março de 2026, o CEVIU noticiou "Executando Agentes no Kubernetes com Agent Sandbox", que tratava de identidade persistente, ambientes isolados e suspensão de agentes de longa duração. Em 26 de outubro de 2026, o CEVIU publicou "Kagent e Agent Substrate: sandboxing de agents com isolamento, segurança e escala no Kubernetes". Aquelas matérias cobriam o onde rodar. A notícia de hoje aponta a lacuna que sobra: o que o agente já fez. E em 5 de novembro de 2026, o CEVIU abordou "Dívida técnica em sistemas de agentes: onde a orquestração deve ficar na arquitetura", que já citava retries de operações com efeitos colaterais e trilhas de auditoria como responsabilidades que não deveriam ficar nos prompts e agent loops. O tema da recuperação ganha agora um nome e uma ferramenta concreta.

Para quem opera plataforma de agentes, a leitura é que isolamento e snapshot resolvem disponibilidade, não correção. Se o agente toca pagamento ou dado de paciente, a pergunta de design passa a ser idempotência e histórico de execução, não só limite de recurso. Vale revisar o que hoje depende de retry na mão do time de aplicação.