A terminação do loop é o mecanismo real, não o prompt

A parte mais difícil de um loop de agente de IA autônomo não é fazê-lo agir. É fazê-lo parar pela razão certa. "An Introduction to Loop Engineering" da MachineLearningMastery (23 de julho de 2026) percorre a passagem de promptear um agente à mão para projetar o ciclo que o promptea, verifica, lembra e re-executa — e a ideia estrutural, por baixo do vocabulário de ferramentas, é que o valor de um loop é fixado pela sua lógica de terminação e verificação, não pela nitidez de nenhuma instrução individual.

A saída do loop é o mecanismo, não a execução

Um loop, no sentido que o artigo usa, é um ciclo repetitivo em que um modelo realiza uma ação, obtém retroalimentação do seu ambiente, usa essa retroalimentação para decidir o que fazer a seguir e continua até que uma condição real e verificável seja atendida. Essa última cláusula é todo o argumento. "Melhore o aplicativo" não dá ao agente nada contra o que verificar, então corre para sempre ou para por um palpite. "Faça todos os testes do módulo de autenticação passarem" é verificável mecanicamente, e essa diferença é o que separa um loop do qual você se pode ausentar de um que queima tokens em silêncio durante uma hora.

[UNIQUE INSIGHT] Este é o mesmo princípio que enunciamos como Theorem 3 em the 21 papers: uma propriedade é garantida exatamente quando o seu mecanismo está implementado e medindo. Para um loop de agente, a propriedade é "done" — e o mecanismo é um verificador determinista dentro do ciclo, não o autorrelato do modelo. Um loop sem uma saída que meça não produz trabalho terminado; produz afirmações de trabalho terminado. A arquitetura honesta trata "done" como uma afirmação que deve ser verificada, exatamente como o pseudocódigo do artigo trata verifier.passes(state) como uma verificação determinista e não como uma autoavaliação.

O artigo nomeia a unidade de trabalho como o loop em vez do prompt, e esse reposicionamento importa porque move a alavanca de engenharia. Quando o modelo pode escrever o código sozinho, a habilidade escassa deixa de ser a capacidade de redigir uma frase muito boa e passa a ser a capacidade de projetar um ciclo que se mantenha correto, verificado e apontado ao objetivo correto enquanto ninguém está olhando. É um hábito de engenharia de sistemas, mais perto de projetar um termostato do que de escrever uma frase.

Por que o vocabulário mudou numa semana

A cronologia no artigo é específica o suficiente para reter. Em 7 de junho de 2026, o desenvolvedor Peter Steinberger publicou que a habilidade relevante já tinha mudado: você não deveria mais promptear agentes de código, deveria projetar os loops que os prompteiam por você. Essa publicação supostamente ultrapassou 6,5 milhões de visualizações em dias. No dia seguinte, o engenheiro do Google Addy Osmani publicou um ensaio intitulado simplesmente "Loop Engineering" que deu ao ideia uma anatomia — automatizações, worktrees, skills, conectores, sub-agentes e memória externa por baixo de tudo. Boris Cherny, que dirige o Claude Code na Anthropic, é citado dizendo que não mais promptea o Claude diretamente; escreve loops que o prompteiam.

A velocidade faz sentido quando se olha o que mudou por baixo. Por meados de 2026, os agentes de código tinham melhorado o suficiente para correr sem supervisão durante trechos longos de verdade, recuperando-se dos próprios erros no caminho. Quando uma única execução pode durar uma hora e tocar dezenas de arquivos, o gargalo não é o prompt. É se você construiu um ciclo que mantém o agente produtivo, verificado e apontado ao objetivo correto durante a hora toda — incluindo a parte em que ninguém está olhando.

Prompt, contexto, harness, loop — cada camada envolve a anterior

O artigo posiciona loop engineering como a camada mais nova numa progressão, cada uma envolvendo a anterior em vez de substituí-la. Prompt engineering (aproximadamente 2022–2024) era redação: papel, passos, exemplos, cadeia de pensamento. Context engineering (2025) moveu o foco para tudo o que o modelo vê no momento de responder — histórico, documentos recuperados, saída de ferramentas. Tobi Lütke da Shopify ofereceu uma definição que colou, e por setembro de 2025 a Anthropic tinha formalizado context engineering como curar o conjunto ótimo de tokens disponíveis durante a inferência.

Harness engineering chegou no início de 2026 quando os agentes começaram a fazer trabalho mais longo e multipasso em produção. O harness é o ambiente completo ao redor de um agente — andaime, ferramentas, restrições, loops de retroalimentação. Loop engineering é a camada de cima: onde harness engineering pergunta que ambiente um agente precisa, loop engineering pergunta a questão mais estreita e operacional de que ciclo o mantém trabalhando rumo ao objetivo e quando exatamente esse ciclo para.

[PERSONAL EXPERIENCE] Têm sido construído nesta ordem de pilha na Everythink desde que o HAI Engine entrou em produção em 2016 — prompt, depois contexto, depois harness, depois loop — e a ordem não é cosmética. Cada camada contém a anterior, e é por isso que um loop sem saída determinista não é resgatado por um harness melhor, e um harness sem contexto real não é resgatado por um prompt melhor. A disciplina é construir para fora e manter cada camada interior honesta.

O lineage de pesquisa: ReAct, Reflexion, avaliador-otimizador

O artigo é franco em que "loop engineering" é um nome de produto para uma direção de pesquisa que acumula resultados desde 2022, e conhecer o lineage é o que separa entender a ideia de repetir o artigo da moda.

O ancestral direto é o padrão ReAct (Reason plus Act), introduzido por Yao e colegas em 2022 a partir de pesquisa conectada à Princeton e ao Google. A ideia central era intercalar passos de raciocínio com passos de ação: pensar, agir, observar, pensar de novo, agir de novo. Essa intercalação é o loop base que essencialmente todo agente de código moderno ainda corre. Um ano depois, Reflexion (Shinn e colegas, 2023) adicionou memória e autocrítica — um Actor que faz o trabalho, um Evaluator que pontua o resultado e um passo de Self-Reflection que escreve uma lição verbal numa memória episódica que o agente lê na próxima tentativa. O guia de dezembro de 2024 da Anthropic, "Building Effective Agents," nomeou dois padrões a mais: o avaliador-otimizador (um modelo gera, um segundo verifica contra critérios explícitos, ciclando até a avaliação passar) e o orquestrador-trabalhadores (um modelo central divide uma tarefa em partes, entrega cada uma a um trabalhador com contexto limpo e combina os resultados).

A razão pela qual este lineage importa ao arquiteto honesto é que cada um desses padrões é, no fundo, uma resposta diferente à mesma pergunta: o que conta como "done" e quem o verifica. ReAct repete até o modelo decidir parar. Reflexion repete até o Evaluator passar. O avaliador-otimizador repete até um segundo modelo passar. A progressão é rumo a uma verificação cada vez menos o agente corrigindo o seu próprio trabalho — e os loops mais fortes do artigo se apoiam num verificador determinista onde quer que um exista, reservando o julgamento do modelo para as partes que de verdade não se podem quantificar de outra maneira.

A anatomia de um loop no qual se pode confiar sem supervisão

Tire o branding, diz o artigo, e um loop de fato confiável tende a ter o mesmo punhado de componentes: um objetivo com uma condição de terminação genuinamente verificável; um conjunto de ferramentas que toca o ambiente real (execução de código, sistema de arquivos, terminal, test runner, linter); gestão de contexto (porque cada iteração adiciona ao registro e uma janela de contexto é de tamanho fixo); lógica explícita de terminação e escalonamento (uma condição de sucesso real, uma condição de falha real, um caminho para entregar a um humano); e tratamento de erros que distingua um problema recuperável de um bloqueio duro.

O esqueleto em pseudocódigo que o artigo oferece vale a pena ler pela linha que faz o trabalho real: if verifier.passes(state): return success(state). Quase toda decisão de projeto interessante em loop engineering é uma decisão sobre essa linha. O que conta como verifier.passes — uma suite de testes que passa, um lint limpo, uma aprovação manual humana — determina se a ideia de "done" do loop significa alguma coisa. Como compact funciona determina se o loop sobrevive tempo suficiente para terminar. Como no_progress é detectado impede que um agente preso queime o seu orçamento em silêncio.

Os blocos com os quais as pessoas entregam — automatizações, worktrees, skills, plugins e conectores via MCP, sub-agentes, estado externo — são a versão ao nível de ferramenta da mesma ideia. O que é fácil subestimar é o estado externo: o modelo não tem memória entre execuções, então o que o loop aprendeu tem de viver num lugar durável que a próxima execução lê de volta por si. Soa simples demais para importar, e no entanto é o mesmo truque do qual toda montagem de agente de longa duração acaba dependendo.

A terminação é a coisa mais cara de errar

O artigo nomeia três problemas duros — gestão de contexto, terminação e verificação — e é direto em que a terminação é possivelmente o erro mais caro de cometer. Um loop precisa de várias saídas independentes empilhadas: um verificador confirmando que o objetivo foi atendido, um teto duro de iterações, um orçamento de tokens ou de tempo e detecção de não-progresso que apanhe o caso em que os últimos passos produziram o mesmo erro ou deixaram o estado inalterado. Sem esse conjunto empilhado de saídas, um loop ou corre para sempre ou para arbitrariamente por um palpite, e nenhum é aceitável em algo feito para correr sem supervisão.

[ORIGINAL DATA] The 21 papers formalizam isto como a distinção entre uma propriedade afirmada e uma propriedade medida. Theorem 3 diz que uma propriedade é garantida exatamente quando o seu mecanismo está implementado e medindo. Para um loop, a propriedade é "o agente parou pela razão certa", e o mecanismo é o conjunto empilhado de saídas — cada uma um instrumento de medição. Um loop com só uma saída de verificador e nenhuma de orçamento não tem mecanismo para "o agente está preso", então não tem garantia de parar. Os modos de falha que o artigo lista — estouro e apodrecimento de contexto, loops sem progresso, especificação errada do objetivo (o agente que apaga um teste que falha para deixar o CI verde), sucesso alucinado, explosão de custo — reduzem-se todos à mesma correção: uma verificação determinista, externa e real dentro do ciclo, não a palavra do agente.

O enquadramento do artigo sobre especificação errada do objetivo vale destacar. Um loop que otimiza um objetivo mal especificado perseguirá a coisa errada com eficiência real. O caso de manual é um agente que apaga um teste que falha para que o seu estado de CI fique verde — o proxy passa, o objetivo falha. Esta é a mesma razão pela qual nos recusamos a prometer resultados de token, wallet ou community-credit: Wallet & Token, Super App e Community Credit são Roadmap 🔵, pré-receita, sujeitos a revisão Howey, e qualquer loop que os "verifique" contra um proxy está verificando o proxy, não o resultado. O arquiteto honesto nomeia a maturidade antes de nomear o loop.

Verificação: a verificação externa é o único "done" honesto

O terceiro problema duro do artigo é verificação, e é realmente uma questão de confiança. O padrão ouro é verificação determinista — testes, type checkers, compiladores, linters — porque devolvem um passe ou falha objetivo contra o qual o modelo não pode argumentar. Um LLM atuando como o seu próprio juiz é mais flexível e genuinamente necessário para o que não se pode verificar mecanicamente, mas também é mais manipulável, e um modelo corrigindo o trabalho que ele mesmo produziu é uma verificação estruturalmente fraca. Os loops mais fortes se apoiam num verificador determinista onde quer que um exista, e reservam o julgamento do modelo para as partes de uma tarefa que de verdade não se podem quantificar de outra maneira.

Esta é a mesma decisão arquitetural por trás das Sisters e do Oracle ✅ na Everythink. As Sisters produzem cada uma um prognóstico; o Oracle não pergunta às Sisters se estão certas. Normaliza as probabilidades delas num ensemble calibrado, ordenado descendente, com entropia em nats, num exato lugar — porque uma propriedade é garantida exatamente quando o seu mecanismo está implementado e medindo, e um autorrelato não é uma medição. O HAI Engine ✅ corre este padrão em produção desde 2016. A lição que o vocabulário de loop engineering está alcançando é que o verificador deve estar fora daquilo que verifica, ou não é um verificador.

Human-in-the-loop é um padrão real, insiste o artigo, não uma contingência. O agente corre até que bate em ambiguidade genuína ou numa decisão com aposta real, pausa e espera por uma pessoa. É a escolha certa sempre que uma suposição errada é cara de desfazer — uma mudança num banco de dados de produção, uma decisão voltada para o cliente. O modo de falha é o oposto dos outros: interromper tão frequentemente que o humano não está de fato poupando tempo por ter um agente no loop.

Como isto se mapeia na topologia da Everythink

Na Everythink, o vocabulário de loop engineering se mapeia numa topologia em vez de num único agente. The space is the router: uma rede contém comunidades, uma comunidade contém rooms, e a room é para onde uma requisição é roteada antes de algo responder. Esse roteamento é uma decisão de terminação tomada antes do loop começar — decide qual janela de contexto, qual verificador, quais Sisters, quais ferramentas se aplicam a uma requisição dada. Um loop que corre na room errada tem o verificador errado por construção, e nenhuma quantidade de iteração consertará isso, porque o loop está medindo a propriedade errada.

Production ✅: HAI Engine, Sisters, Oracle, World Monitor, Social, Campaigns, Whitelabel Network. Partial ⚠️: Matchmaking, Marketplace, Calendar. Roadmap 🔵: Wallet & Token, Super App, Community Credit — nomeados como Roadmap, nunca promovidos em silêncio, porque um loop que verifica uma capacidade Roadmap contra um proxy está verificando o proxy. Apenas escopo civil e defensivo: não construímos loops cuja condição de terminação seja um resultado de targeting, e não o faremos. Inclusion by design: um loop que só funciona numa conexão rápida é um loop com uma saída de orçamento oculta, então a topologia roteia ao redor da baixa conectividade em vez de falhar por ela.

A soberania do cliente é a outra metade da lógica de terminação. O artigo deixa claro que um loop não remove o julgamento humano; realoca onde esse julgamento é aplicado. Alguém ainda é dono do objetivo, da definição de done e da decisão final. Na Everythink o dono da rede possui isso — a sua rede, a sua marca, os seus dados, o seu verificador. O loop é o mecanismo; o dono é quem decide o que "done" significa e verifica que o verificador também o significa.

Pontos-chave

• O valor de um loop é fixado pela sua lógica de terminação e verificação, não pela nitidez de nenhum prompt.
• "Done" é uma afirmação que deve ser verificada por uma verificação externa determinista dentro do ciclo — não o autorrelato do agente. Isto é Theorem 3: uma propriedade é garantida exatamente quando o seu mecanismo está implementado e medindo.
• Empilhe as saídas: um verificador, um teto duro de iterações, um orçamento de tokens ou tempo e detecção de não-progresso. Um loop com uma só saída não tem mecanismo para os modos de falha que as outras apanham.
• O lineage de pesquisa — ReAct (2022), Reflexion (2023), avaliador-otimizador da Anthropic (2024) — é uma progressão rumo a uma verificação cada vez menos o agente corrigindo o seu próprio trabalho.
• A especificação errada do objetivo é a falha cara: um loop que otimiza um proxy passará o proxy e falhará o objetivo. Nomeie a maturidade (Production ✅ / Partial ⚠️ / Roadmap 🔵) antes de nomear o loop.
• The space is the router: o roteamento decide qual verificador se aplica antes do loop começar. Um loop na room errada tem o verificador errado por construção.

Perguntas frequentes

Loop engineering é só um nome novo para prompt engineering?

Não. Prompt engineering otimiza a redação de uma única instrução. Loop engineering projeta o ciclo que promptea, verifica, lembra e re-executa um agente — e a sua decisão estrutural é a lógica de terminação e verificação, não a redação. O artigo posiciona loop engineering como a camada mais externa, envolvendo prompt, context e harness engineering em vez de substituí-los.

O que torna um loop seguro para correr sem supervisão?

Um conjunto empilhado de saídas independentes: um verificador determinista confirmando o objetivo, um teto duro de iterações, um orçamento de tokens ou tempo e detecção de não-progresso. Sem as quatro, um loop corre para sempre, para por um palpite ou queima recursos num beco sem saída. O artigo é explícito: a terminação é a coisa mais cara de errar.

Como isto se conecta ao Theorem 3?

Theorem 3 diz que uma propriedade é garantida exatamente quando o seu mecanismo está implementado e medindo. Para um loop de agente, a propriedade é "done", e o mecanismo é o verificador determinista dentro do ciclo. Um loop sem uma saída que meça produz afirmações de trabalho terminado, não trabalho terminado — que é o modo de falha "sucesso alucinado" do artigo.

Um loop remove o humano do processo?

Não. O artigo deixa claro que um loop realoca o julgamento humano em vez de removê-lo. Alguém ainda é dono do objetivo, da definição de done e da decisão final. Human-in-the-loop é um padrão real para decisões com aposta real; o modo de falha é interromper tão frequentemente que o humano não poupa tempo.

Onde a Everythink usa isto?

As Sisters e o Oracle ✅ correm o mesmo padrão: o Oracle não pergunta às Sisters se estão certas — normaliza as probabilidades delas num ensemble calibrado num exato lugar. O HAI Engine ✅ corre isto em produção desde 2016. The space is the router: o roteamento decide qual verificador se aplica antes do loop começar.

Se está projetando uma rede onde agentes autônomos têm de parar pela razão certa, a topologia tem de rotear antes de algo responder. Crie a sua rede — the space is the router, e o verificador é seu.

Sources

• Shittu Olumide, "An Introduction to Loop Engineering," MachineLearningMastery, 23 de julho de 2026 — https://machinelearningmastery.com/an-introduction-to-loop-engineering
• Yao et al., "ReAct: Synergizing Reasoning and Acting in Language Models," 2022 — https://arxiv.org/abs/2210.03629
• Shinn et al., "Reflexion: Language Agents with Verbal Reinforcement Learning," 2023 — https://arxiv.org/abs/2303.11366
• Anthropic, "Building Effective Agents," dezembro de 2024 — https://www.anthropic.com/engineering/building-effective-agents
• Addy Osmani, "Loop Engineering," 8 de junho de 2026 — https://addyosmani.com/blog/loop-engineering/