Engenharia de loop não é um while loop com um LLM dentro. É como a Apollo roda sem supervisão.

São seis horas de uma rodada de código durante a madrugada. O agent vem iterando havia horas: escreve uma mudança, roda um teste, escreve outra. Às 6 da manhã ele posta seu resumo. Feature completa. Todos os testes verdes. Pronto para review. Um humano abre o app e o botão não faz nada, porque o agent testou a função isoladamente e nunca abriu a página à qual ela estava conectada. Ninguém mentiu. O loop perguntou à única testemunha disponível, o modelo que fez o trabalho, se o trabalho estava pronto, e a testemunha disse que sim.

Essa é a falha que a engenharia de loop existe para fechar, e vale a pena nomeá-la com precisão: engenharia de loop é a estrutura externa durável dentro da qual um agent de longa duração roda: uma meta-como-contrato, um executor, um verificador externo que o executor não consegue contornar, e uma trilha de prova. Não um prompt. Não um modelo maior. Uma estrutura que fica ao redor do modelo e decide, de fora dele, se a execução de fato aterrissou.

Este post defende essa definição contra a versão mais barata que a maioria dos times busca primeiro: um “loop” como apenas um while loop com um LLM dentro, que recebe o mesmo prompt de novo até anunciar sucesso. Essa versão é sedutora porque exige quase nenhuma engenharia — e é exatamente a forma da falha das 6 da manhã acima, por uma razão específica e documentada.

A versão ingênua: um while loop com um modelo dentro

Aqui está o loop que quase todo mundo constrói primeiro, porque é o loop que exige menos pensar. Você dá um prompt ao modelo com uma tarefa. Deixa ele trabalhar. Pergunta a ele, em linguagem simples, “você terminou?” Se ele disser que sim, para. Se disser que não, ou se der timeout, você prompta de novo com o que sobrou de contexto. Repete.

Isso não é um argumento espantalho — é a forma padrão de todo wrapper de agent do tipo “continue até terminar”, popular porque são três linhas de código de orquestração em volta de uma chamada de API, e para tarefas curtas com uma linha de chegada óbvia funciona bem. O problema começa exatamente onde o valor deveria começar: trabalho longo, ambíguo, de múltiplas etapas — o único tipo que vale a pena automatizar sem supervisão.

O mito do while loop trata o próprio relato do modelo como a linha de chegada, e o próprio relato do modelo não é evidência independente. É o mesmo processo que fez o trabalho, descrevendo o trabalho, com os mesmos pontos cegos. Se o modelo esqueceu de checar algo enquanto construía, ele esquece de checar essa mesma coisa enquanto avalia — porque é o mesmo esquecimento.

Por que o loop não consegue se auto-avaliar

O próprio time de engenharia da Anthropic esbarrou nisso diretamente ao construir harnesses para agents de programação de longa duração, e documentou isso sem rodeios: seus agents mostravam “uma tendência a marcar uma feature como completa sem testes adequados,” fazendo mudanças e até rodando testes unitários ou comandos curl contra um servidor de dev, mas falhando consistentemente “em reconhecer que a feature não funcionava de ponta a ponta.” A correção que a Anthropic relata não é um prompt mais esperto — é dar ao agent ferramentas para observar o sistema rodando (automação de browser, não a própria narração), o que “melhorou drasticamente a performance” precisamente porque parou o agent de confiar na própria palavra.

Esse é o mecanismo, sem rodeios: uma auto-checagem não é uma checagem, é uma repetição do raciocínio que produziu a coisa sendo checada. O termo de mercado para isso, cunhado fora da Apollo e que merece crédito em vez de reinvenção, é engenharia de loop. Boris Cherny, que construiu o Claude Code, descreveu a mudança sem rodeios em meados de 2026: “Eu não prompto mais o Claude. Eu tenho loops rodando que promptam o Claude e descobrem o que fazer. Meu trabalho é escrever loops.” O guia de 2026 do AI Builder Club pegou o termo dali e o formalizou como “a disciplina de projetar o loop dentro do qual um agent roda, o que ele faz entre chamadas de tool, quando ele checa o próprio trabalho, e como ele decide que terminou, em vez de escrever cada prompt à mão” — uma cobertura downstream útil, mas a frase de Cherny é a origem. A síntese que conecta o loop a um contrato e a uma trilha de prova é nossa.

Engenharia de loop é a estrutura externa durável dentro da qual um agent de longa duração roda: uma meta-como-contrato, um executor, um verificador externo que o executor não consegue contornar, e uma trilha de prova. Repita porque é o post inteiro: a correção não é uma auto-checagem melhor. É remover o “auto” da checagem.

O que a engenharia de loop de fato é, estruturalmente

Se a auto-checagem é a doença, a cura não é “checar duas vezes.” É mover a checagem para um lugar que o executor não consegue alcançar: um loop externo, um wrapper em volta do ciclo de execução do agent rodando como um processo separado do qual o agent nunca tem conhecimento. Ele faz seu trabalho e produz um output; um processo fora daquele turno compara o output contra a meta real e decide se continua, para, ou reinicia.

Então o loop engenheirado tem quatro partes duráveis, cada uma removendo um ponto onde o loop ingênuo confiava no executor para se auto-avaliar. É aqui que “como você roda isso, concretamente” para de ser abstrato: a Apollo é construída como três camadas — System of Record, System of Intelligence, System of Action — de forma que cada uma dessas quatro partes ganha um endereço fixo, em vez de viver dentro de um único prompt de longa duração.

Uma meta-como-contrato declara o estado final mensurável e a evidência que o comprova, escrita antes da execução começar, para que “pronto” tenha uma definição que precede o trabalho e não pode ser redefinida por quem está fazendo ele. Defendemos esse ponto em “a meta é um contrato ou é um desejo”: uma meta em prosa é um desejo, uma meta como uma condição checável é um contrato. A própria referência de contrato e loop da Apollo documenta isso como o schema contra o qual todo agent de longa duração roda — construído para viver no System of Record, o mesmo lugar onde vive um deal ou um ticket, para que uma meta não consiga mutar silenciosamente no meio da execução do jeito que uma nota rascunho num prompt consegue.

Um executor faz o trabalho: lê o contrato, age, e seu acesso de escrita é limitado aos artefatos da tarefa — nada no verificador, nada no próprio contrato. Na forma da Apollo, o executor é uma execução do System of Intelligence, cercado por onde ele tem permissão para escrever, não por quão educadamente ele é instruído a se comportar.

Um verificador externo lê o output do executor e o checa contra o contrato a partir de um lugar estruturalmente fora do alcance do executor, um ponto que merece seu próprio post, “o verificador não pode viver no repo do executor”: um verificador que o executor pode editar não é um verificador, é um espelho. O System of Action da Apollo é a única camada com permissão para escrever resultados de volta no System of Record, e é construído para fazer isso só com uma aprovação de um verificador que o executor nunca toca.

Uma trilha de prova registra o que o verificador encontrou, não o que o executor alegou, para que “pronto” se torne um artefato que você pode auditar depois em vez de uma frase que você tem que confiar no momento — vivendo no System of Record também, ao lado do contrato contra o qual ela avalia, não num canal lateral que ninguém lembra de checar.

Um loop que deixa o trabalhador decidir quando o trabalho terminou não é uma etapa de verificação. É uma formalidade que o trabalhador sempre ia passar.

O executor não pode ser o verificador

Este é o ponto que os times resistem por mais tempo em aceitar: parece tranquilo deixar um modelo forte checar o próprio output, especialmente um bom o bastante para ter feito o trabalho. Não é — se o mesmo processo escreve a mudança e a avalia, a nota não é independente da coisa que está sendo avaliada. É um primo próximo de uma falha coberta na camada de veredito em “nunca deixar um modelo corrigir a própria lição de casa”: um juiz da mesma família do escritor pontua o estilo dele como se fosse correção. Este post está uma camada além: mesmo um veredito honesto e entre famílias diferentes não vale nada se computado dentro do próprio escopo de escrita do executor — que é exatamente por que o System of Action da Apollo, não o executor, é a única coisa com permissão para agir sobre um veredito.

Engenharia de loop é a estrutura externa durável dentro da qual um agent de longa duração roda: uma meta-como-contrato, um executor, um verificador externo que o executor não consegue contornar, e uma trilha de prova. A fronteira do escopo de escrita é o que faz “externo” ser uma palavra real em vez de uma decoração.

A trilha de prova: pronto é um evento checável, não um sentimento

Mesmo com a fronteira no lugar, resta uma lacuna: um veredito que só existe no momento ainda é, na prática, uma alegação que alguém precisa lembrar que aconteceu, e a memória de um veredito degrada como qualquer outra memória. Nosso post sobre “por que um eval é a única definição honesta de ‘funciona’” argumenta que o verificador precisa rodar a coisa real, não um substituto mockado que prova que o código executou sem provar que o comportamento estava correto — uma alegação sobre o rigor da checagem. A alegação deste post é sobre o que acontece depois: o resultado precisa ser escrito, não falado e esquecido, porque um veredito que vive só num transcript de chat é exatamente tão frágil quanto o auto-relato que ele substituiu.

Uma trilha de prova é deliberadamente sem glamour: um registro com timestamp do que o contrato pediu, do que o executor produziu, do que o verificador encontrou, e se passou — a diferença entre “tenho quase certeza que isso rodou limpo semana passada” e apontar para a linha que diz isso. Uma meta-como-contrato sem uma trilha de prova é uma promessa sem recibo, e um agent de longa duração operando sem supervisão por horas é exatamente o cenário em que alguém, depois, vai precisar de uma. É também por isso que o contrato, o verificador, e a trilha de prova precisam de um verdadeiro “sistema de registro construído para ação de agent”, do mesmo jeito que contratos financeiros vivem num ledger, não na memória de quem quer que estivesse prestando atenção naquele trimestre.

O que isso custa, honestamente

Nada disso é grátis, e este post diz isso sem rodeios em vez de vender a estrutura como um upgrade sem nenhuma desvantagem. Uma meta-como-contrato precisa ser redigida, com antecedência, com precisão suficiente para que uma máquina consiga checá-la — uma meta vaga produz um contrato vago, que não pode ser verificado, só realocando o problema um nível acima. Um verificador externo precisa ser construído e mantido separadamente do executor, dobrando a superfície pela qual você é responsável por manter correta. Uma trilha de prova custa armazenamento e a disciplina de escrever nela a cada ciclo, não só nos que deram certo.

A troca vale a pena mesmo assim: cada um desses custos é pago uma vez, antecipadamente, por quem projeta o loop. A alternativa, o loop ingênuo de auto-checagem, paga seu custo depois, de forma imprevisível, na pior moeda que existe: uma execução que parecia terminada, que todo mundo acreditava estar terminada, e não estava.

A virada

Dando um passo atrás, isso é um problema velho com roupa nova. Todo time que já shipou qualquer coisa enfrentou a mesma tentação: deixar quem fez o trabalho também declarar que está bom, porque é mais rápido, porque a pessoa já está ali. Todo time que aprendeu do jeito difícil chega na mesma correção: uma fronteira entre fazer e julgar — não porque quem faz não é confiável, mas porque ninguém, humano ou modelo, é uma testemunha neutra do próprio esforço.

O modelo dentro de um loop de agent não é mais a parte cara. Ele é rápido, barato por hora, e melhora a cada poucos meses sem ninguém levantar um dedo. O que não melhora sozinho é a estrutura ao redor dele: o contrato que diz o que “pronto” significa antes da execução começar, a fronteira que impede o trabalhador de se auto-avaliar, e o registro que deixa alguém checar, depois, que aconteceu do jeito que alega ter acontecido. Essa estrutura é a parte que vale a pena engenheirar, e é a parte em torno da qual a Apollo é construída: o System of Record guarda o contrato antes de uma execução começar, o System of Intelligence é cercado para que o executor possa agir mas nunca se reavaliar, e o System of Action é construído para que nada volte a pousar no registro até um verificador fora dos dois aprovar. O modelo sempre ia aparecer esperto. A pergunta que a engenharia de loop responde é se alguém pode confiar no que ele diz sobre o próprio trabalho — e a resposta, rodando nessa estrutura, é: você não precisa confiar nele, você pode checar.

---

Esse é o mecanismo em torno do qual a Apollo é construída, não parafusado depois dos fatos: um contrato no System of Record, um executor no System of Intelligence com um escopo de escrita limitado, um verificador que ele não consegue alcançar, e um System of Action que só escreve de volta o que o verificador já aprovou. Se seus agents relatam o próprio sucesso e você acredita neles porque o relato soa confiante, você já tem o problema das 6 da manhã — você só ainda não esteve na sala quando alguém abre o app.