5 Agent Loops no Claude Code que deixam agentes trabalhando por dias

Passei as últimas semanas recriando cada tipo de agent loop que encontrei por aí, plugando no meu Claude Code e rodando em projetos de verdade. O resultado foi meio absurdo: deixei agentes trabalhando sozinhos por dias em bases extensas e voltei pra ver features prontas, testadas e revisadas sem tocar numa linha. Não é mágica nem hype pra vender token — é engenharia de loop. E a maioria das pessoas usa o loop errado pra tarefa errada, queima crédito à toa e conclui que “não funciona”. Deixa eu te mostrar os 5 padrões que de verdade mudaram meu jeito de construir.

O que é um agent loop — e o erro que quase todo mundo comete

Loop engineering é quando você para de ser a pessoa que escreve os prompts que dirigem o agente e vira quem monta o sistema que escreve o próprio loop. Em vez de ficar estruturando prompt gigante toda vez, o agente aprende enquanto trabalha, cresce a partir dos erros que bate pelo caminho e decide sozinho qual o próximo passo. Na minha visão, é a fronteira mais subestimada do momento. Todo loop cai em duas famílias: o determinístico, onde você já sabe o resultado esperado e o agente tem como conferir o próprio trabalho contra ele; e o não-determinístico, onde não existe gabarito e você precisa de outras táticas pra manter o agente no trilho. Escolher a família errada é o que faz o loop rodar em círculo e torrar token. Se você quer o mapa completo de abstração antes de entrar nos padrões, eu já destrinchei isso em Loop Engineering: os 4 níveis de abstração.

Loop 1 — Stateless: o bloco de construção (Ralph e o goal)

O stateless é o loop mais simples que existe e a base de todos os outros. Ele não guarda memória nem se melhora enquanto trabalha — roda a mesma tarefa de novo e de novo até enxergar que terminou, e para. O exemplo clássico é o Ralph loop, e no Claude Code o comando goal é a melhor cara disso: você diz o que quer construir, o Claude fixa aquilo como meta e trabalha. Cada vez que o agente principal acha que a tarefa acabou, um modelo menor — o Haiku, no Claude Code — confere tudo contra os requisitos que você deu e reprompta se faltou algo. O problema é que ele depende inteiro do modelo pra decidir se acabou, sem um padrão duro de medida.

Por isso ele brilha quando os requisitos dão pra checar de forma concreta. Na prática, eu escrevo os testes antes de pedir a feature: aí o goal vira “faça passar todos os testes”, o agente escreve código, roda os testes, se corrige e só marca como concluído quando tudo verde. Um detalhe que salva: uma linha no CLAUDE.md mandando salvar toda versão funcional do app. Se ele quebrar algo lá na frente, volta pra última versão que funcionava em vez de tentar desfazer mudança de memória. Eu mostrei variações práticas desse padrão em 4 Padrões de Loops no Claude Code.

Loop 2 — Learning loop: a skill que aprende sozinha

Aqui a coisa vira o oposto do stateless. Em vez de terminar a tarefa e parar, o learning loop foca em melhorar algo que você vai reusar — uma skill ou um workflow. Ele roda a skill, observa como ela se saiu e a melhora com base no que aprendeu, guardando um registro de cada lição. O coração disso é um arquivo learning.md que mora dentro da própria skill: um diário de melhoria que documenta o que foi tentado, o resultado com e sem a skill, e as lições de cada rodada. Eu montei um comando que chama um agente “skill improver” e fica chamando ele até não sobrar melhoria nenhuma — e o truque mais esperto é rodar a implementação de dois jeitos, com a skill e sem a skill, pra medir o impacto real dela.

Foi assim que várias das minhas skills pararam de ser “ok” e viraram afiadas. Aliás, é exatamente esse arsenal de skills e loops que eu abri só pra galera das minhas comunidades: se quiser as minhas, entra no meu grupo no WhatsApp e me pede acesso ao repositório.

Loop 3 — Multi-agent: um conselho que revisa por dimensão

Um review nunca é sobre um aspecto só. Quando um único agente revisor tenta cobrir tudo, ele deixa buraco. A sacada é dividir a revisão entre vários agentes, cada um numa dimensão — ideia parecida com o LLM Council que o Andrej Karpathy soltou, um conselho de agentes que discutem entre si até chegar na resposta certa. No loop que montei tem quatro: um checa correção factual (com web search pra se ancorar em fonte real), um domain checker que vê se aquilo é relevante pro que a gente quer, um safety critic que olha conteúdo sensível, risco de segurança e violação de política, e um style critic que garante clareza e o tom certo. O que amarra os quatro é um comando orchestrate que coordena os agentes rodada a rodada: o agente principal aplica os fixes da rodada um, sobe todos de novo pra rodada dois, e no fim você tem o app num estado muito melhor. Serve pra qualquer coisa, código ou não.

Loop 4 — Verification loop: implementador contra juiz

Esse usa dois agentes como jogadores: um implementa e o outro dá nota. O trabalho do implementador é uma coisa só — subir a nota o mais alto possível contra uma métrica que você definiu. O reviewer não tem ferramenta de edição; ele só lê e pontua. É o mesmo espírito do thermonuclear review do Cursor, uma skill de review que audita o código inteiro e devolve um parecer com padrões inegociáveis. Pra cobrir tantas categorias, ele roda um dynamic workflow que espalha o trabalho entre vários subagentes ao mesmo tempo — o que é poderoso, mas custa caro: demora e queima muito token.

Eu só recomendo esse quando o app já está grande e você quer uma revisão pente-fino de verdade; pra caso comum, dá pra montar o mesmo loop com um reviewer normal e gastar uma fração. Se quiser entender o motor por trás desse fan-out, eu expliquei os dynamic workflows em Dynamic Workflows no Claude Code.

Loop 5 — Workflow improvement: o loop que conserta o próprio loop

Nenhum dos quatro anteriores tinha um passo pra melhorar o loop em si — e isso, pra mim, é o coração do que um loop deveria fazer. O workflow improvement loop vai além de repetir a tarefa: ele olha pro próprio processo e sugere como melhorá-lo. Cuidado pra não confundir com o learning loop: aquele melhora uma skill, uma peça de dentro do processo; este melhora o processo inteiro. O ponto de entrada é um comando iterate que orquestra tudo, com três agentes: um builder que entrega um requisito do app por rodada, um scorer que avalia contra uma rubrica e dá nota de 0 a 100 como guard rail de qualidade, e um process optimizer que é quem de fato faz a auto-melhoria — depois de planejar, implementar e verificar, ele volta na iteração e sugere como deixá-la melhor. Você roda iterate all e no fim não sai só com o app pronto: sai com um workflow testado e refinado, onde cada passo foi validado como um passo que precisava mesmo existir. Foi esse tipo de loop que me deixou confortável em largar o agente rodando por dias.

Conclusão

Se eu tivesse que resumir o que aprendi recriando esses cinco: (1) loop não é gasto de token, é alavanca — o desperdício vem de usar o loop errado pra tarefa errada; (2) o pulo do gato quase sempre é dar ao agente um jeito concreto de conferir o próprio trabalho, seja teste, rubrica ou um segundo agente juiz; (3) o loop que mais compõe valor no longo prazo é o que melhora a si mesmo, porque ele paga dividendo em todo projeto seguinte.

Eu recriei cada uma dessas skills, testei em projeto real e empacotei tudo num repositório que deixei exclusivo pras minhas comunidades. Se você quer sair do prompt-a-prompt e botar agente pra trabalhar sozinho de verdade, entra no meu grupo do WhatsApp e me pede o acesso ao repositório — é lá que eu libero as skills e respondo quem está construindo junto.