Agentes de longa execução — o que muda quando um agente roda por dias

• Surge um novo paradigma em que agentes de IA operam autonomamente por vários dias ou semanas, em vez de uma única sessão de chat, atravessando várias janelas de contexto e sandboxes, recuperando-se de falhas e retomando de pontos de interrupção
• Os agentes tradicionais esbarram em limites estruturais de uma única sessão, como esgotamento da janela de contexto, excesso de confiança na autoavaliação e reintrodução de alterações anteriores
• Empresas como Anthropic, Google e Cursor estão convergindo para uma arquitetura com separação entre loop do modelo, sandbox de execução e logs de sessão
• Os principais desafios dos agentes de longa execução são gerenciamento de estado persistente, autoverificação e compressão de contexto, e o texto apresenta cinco padrões de projeto para resolvê-los
• Mais do que o modelo em si, a principal área de investimento que de fato gera diferença de produtividade está na camada de estado, sessão e handoff estruturado ao redor do modelo

---

Três significados de “longa execução”

• Long-horizon reasoning: capacidade de planejar e executar ao longo de muitas etapas dependentes, sendo principalmente uma questão de qualidade do modelo. Segundo a métrica de time horizon da METR, o tempo de tarefa que modelos de fronteira conseguem concluir com 50% de confiança vem dobrando aproximadamente a cada 7 meses desde 2019; se a tendência continuar, isso permitiria concluir tarefas em escala de dias em 2028 e em escala de anos em 2034
• Long-running execution: uma estrutura em que o processo do agente roda por horas ou dias, com o modelo podendo ser chamado milhares de vezes, sendo principalmente um problema de projeto do harness
• Persistent agency: forma em que o agente mantém identidade além de uma única tarefa, acumulando memória e aprendendo preferências do usuário. O Memory Bank do Google é um exemplo representativo
• Em produção, agentes reais combinam os três, mas os problemas de engenharia e as soluções de cada um são diferentes

Por que agentes de longa execução importam

• Um agente que roda por 10 minutos fica no nível de responder perguntas ou corrigir pequenos bugs, mas um agente que roda por 10 horas pode desenvolver uma funcionalidade inteira, concluir uma migração acumulada por 6 trimestres ou fazer pesquisa no nível de um analista júnior
• No anúncio do Claude Sonnet, a Anthropic revelou casos internos de codificação autônoma por mais de 30 horas, incluindo a criação, em uma única execução, de um app no estilo Slack com cerca de 11.000 linhas
• No Project Vend, uma instância do Claude operou por um mês um negócio real de máquina de vendas em escritório, gerenciando estoque, definindo preços e se comunicando com fornecedores. A primeira fase produziu casos relevantes de falha, e a segunda melhorou muito
  • O ponto central não era a lucratividade, mas observar os problemas de consistência que surgem quando o agente mantém identidade ao longo de semanas, e não apenas de turnos

As três barreiras que todo agente de longa execução enfrenta

• Contexto finito: até uma janela de 1M tokens se esgota, e antes mesmo disso já ocorre context rot (degradação gradual do desempenho do modelo). Uma execução de 24 horas não cabe em nenhum roadmap atual de janela de contexto
• Ausência de estado persistente: uma nova sessão começa em branco. A Anthropic compara isso a “um engenheiro de plantão chegando sem saber absolutamente nada do que aconteceu no turno anterior”
• Ausência de autoverificação: quando o modelo avalia o próprio trabalho, surge um viés positivo consistente. À pergunta “terminou?”, ele responde “sim” com mais frequência do que deveria e, sem um sinal de verificação separado, entrega resultados com convicção total quando na prática só concluiu 30%

O loop Ralph: uma implementação simples de agente de longa execução para praticantes

• O loop Ralph (técnica Ralph Wiggum) é um padrão de agente de longa execução para uso prático, popularizado por Geoffrey Huntley e Ryan Carson, cuja implementação de referência é um único script bash
• Fluxo de funcionamento: selecionar uma tarefa não concluída (prd.json) → montar o prompt com tarefa, contexto e memos → chamar o agente → executar testes → acrescentar o resultado em progress.txt → atualizar a lista de tarefas → repetir
• O princípio central é: o agente em si tem amnésia, mas o sistema de arquivos mantém a memória. prd.json funciona como plano, progress.txt como caderno de laboratório e AGENTS.md como manual de regras em evolução
• O Compound Product de Ryan Carson encadeia vários loops na forma loop de análise (ler relatórios diários) → loop de planejamento (gerar PRD) → loop de execução (escrever código), uma versão open source da estrutura tripla planner-generator-evaluator à qual a Anthropic chegou de forma independente
• Só com script bash e arquivos JSON já é possível montar, da noite para o dia, um agente de longa execução funcional. O que Google e Anthropic transformaram em produto foi tornar esse padrão recuperável, seguro e observável

Anthropic: do harness à separação Brain/Hands/Session

• Primeira abordagem (estrutura de harness): um harness de 2 agentes para desenvolvimento full stack autônomo. O agente Initializer configura o ambiente inicial do projeto, expande o prompt em feature-list.json e escreve o script de inicialização (init.sh). O agente Coding acorda repetidamente, avança por funcionalidade, roda testes, escreve em claude-progress.txt e faz commits
  • Regra de test ratchet: “não é permitido apagar ou modificar testes” — evita uma falha comum em que o agente apaga testes que falham para fazê-los passar
  • Na versão expandida da InfoQ, isso evolui para a estrutura tripla planner, generator, evaluator. A separação entre geração e avaliação é importante porque o modelo tende a avaliar o próprio trabalho com tolerância excessiva
• Segunda abordagem (separação Brain/Hands/Session): arquitetura do Claude Managed Agents (lançado no início de abril de 2026)
  • Brain: o modelo e o loop do harness
  • Hands: o ambiente de execução temporário em sandbox onde as ferramentas realmente rodam
  • Session: um log de eventos append-only de todos os pensamentos, chamadas de ferramenta e observações
• O enquadramento central da Anthropic é: “todos os componentes do harness codificam suposições sobre o que o modelo não consegue fazer sozinho”; quando tudo fica acoplado, qualquer obsolescência dessas suposições obriga a mudar o sistema inteiro, e ao separar, o harness se torna stateless e a sandbox pode ser tratada como cattle (descartável)
• Um novo container pode chamar wake(sessionId) e reconstruir o estado a partir do log. O time-to-first-token caiu cerca de 60% no p50 e mais de 90% no p95 — resultado de poder começar o raciocínio antes de preparar a sandbox
• O conceito de session-event-log é a parte mais subestimada. É isso que torna um agente de longa execução recuperável. Sem isso, uma falha no container vira imediatamente uma falha de sessão
• Stack para computação científica: CLAUDE.md (plano vivo que o agente aprende e edita), CHANGELOG.md (caderno de laboratório portátil), tmux + SLURM + git (camada de execução e coordenação), loop Ralph (reverificação ao declarar conclusão)
  • Caso representativo: um solver de Boltzmann construído pelo Claude Opus ao longo de vários dias alcançou erro inferior a 1% em relação à implementação de referência CLASS, comprimindo meses ou anos de trabalho de pesquisadores

Cursor: estrutura Planner, Worker, Judge

• Na expansão da codificação autônoma de longa duração do Cursor, houve três iterações de projeto
  • Primeira (coordenação plana): agentes em posição equivalente escreviam em arquivos compartilhados com locks → surgiram gargalos, e os agentes passaram a agir de forma excessivamente avessa a risco, levando a churning (repetir sem fazer commit)
  • Segunda (controle de concorrência otimista): os gargalos foram resolvidos, mas o problema de coordenação continuou
  • Terceira (produção atual): Planner (explora a base de código e gera tarefas, podendo criar subplanners recursivamente), Worker (execução focada, tarefas independentes sem coordenação mútua), Judge (decide fim da iteração e se deve reiniciar)
• A descoberta central: “uma parcela surpreendentemente grande do comportamento do sistema é determinada pelo prompt, mais do que pelo harness ou pelo modelo”
• O encaixe entre modelo e papel faz parte da superfície de projeto: modelos GPT superam o Opus em trabalho autônomo de longa duração. O Opus tende a interromper cedo e escolher atalhos. Mesma tarefa, papéis diferentes, modelos diferentes
• Composer 2 (modelo proprietário de fronteira para coding) e agente em nuvem em background: tarefas longas passam a rodar não localmente, mas na infraestrutura em nuvem da Anysphere. Refatorações de 8 horas e migrações de código em toda a base continuam mesmo com o notebook fechado
  • Se o trabalho começar localmente e for estimado em mais de 30 minutos, ele muda para a nuvem, e depois é possível reconectar até pelo celular
  • Cada agente roda em um git worktree isolado e faz merge via PR
• A estrutura final se parece com a da Anthropic: separação de papéis, persistência de sessão, judge ao lado do worker e tarefas longas coordenadas por git em sandboxes na nuvem

Google: agentes de longa execução na Agent Platform

• No Cloud Next '26, o Vertex AI foi integrado ao Gemini Enterprise Agent Platform, transformando agentes de longa execução em um produto formal com SLA definido
• Agent Runtime: suporte a “execução autônoma por vários dias”, cold start em subsegundos e provisionamento de sandbox on-demand. Exemplo de uso: uma sequência de prospecção comercial que leva uma semana
• Agent Sessions: persistência de histórico de conversa e eventos. IDs de sessão customizados podem ser mapeados a registros em CRM ou banco de dados, permitindo armazenar o estado do agente junto com o estado do negócio
• Agent Memory Bank: camada de memória de longo prazo com GA (disponibilidade geral) no Next '26. Faz curadoria da memória a partir de sessões, delimita por ID de usuário e oferece API de busca. No caso da Payhawk, um agente baseado em Memory Bank reduziu em mais de 50% o tempo de envio de despesas
• Agent Sandbox (execução de código reforçada), Agent-to-Agent Orchestration, Agent Registry, Agent Identity, Agent Gateway, Agent Observability, Agent Simulation e outros cobrem praticamente todas as preocupações de operação em produção. Inclui IDs criptográficos e logs de auditoria exigidos por empresas
• Em termos de arquitetura, é a mesma separação brain/hands/session da Anthropic transformada em produto em escala de plataforma, com ADK (kit de desenvolvimento code-first) e Agent Studio (ferramenta visual) em bundle. O que há 3 anos exigia construir tudo do zero agora virou a escolha de “qual versão da separação brain/hands/session pegar emprestada”

Cinco padrões para agentes de longa execução em produção

• Checkpoint-and-resume: a falha mais comum em vários dias é a perda de contexto. Se houver erro no 201º documento depois de processar 200, sem checkpoint é preciso reiniciar do zero. Trate o agente como um processo de servidor de longa execução: grave o estado intermediário em disco, faça checkpoint a cada N unidades de trabalho e recupere após falha. O ponto crucial é definir a granularidade adequada do checkpoint (nem em toda etapa, nem só no fim)
• Delegated approval (human-in-the-loop): implementações antigas serializam estado em JSON → webhook → espera de resposta, mas isso gera estado stale e notificações perdidas. Em um runtime de longa execução, o agente pode pausar mantendo toda a cadeia de raciocínio, memória de trabalho, histórico de ferramentas e ações pendentes. Durante a revisão humana, o consumo de compute vai a zero, e a retomada ocorre com latência de subsegundos. O Mission Control do Google funciona como caixa de entrada para isso
• Memory-layered context: um agente que roda por 7 dias precisa de mais do que estado de sessão. Memory Bank (memória curada de longo prazo) + Memory Profiles (consulta de baixa latência). O modo de falha em produção é memory drift — o agente aprende atalhos procedurais em interações não estruturadas e passa a aplicá-los amplamente. É preciso governar a memória como se fosse um microsserviço. Agent Identity (permissões de leitura/escrita), Agent Registry (rastreamento de versões do agente), Agent Gateway (aplicação de políticas)
• Ambient processing: agentes que não conversam com humanos, mas reagem a eventos em streams Pub/Sub ou tabelas BigQuery, como moderação de conteúdo, detecção de anomalias ou classificação de inbox. Se a política for definida no Gateway, e não hardcoded no agente, é possível propagar mudanças de política para centenas de agentes sem redeploy
• Fleet orchestration: em sistemas reais, em vez de um único agente, um coordenador delega subtarefas a especialistas (Lead Researcher Agent, Scoring Agent, Outreach Agent). Cada especialista tem Identity própria (por exemplo, o Outreach Agent não pode acessar dados financeiros usados pelo Scoring), política própria e item próprio no Registry. O ADK trata isso de forma declarativa com workflows baseados em grafos
• Os padrões podem ser combinados. Exemplo em um sistema de compliance: checkpointing no processamento de documentos + aprovação delegada em gates de revisão + camada de memória entre sessões + orquestração de frota para coordenação de especialistas

Como construir na prática

• Desenvolvedores que querem tarefas longas de coding no próprio repositório: usar Claude Code, Antigravity, Cursor, Codex etc. Manter AGENTS.md como checklist de piloto (curto, só com itens vindos de falhas reais). Adicionar hooks de typecheck e lint, criar arquivo de plano antes de começar e reverificar com o loop Ralph quando o agente disser que terminou. Para trabalhos de várias horas ou noturnos, rodar em worktree para continuar mesmo com o notebook fechado, e fazer commits a cada unidade significativa de trabalho. É o caminho de maior alavancagem para a maioria das pessoas
• Construir um produto com agentes hospedados: não construir o runtime do zero; escolher uma opção gerenciada. Hoje há três opções práticas: Google Agent Platform (Agent Engine + Memory Bank + Sessions), Claude Managed Agents ou hospedagem própria sobre ADK, Claude Agent SDK ou Codex SDK. As opções gerenciadas já oferecem separação brain/hands/session, observabilidade, identidade e trilha de auditoria. A hospedagem própria oferece mais controle e uso de modelos especializados
• Trabalho autônomo e operacional (monitoramento, pesquisa, operações): exige persistência no estilo Memory Bank. ADK + Memory Bank + Cloud Run + Cloud Scheduler formam a stack mais limpa para “rodar o agente a cada N horas, acumular estado e alertar em limiares”

Práticas essenciais, independentemente do caminho

• Definir explicitamente as condições de conclusão antes de iniciar o agente: é a alavanca mais importante em longa execução. Escrever critérios de conclusão explícitos e testáveis em arquivo externo evita que o agente redefina “concluído” durante a execução
• Separar avaliador e gerador: autocorreção e autoavaliação são um modo crítico de falha. O pipeline planner/worker/judge ou o par generator/evaluator não é uma questão de estilo, mas um padrão arquitetural real. Mesmo modelo, mas papéis e prompts diferentes
• Investir em log de sessão, não em prompt: um log de eventos append-only torna o agente recuperável, depurável e auditável. Se não for possível reconstruir as últimas 24 horas de atividade do agente a partir de armazenamento persistente, então isso é apenas um shell script de longa execução chamando LLM
• Tratar compressão e reset de contexto como cidadãos de primeira classe: a Anthropic concluiu que, em tarefas muito longas, compressão baseada só em resumo não basta; o harness precisa desmontar completamente a sessão e reconstruí-la a partir de arquivos de handoff estruturados. Isso equivale, em essência, a integrar um novo engenheiro ao trabalho

Limites práticos atuais

• Custo: rodar por 24 horas com modelos de fronteira custa caro. Sem orçamento, circuit breakers e hard cap de gasto com ferramentas, é possível consumir em uma tarde inteira o orçamento semanal de API
• Segurança: um agente de longa execução com chaves de API, acesso à nuvem e permissão para comandos de shell tem uma superfície de ataque muito maior do que uma sessão de chat. Por isso o padrão de separação brain/hands é importante — o código gerado pelo modelo deve rodar em sandbox sem acesso a credenciais
• Alignment drift: ao atravessar várias janelas de contexto, o agente deriva. O objetivo original é resumido e re-resumido, perdendo fidelidade. Hooks e judge existem para defender contra isso, e esse é o motivo mais comum para “o agente fazer algo que não foi pedido”
• Verificação: auditar 24 horas de atividade autônoma continua exigindo tempo humano real. Observabilidade e saídas estruturadas (PRs, commits, briefings, execuções de teste) são o que tornam isso tractable
• Papel do humano: definir uma tarefa com precisão suficiente para que um agente execute por um dia inteiro é mais difícil do que fazê-la diretamente. A habilidade cujo valor mais cresce não é escrever código, mas escrever especificações que sobrevivam ao contato com um executor autônomo

Para onde isso vai

• Google, Anthropic e Cursor estão convergindo para a mesma estrutura: separação entre loop do modelo, sandbox de execução e log de sessão, separação entre planejamento, geração e avaliação, compressão, hooks e resets de contexto integrados, e memória exposta como serviço gerenciado
• As diferenças são de superfície: o Google Agent Platform é uma stack enterprise com identidade e auditoria embutidas; o Claude Managed Agents é uma “versão hospedada do harness da Anthropic”; o agente em background do Cursor é “coding de longa duração levado da IDE para a nuvem”
• O problema mais difícil do próximo ano não estará nas camadas individuais, mas na coordenação acima delas: operar vários agentes long-running na mesma base de código, agentes que leem seus próprios traces e corrigem o próprio harness, e harnesses que montam ferramentas e contexto em JIT (just-in-time) conforme a tarefa
• Os modelos continuam centrais, mas a lacuna entre uma janela de chat e um agente capaz de rodar durante a noite está majoritariamente em estado, sessão e handoff estruturado — e é nisso que vale investir tempo de aprendizado agora

[jjpark78]

Eu comecei a usar o hermes para tentar resolver esse problema, e acho que não é ruim não hahaha