O foco quebra antes do código quebrar

Agentes de IA de longa duração sempre morrem do mesmo jeito. Não é falta de inteligência, é perda de foco. Você monta um pipeline decente, o modelo resolve bem nas primeiras duas horas, depois começa a alucinar ferramenta, esquecer contexto, repetir chamada de API e travar em loop bobo. Quem já tentou rodar um agente por uma madrugada inteira sabe que o problema real não é o benchmark, é sustentar atenção, memória e custo sob controle quando a tarefa dura dias e não minutos. É exatamente esse gargalo que o caso da Third Moment tenta atacar de frente.

Operar um ou dois agentes por algumas horas qualquer um faz. O jogo muda quando você precisa de milhares deles trabalhando em paralelo, por mais de um dia, sem supervisão constante e sem explodir a conta. Latência acumula, janela de contexto estoura, estado diverge e a cibersegurança vira um pesadelo porque cada agente é uma superfície de ataque nova. Se 10 mil agentes conseguem trabalhar por 36 horas seguidas e ainda melhorar com o uso, isso deixa de ser demo e vira infraestrutura. A pergunta que importa para quem constrói é simples: o que eles fizeram de diferente na arquitetura para isso não desabar.

PublicidadeAnuncie aqui336x280 / responsivo

O fato

A Third Moment Research colocou 10 mil agentes para rodar de forma contínua por mais de 36 horas usando GPT-6 Astra e GPT-6.1 Sol, com Codex como camada de execução de código e Daybreak como camada de cibersegurança. Não foi um teste pontual de throughput. Foi uma operação longa, com agentes assumindo tarefas complexas, mantendo contexto por dias e refinando o próprio comportamento a partir do uso. O laboratório descreve esses agentes como sistemas que focam por dias e melhoram com o tempo, em vez de degradarem como a maioria dos setups atuais.

Na prática, o destaque está na combinação. O GPT-6 Astra aparece como modelo base para raciocínio longo e planejamento, o GPT-6.1 Sol parece otimizado para velocidade e custo em subtarefas repetitivas, o Codex assume a parte de escrita, teste e correção de código, e o Daybreak monitora comportamento para conter vazamento, injeção e uso indevido de ferramenta. É um desenho que faz sentido para operação real: modelo grande pensa, modelo menor executa em escala, executor valida no ambiente e uma camada de segurança observa tudo. Não tem mágica aqui, tem separação de responsabilidades.

Como funciona na visão de quem opera

Pensando como operador, uma frota desse tamanho só funciona com orquestração forte e memória hierárquica. É plausível que a Third Moment não jogue 10 mil agentes idênticos no mesmo prompt gigante. O padrão mais provável é um sistema de gerente e trabalhador, onde poucos agentes planejadores com GPT-6 Astra quebram o trabalho em metas menores e despacham milhares de executores com GPT-6.1 Sol. Cada executor roda com contexto curto e barato, enquanto o estado global fica em um store externo com resumos progressivos, checkpoints e fila de tarefas. Isso explica como manter foco por 36 horas sem estourar janela de contexto em cada chamada.

Em termos de API, custo e latência, a conta precisa ser fria. Dez mil agentes em paralelo, mesmo com chamadas espaçadas, geram milhões de tokens por hora. Se tudo rodasse no modelo mais pesado, a operação seria inviável. A inferência técnica mais razoável é que eles usam roteamento dinâmico: Astra para decisão difícil, Sol para varredura, reescrita e validação simples, Codex com sandbox para executar e testar. Dá para imaginar algo como ciclos de 30 a 90 segundos por agente, com backoff, cache semântico e deduplicação de chamadas. A latência média provavelmente não é baixa, mas a vazão agregada compensa porque o trabalho é assíncrono e tolerante a atraso.

O ponto mais interessante é a ideia de melhorar com o uso. Isso não significa que o peso do modelo muda em produção. Significa que o sistema aprende em volta do modelo, com memória de episódios, biblioteca de padrões que funcionaram, prompts que se autoajustam e filtros que ficam mais espertos. Pense em um agente de código que erra uma integração na hora 4, registra o erro, salva o patch que funcionou e reutiliza nas horas 20 e 30 sem chamar o modelo grande de novo. Some isso ao Daybreak observando chamadas de rede, permissões de arquivo e sequências suspeitas de ferramenta. Com 10 mil trajetórias, você tem dado suficiente para podar caminhos ruins rápido. É aprendizado de sistema, não fine tuning em tempo real.

O que isso muda na prática

Para quem constrói produto com agentes, esse caso muda a régua. Até agora, muita equipe desenhava agente para sessão curta, com humano no loop a cada 15 minutos. Se 36 horas contínuas viram viável, dá para pensar em turnos autônomos de verdade: pesquisa profunda que dura dias, migração de código que atravessa a madrugada, monitoramento de segurança que investiga sozinho. Quem ganha primeiro são labs, empresas de segurança e times de plataforma que já têm observabilidade e sandbox. Quem perde são os wrappers finos que só empilham prompt em cima de API sem gerenciar estado, custo e permissão.

Se você opera agentes hoje, tem ajuste imediato para fazer. Não tente replicar os 10 mil de uma vez. Comece replicando o padrão de separação de funções e contenção. Uma ação prática para esta semana é dividir seu agente monolítico em três papéis com limites claros: um planejador com modelo forte e contexto resumido, executores baratos com ferramentas restritas e um verificador que só aprova ação com teste ou evidência. Coloque tudo atrás de fila, com timeout, orçamento de tokens por tarefa e log completo de ferramenta. Rode por 12 horas seguidas em staging e meça deriva de foco, taxa de retry e custo por tarefa concluída. Sem esse teste de resistência, escalar é só empilhar risco.

  • Orquestre por fila e checkpoint: salve estado a cada etapa para retomar sem perder 30 horas de trabalho quando um agente travar.
  • Roteie por dificuldade: use modelo forte só para planejar e revisar, deixe o trabalho repetitivo para modelo rápido e barato.
  • Trave ferramenta por padrão: agente só ganha permissão de rede e escrita após passar em verificação, com Daybreak ou regra própria observando o comportamento.

A tensão que ninguém quer admitir

Aqui vai a dúvida real de operador: isso escala para gente normal ou só para quem tem contrato grande e infra dedicada. Rodar 10 mil agentes por 36 horas ainda deve custar uma fortuna em tokens, orquestração e monitoramento. Mesmo com roteamento inteligente, o custo por tarefa concluída pode não fechar para SaaS com margem apertada. E tem o outro lado: quanto mais autônomo e persistente o agente, maior o estrago quando ele desvia. Um loop de 10 minutos é irritante, um loop de 30 horas com acesso a código e rede é incidente de segurança. O Daybreak ajuda, mas segurança de agente ainda é um campo imaturo.

Também fica a questão do melhorar com o uso. Em sistemas grandes, melhoria rápida pode virar contaminação rápida. Se um padrão ruim entra na memória compartilhada, 10 mil agentes replicam o erro em horas. Resolve o problema de foco mas move o gargalo para curadoria de memória e avaliação contínua. Sem um sistema forte de pontuação de trajetória, rollback de conhecimento e isolamento por projeto, a frota aprende junto e erra junto. Funciona no lab, com time olhando tudo. Em produção aberta, com dados sujos e adversários tentando injetar instrução, a história pode ser bem diferente.

Conclusão

A Third Moment mostrou que agente de longa duração em larga escala deixou de ser teoria e virou problema de engenharia. Agora a questão é custo por hora útil e controle. Você confiaria 36 horas de acesso contínuo aos seus sistemas para uma frota que aprende sozinha.