Loop Engineering: os Tipos de Loop que Fazem Agentes de IA Trabalharem Sozinhos

“Loop engineering” é o termo usado para descrever uma mudança fundamental de arquitetura: em vez de enviar prompts manuais e aguardar respostas isoladas, criam-se ciclos iterativos onde o próprio agente de IA executa, avalia o resultado contra regras predefinidas e corrige a si mesmo até atingir a condição de parada.

Vale destacar que este artigo foca exclusivamente nos aspectos técnicos e na lógica de implementação de cada abordagem, separando o método prático de qualquer oferta comercial.

A anatomia de um loop: gerador, verificador, critério de parada

Antes de chegar aos tipos, vale entender a peça que sustenta qualquer um deles. No vídeo “Engenharia de Loop: faça a IA trabalhar SOZINHA”, Anwar Hermuche descreve a estrutura mínima de um loop agêntico em três partes: um gerador, que escreve o código ou o texto; um verificador, que avalia se aquilo está de acordo com o que foi pedido; e um critério de parada, a decisão booleana (sim ou não) que encerra o ciclo ou manda ele rodar de novo.

É essa terceira peça, o critério de parada, que Anwar usa para separar os quatro tipos de loop que ele descreve na aula, cada um com uma forma diferente de decidir quando parar:

Loop por turno: o modelo interage no formato de chat padrão e é o próprio modelo quem decide quando a interação terminou. É o loop “default” de qualquer conversa com um agente.
Loop por meta (comando /go): o agente itera até bater uma métrica quantitativa explícita, por exemplo uma pontuação de Lighthouse acima de 90, ou até esgotar um teto de tentativas definido antes de começar.
Loop por tempo (comandos /loop e /schedule): a execução se repete em intervalos fixos. /loop roda localmente, com a máquina ligada, por até 7 dias seguidos; /schedule roda na nuvem da própria Anthropic, sem depender de uma máquina local ligada.
Loop proativo: disparado por um evento externo (um webhook, uma mensagem no Slack, um e-mail), que por sua vez pode acionar sub-loops de resolução automática.

Um ponto central do vídeo é sobre o custo de não verificar: segundo Anwar, a probabilidade acumulada de falha num loop não supervisionado cresce de forma exponencial com o número de iterações, saindo de cerca de 15% de chance de erro numa única rodada para mais de 96% depois de 20 rodadas sem checagem. É o argumento central para por que o verificador não é opcional: sem ele, deixar um loop rodar sozinho por muitas iterações é, na prática, apostar que ele vai acumular erro.

O caso Bun: 535 mil linhas, 50 workflows, 11 dias

O exemplo que Anwar usa para mostrar o que um loop bem verificado permite em escala é a reescrita do runtime Bun, que trocou 535.000 linhas de código de Zig para Rust usando 50 workflows dinâmicos no Claude Code, ao longo de 11 dias, a um custo total de 65 mil dólares. O detalhe mais específico do caso, e o que melhor ilustra o papel do verificador: a etapa de leitura e verificação do código consumiu 113 vezes mais tokens que a etapa de escrita, 78 bilhões de tokens de leitura contra 690 milhões de tokens de escrita. Na prática, a maior parte do custo de um loop de produção não está em gerar a mudança, está em confirmar que ela está certa.

Bruno Okamoto: o quarto loop, o que aprende com o próprio erro

Em “Meus agentes aprendem sozinhos. Eu só gravo a lição”, Bruno Okamoto apresenta o que chama de Quarto Loop, o Loop de Autoaprendizado (Self-Learning Loop): um ciclo que não apenas executa e verifica, mas retroalimenta a base de regras e a memória do próprio agente a partir do resultado. Diferente da aula de Anwar, que classifica tipos de loop pelo critério de parada, Bruno organiza a apresentação em três níveis de onde vem o feedback que alimenta esse aprendizado.

Nível 1, feedback humano (Amora): um agente executivo pessoal, no papel de Chief of Staff. Erros que o agente comete são corrigidos pelo próprio usuário e ficam registrados num arquivo chamado lessons_learned.md. A regra específica que Bruno descreve: quando um mesmo erro se repete três vezes, ele é promovido de anotação para regra inegociável permanente, incorporada diretamente ao system prompt (a “alma”, ou SOUL, do agente).

Nível 2, feedback do mercado (Leonardo da Vinci): um agente gestor de tráfego pago, conectado à API da Meta. Ele analisa métricas reais de criativos (ROAS, retenção, taxa de cliques), extrai os ganchos e ângulos que performaram melhor, e gera semanalmente entre 50 e 90 novas variações de anúncios com base no que efetivamente gerou receita.

Nível 3, feedback da própria performance (Dexter): um agente de inteligência de conteúdo que monitora benchmarks no YouTube e no X, sintetiza tendências, produz roteiros e carrosséis, e tira snapshots diários das métricas dos vídeos publicados ao longo de 7 dias para recalibrar o modelo editorial.

A infraestrutura que Bruno recomenda para rodar esse tipo de operação: um VPS Linux KVM2 na Hostinger, com 2 GB de RAM por agente, operando 24 horas por dia.

Vale notar a diferença de enfoque entre os dois criadores: o quarto tipo de Anwar é o loop proativo (o agente que age sem gatilho direto do usuário); o quarto nível de Bruno é o loop de autoaprendizado (o agente que melhora com base no próprio histórico de erros e resultados). São conceitos diferentes, tratando de eixos diferentes do mesmo problema, cada criador batizando o próprio quarto tipo. Isso reforça que “loop engineering” ainda não tem uma taxonomia única consolidada entre quem produz conteúdo sobre o tema, e sim abordagens complementares.

O estudo de caso: uma “empresa” de 5 agentes, em duas partes

Os outros dois vídeos do lote são, na prática, um único tutorial dividido em duas partes pelo mesmo canal (José Carlos Amorim), sobre o Hermes Agent.

Parte 1: a arquitetura (“Hermes Agent não é um agente de IA. É um sistema”). José Carlos desconstrói a visão de que o Hermes Agent é um assistente isolado: ele é, segundo o vídeo, um sistema operacional multiagente completo pensado para o que chama de One-Person Agentic Business, uma empresa de uma pessoa só rodada por agentes. A unidade central da arquitetura é o Profile (perfil): cada perfil tem seu próprio modelo de LLM, memória persistente, skills (SOPs, procedimentos operacionais padrão), rotinas agendadas (cron jobs) e múltiplos gateways de comunicação simultâneos, entre eles Telegram, WhatsApp, Discord, Slack e e-mail.

Um detalhe específico da arquitetura: dentro do Telegram, um único perfil pode se conectar a um grupo estruturado em tópicos (por exemplo LinkedIn, X, Métricas, Geral), e cada tópico roda regras e system prompts distintos, mesmo compartilhando o mesmo contexto de perfil. A operação inteira é coordenada por um quadro Kanban de agentes, onde agentes de marketing, comercial, pedagógico e suporte trocam tarefas e métricas entre si, sem intervenção humana constante.

Parte 2: a instalação (“Como criar 5 agentes de IA que trabalham sozinhos (passo a passo)”). Aqui o vídeo mostra a montagem completa de uma empresa virtual de 5 agentes autônomos no Hermes Agent, passo a passo:

Infraestrutura provisionada num VPS na nuvem da Hostinger, com autenticação do ChatGPT/Codex feita por código de dispositivo.
Criação de 5 bots no Telegram via BotFather, um para cada área: Performance, Pedagógico, CS, Comercial e Conteúdo.
Configuração dos perfis pela CLI do Hermes (comando hermes profile list), com scripts de inicialização persistente que tratam o caso de reinicialização do servidor.
Organização no Telegram numa pasta chamada “Empresa”, com grupos dedicados a cada setor, cada um com o respectivo bot como administrador.
Integração com o Notion via API (variável NOTION_API_KEY), usada para ler logs de alunos e relatórios de atendimento.
Rotinas autônomas (cron jobs) disparadas a cada 2 minutos ou diariamente, para auditar acessos, identificar alunos em risco de evasão e registrar alertas nos canais do Telegram e em tabelas do Notion.

Dos quatro vídeos, esse é o que melhor materializa a ideia de loop em produção: não é uma definição teórica de tipo de loop, é uma rotina cron concreta, com intervalo definido, gatilho definido e ação de saída definida (alerta no Telegram, registro no Notion).

O que os quatro vídeos têm em comum

Juntando os quatro: um loop de produção real combina uma condição que define quando parar (seja meta, tempo, turno ou evento), algum mecanismo de checagem do resultado antes de aceitar a tarefa como concluída, e, na versão mais madura descrita por Bruno Okamoto, algum tipo de aprendizado que retroalimenta a próxima rodada. Os quatro criadores concordam, ainda que com vocabulários diferentes, que um agente que só responde quando perguntado, sem esse ciclo de verificação e repetição, não é o que eles chamam de “loop”.

Fontes

“Engenharia de Loop: faça a IA trabalhar SOZINHA (explicada por quem trabalha com IA há 6 anos)” — Anwar Hermuche | Engenheiro de IA
“Hermes Agent não é um agente de IA. É um sistema” — José Carlos Amorim
“Meus agentes aprendem sozinhos. Eu só gravo a lição.” — Bruno Okamoto
“Como criar 5 agentes de IA que trabalham sozinhos (passo a passo)” — José Carlos Amorim