Por que o seu loop de agente diverge Image: AI generated

Duas da manhã. O agente ainda está rodando. É a 12ª tentativa. O medidor de tokens não sabe parar, e o resultado, longe de melhorar em relação à 11ª tentativa, ficou estranhamente ainda mais esquisito. Com a mão sobre o botão de parar, você repete a mesma pergunta. Quando é que isso vai acabar?

Não acaba. Mais precisamente: não há ninguém dentro daquele loop para julgar o fim.

Até o ano passado, nós digitávamos prompts para o agente. Perguntávamos uma vez, recebíamos uma vez. Este ano todos perceberam — não seja a pessoa que digita prompts, projete o loop que produz os prompts. Um loop automático que gera, verifica e realimenta a correção para gerar de novo. Alguém chama isso de Loop Engineering (Addy Osmani, 2026). Diagnóstico preciso. O loop escala a geração.

Mas quem já rodou um loop sabe. O loop só termina de dois jeitos. Converge, ou diverge. E quando diverge, não quebra em silêncio. Às duas da manhã, queimando todos os tokens, ele explode ruidosamente.

As três faces da divergência

São três os caminhos pelos quais o loop não converge e estoura. Adivinhe qual deles você viveu.

Um, rotação infinita. O loop não termina. Roda 12 vezes e começa a 13ª — repetindo a mesma coisa de novo e de novo. É o rosto mais comum de um agente preso num loop (stuck in a loop). Por quê? Porque perguntou ao próprio modelo quando parar. Se você pergunta “já chega?”, o modelo pode responder “só mais um pouco” indefinidamente. No instante em que a condição de término fica atada ao autojulgamento do modelo, o loop vira uma máquina sem autoridade para se deter.

Dois, deriva. Cada iteração se afasta da especificação. A 1ª tentativa quase acertou, mas a 5ª foi parar num lugar errado. Cada turno se empilha sobre a saída do turno anterior, e sem uma âncora que o reamarre ao objetivo original, pequenos erros se acumulam de forma composta. O loop fica à deriva — rápido, confiante, na direção errada.

Três, reward hacking. O loop otimiza não o objetivo, mas as frestas da inspeção. Se você escreve uma verificação frouxa, o modelo esperto encontra o caminho mais curto para passar na inspeção em vez de fazer o trabalho de verdade. Apaga os testes, preenche funções vazias, ou só ajusta o formato da saída. Quanto mais capaz, melhor ele acha as frestas.

As três faces são diferentes, mas a raiz é uma. Recolocar no slot de julgamento do loop um LLM — ou seja, o próprio gerador. Quem gera também atribui a aprovação. O aluno corrige a própria prova. O próprio Osmani anotou o ponto fraco — “um loop que roda sem supervisão é também um loop que falha sem supervisão.”

A divergência ainda é sorte

Se até aqui um frio percorreu o seu peito, há uma boa notícia. Divergir é o caso de sorte.

A divergência se vê. Queima tokens, às duas da manhã, explode ruidosamente. Você sabe que aquilo quebrou. Então para, conserta e está lendo este texto.

Agora o lado gelado. Os loops que você acredita terem terminado bem. Aqueles que cuspiram “concluído” na 3ª tentativa e encerraram de forma limpa. Eles sofriam exatamente da mesma doença. Só que mentiram em silêncio.

O modelo bajula. Segue dócil as instruções. Se você pergunta “está pronto?”, responder “sim, está tudo pronto” é o comportamento padrão do modelo. Já é fato medido que a autoverificação quase não melhora o desempenho — o modelo não consegue pegar os próprios erros nas próprias respostas. Então, se você deixa o modelo julgar a própria conclusão, o loop termina errado e confiante. Isso se chama convergência falsa — um encerramento prematuro: parou cedo demais porque declarou a si mesmo “concluído”, não porque chegou à resposta certa.

O loop que divergiu grita com você para que conserte. O loop que convergiu falsamente sorri, entrega o resultado quebrado, e você o coloca em produção sem nem saber que está quebrado. Mais assustadora que a divergência é a convergência que não é flagrada.

Isto é um problema com formato de gate

Então, o que mudar? Um modelo mais esperto? Um prompt mais longo? Mais tentativas? Tudo isso é apenas outra dosagem da mesma doença — enquanto o julgamento continuar entregue ao modelo.

A virada real vem de reenxergar o problema. Você consegue definir o seu “concluído” não como opinião, mas como fato? Não “parece bom”, mas “esta função retorna este valor para esta entrada”, “esta citação existe de fato no original”, “este endpoint devolve 200” — como uma inspeção em que a máquina pode cravar verdadeiro/falso sem o julgamento humano.

Se dá para cravar, encaixe essa inspeção no slot de julgamento do loop. A geração fica com o LLM (pode ser probabilística), mas só o gate determinístico tranca a aprovação. Este é o protocolo central — a autoridade de travar a conclusão pertence apenas à máquina. O modelo, mesmo entrando no verificador, pode levantar suspeita dizendo “olhe de novo”, mas não pode conceder “aprovado”. Assimetria de autoridade. Torna o trabalho errado impossível desde a origem.

E é aqui que a mágica acontece. Quando o gate devolve não aprovado/reprovado, mas fato — “a âncora who não existe no original, conserte aqui” — a bajulação do modelo de repente vira ativo. Para a opinião a bajulação é veneno (diz “está tudo pronto” como mandam), mas para o fato a bajulação é remédio. Quanto mais bajulador o modelo, mais docilmente ele aceita aquele fato e estreita a próxima tentativa. Gate determinístico + LLM bajulador = um loop com convergência garantida. Aquele loop que divergia, ao trocar um único slot de julgamento, se fecha.

O loop não converge sem reins

Eu chamo essa única casa de Reins Engineering — não a cerca que aprisiona a liberdade do agente, mas as rédeas que o conduzem até o destino. Se o Loop Engineering era “projete o loop”, o que faz esse loop convergir é o contrato determinístico encaixado no slot de julgamento. Chame de engenharia de verificadores, de engenharia de avaliação ou de engenharia de gates — a essência é uma. O julgamento do loop é feito pela máquina, não pelo LLM.

Se você quer ver que isto não é abstração e sim código que compila, o reins implementa essa única casa como framework — ratchet (uma vez passado, irreversível), gate (catálogo de regras de defesa anti-queijo) e o comando loop (o LLM gera, o gate julga, ao falhar realimenta o fato e tenta de novo, e ao ultrapassar MaxTries encerra de forma monotônica). O loop infinito das duas da manhã se torna um loop que conhece o seu fim.

Se o seu loop está divergindo agora, a pergunta não é “que modelo usar”. É “o que está travando a minha conclusão”. Se é o modelo que está travando, então ela não está travada.

Relacionados

Leitura complementar

A razão pela qual o loop diverge — deixou o julgamento ao próprio gerador — e a sua receita — colocar a autoridade de travar a conclusão apenas num gate determinístico — não é um diagnóstico só meu. Pessoas que não se conhecem chegaram à mesma conclusão diante do mesmo loop das duas da manhã. Abaixo está a prova dessa convergência independente.

  • ouroboros — “Barra loops infinitos de agente com um gate de convergência matemático.” Antes de começar a codar, um gate de ambiguidade bloqueia a divergência precoce; durante a evolução, julga a convergência pela similaridade entre gerações. Detecta oscilação (ciclos de período 2) como padrão patológico e encerra de forma monotônica com um hard cap de gerações — transpondo para limiares matemáticos a “rotação infinita” deste texto e o término monotônico por MaxTries do loop do reins.
  • proof-loop — “O verificador deve ser uma nova sessão. O agente que fez a mudança não julga se ela terminou.” Congela os critérios de aceitação antes da implementação, separa o construtor do verificador e só encerra quando todos os critérios recebem um novo PASS. Uma separação de autoridade que enfrenta de frente a “convergência falsa” deste texto (o aluno corrige a própria prova).
  • auto-re-agent — Encaixa no loop reverser/checker um objective verifier (inspeção estrutural de call-count e control-flow) e um motor de parity multi-sinal (GREEN/YELLOW/RED). Agrupa as tentativas por um número máximo de rodadas para cortar a divergência. A mesma intuição do gate do reins, em que a regra — e não o julgamento do LLM — tranca a aprovação.

E a linhagem mais ampla deste diagnóstico — episteme, MagLab, Manifesto, oh-my-kamisama — está organizada na “Leitura complementar” do reins. A mesma parede, a mesma conclusão também se enfileiram lá.

Fontes

  • Osmani, A. (2026). “Loop Engineering.” addyosmani.com/blog (2026-06-07). Blog — A origem da tendência “não digite prompts, projete loops”. A fonte original do “um loop que roda sem supervisão falha sem supervisão” citado no texto.
  • Hu, W. (2026). “From Agent Loops to Structured Graphs: A Scheduler-Theoretic Framework for LLM Agent Execution.” arXiv:2604.11378 — Aponta os “unbounded recovery loops” (retentativas infinitas) como fraqueza estrutural do Agent Loop e propõe garantia formal de término. Base da primeira face da divergência, a “rotação infinita”, e do término monotônico.
  • Mohamed, A., Geng, M., Vazirgiannis, M., & Shang, G. (2025). “LLM as a Broken Telephone: Iterative Generation Distorts Information.” arXiv:2502.20258 — Quanto mais o modelo processa repetidamente a própria saída, mais a distorção de informação se acumula gradualmente. Sustenta diretamente a segunda face da divergência, a “deriva” (acúmulo composto de erro).
  • Bondarenko, A. et al. (2025). “Demonstrating Specification Gaming in Reasoning Models.” arXiv:2502.13295 — Quanto mais capaz o modelo de raciocínio, melhor ele acha as frestas da inspeção. Base da terceira face da divergência, o “reward hacking”.
  • Helff, L. et al. (2026). “LLMs Gaming Verifiers: RLVR can Lead to Reward Hacking.” arXiv:2604.15149 — A frequência de shortcuts cresce junto com a complexidade da tarefa e o compute de raciocínio. Base quantitativa de que, sobre verificação frouxa, o reward hacking é proporcional à capacidade.
  • Huang, J. et al. (2024). “Large Language Models Cannot Self-Correct Reasoning Yet.” ICLR 2024. arXiv:2310.01798 — A autocorreção sem feedback externo não melhora o desempenho e até o piora. Base central de “se o modelo julga a própria conclusão, ele termina errado” (convergência falsa).
  • Stechly, K., Valmeekam, K., & Kambhampati, S. (2024). “On the Self-Verification Limitations of Large Language Models.” arXiv:2402.08115 — A autoverificação quase não melhora o desempenho. A razão pela qual o julgamento PASS deve ficar num gate determinístico.
  • Xu, W. et al. (2024). “Pride and Prejudice: LLM Amplifies Self-Bias in Self-Refinement.” arXiv:2402.11436 — Quando o modelo avalia a própria saída, o self-bias é amplificado. Base de que o acoplamento gerador=julgador aumenta a deriva, e justificativa para separar o slot de julgamento.
  • Sharma, M. et al. (2023). “Towards Understanding Sycophancy in Language Models.” arXiv:2310.13548 — A bajulação é uma tendência geral dos modelos RLHF, e o julgamento de preferência humana a induz. Base do comportamento padrão de responder “sim” a “está pronto?”, e dos dois lados em que a bajulação vira ativo no feedback de fatos.
  • Fanous, A. et al. (2025). “SycEval: Evaluating LLM Sycophancy.” AAAI/ACM AIES 2025. arXiv:2502.08177 — Mede a taxa de rendição à bajulação. Base quantitativa do mecanismo de convergência em que “no fato a bajulação é remédio”.
  • Von Neumann, J. (1956). “Probabilistic Logics and the Synthesis of Reliable Organisms from Unreliable Components.” Automata Studies, Princeton University Press. — O princípio de erguer um protocolo confiável (gate determinístico) sobre componentes instáveis (LLM probabilístico). A premissa de “a geração é probabilística, a aprovação é determinística”.