Agent loops: fazendo o Claude Code se corrigir sozinho

Um agente de IA trabalhando sozinho, que cria, confere o próprio trabalho, encontra os erros e corrige, repetindo esse ciclo até chegar no resultado definido. Boris Cherney, criador do Claude Code, chegou a dizer em um podcast que "loops são o futuro". Mas será que isso é produtividade de verdade ou só mais um hype? Neste post explico o que são os agent loops, como funcionam na prática e quando realmente vale a pena usar.

O que é um agent loop

Esquece o nome técnico por um segundo, porque a ideia é mais simples do que parece, e é algo que você provavelmente já faz todo dia usando IA. Pensa na última vez que você pediu algo pra uma IA e ela entregou um resultado que não ficou tão bom. Você pediu de novo, corrigiu um detalhe, ainda não ficou do jeito certo, pediu mais uma vez, até sair bom. Um agent loop é exatamente esse vai e volta, só que sem você no meio.

Você dá a tarefa uma única vez, explica o que seria um resultado aceitável, e a IA fica refazendo, conferindo e melhorando sozinha quantas vezes precisar até chegar lá. É isso que a palavra loop quer dizer: um ciclo que se repete. O agente faz, confere o que fez, e se ainda não estiver bom, faz de novo.

Isso também deu origem ao termo "loop engineering". Hoje, quem olha o resultado e aponta os problemas é você, o revisor do trabalho. Fazer loop engineering é sair desse papel: em vez de ser a pessoa que corrige a IA, você vira a pessoa que desenha o sistema onde a IA se corrige sozinha.

Os dois pilares de um loop que funciona

Para um loop funcionar bem, ele precisa se apoiar em dois pilares.

Objetivo. Responde o que o agente precisa alcançar, e quanto mais claro e concreto, melhor. Pedir "cria um CRM" é muito aberto. Já pedir "cria um CRM com tela de login, recuperação de senha e um kanban onde eu consigo mover os leads entre colunas como novo, atendimento, negociação e fechado" dá uma direção muito mais clara.

Verificação. Responde duas coisas: o que significa a tarefa estar pronta, e como conferir se o agente realmente atingiu esse critério. No exemplo do CRM, a tarefa só estaria pronta se a tela de login funcionasse, a recuperação de senha existisse, o kanban permitisse mover os cards entre colunas e a aplicação rodasse sem erro.

Sem objetivo, o agente não sabe o que construir. Sem verificação, ele não sabe dizer se aquilo que construiu realmente funciona. Quando as duas coisas estão bem definidas, o loop passa a fazer sentido: o agente executa, verifica, corrige e repete até atingir o critério de conclusão ou até o limite de rodadas definido.

Esse limite de rodadas é importante: você diz no próprio pedido o número máximo de tentativas, algo como "tente no máximo oito vezes". Se o objetivo for atingido antes disso, ótimo, ele para ali. Se chegar na oitava rodada sem atingir, ele para do mesmo jeito e entrega a melhor versão conseguida. Isso garante que o loop nunca fique rodando pra sempre nem gastando mais token do que o planejado.

O motivo disso funcionar bem é que a IA quase nunca acerta de primeira aquilo que você pede. Na primeira tentativa, ela entrega algo em torno de 50% da qualidade desejada, e quem sobe esse degrau até o resultado final é o feedback, melhorando 5 a 10% a cada correção, até chegar em 90-95%. A sacada do loop é justamente terceirizar essa interação, que vai acontecer de qualquer maneira, para o próprio agente. Esse ciclo tem três passos: raciocinar, agir e verificar. Você entrega o objetivo, ele decide o próximo passo, executa, confere o próprio trabalho, ajusta o que encontrou de errado, e só volta pra avisar quando estiver pronto.

Os três formatos de loop

Loop solo. O mais simples e provavelmente o mais usado no dia a dia. Um único agente trabalhando em ciclo: raciocina, executa, verifica o próprio trabalho e, se não bateu com os critérios, corrige e tenta de novo. Na prática, isso se ativa com um bom prompt, por exemplo: "crie uma tela de login, depois teste se ela abre sem erro, verifique se o formulário funciona, corrija qualquer problema encontrado, repita esse processo até funcionar, no máximo quatro iterações". O prompt bem escrito não morreu, ele continua sendo a base.

Maker e checker. Aqui os papéis são separados em dois agentes. Um é o criador (maker), que executa a tarefa. O outro é o corretor (checker), que avalia o que foi feito, dá feedback, aponta problemas e diz o que precisa melhorar. Por exemplo: um agente cria uma landing page, o segundo avalia essa página contra os critérios definidos, e se não passar, devolve feedback para o criador fazer uma nova versão.

Gerente e ajudantes (orquestrador com subagentes). O formato mais parecido com uma equipe: um agente principal organiza o trabalho e distribui partes para ajudantes especializados. Num CRM, por exemplo, um ajudante cuida da estrutura técnica, outro do front-end, outro da experiência do usuário. O gerente junta tudo, revisa os critérios finais e decide se precisa de mais uma iteração. É o formato mais poderoso, mas também o mais fácil de exagerar e queimar token sem necessidade.

Um exemplo real: escolhendo a thumbnail de um vídeo

Um uso prático do formato maker e checker foi na criação de opções de thumbnail para um vídeo. O prompt definia a estrutura desejada, dimensões, objetivo, etapas obrigatórias, o papel de cada agente (um criando as versões, outro avaliando) e critérios objetivos de aprovação: média geral maior ou igual a 8,5, nenhum critério individual abaixo de 7, e um limite de oito iterações.

Com base nisso, o processo gerou sete versões, com o checker reprovando algumas por não atingir os critérios (explicando o motivo em cada rodada) e aprovando a versão final, com o histórico completo de decisões, notas por versão e o que mudou entre elas registrado num arquivo de análise. Dividir a tarefa em dois agentes ajuda bastante quando o critério de avaliação é subjetivo, como qualidade visual de uma thumbnail: o checker força esse julgamento subjetivo a virar critérios mais objetivos e mensuráveis.

Checklist antes de montar um loop

1. Objetivo verificável. Quanto mais objetivo o critério, melhor o loop funciona.
2. Trava de segurança. Sempre defina um teto máximo de iterações, para não ser surpreendido por um loop gastando token indefinidamente.
3. Ferramentas de verificação disponíveis. O agente precisa conseguir conferir o próprio trabalho, seja tirando screenshot, rodando teste, checando texto ou fluxo. Cada tarefa pede um tipo de verificação diferente, e é responsabilidade de quem monta o loop garantir que essa ferramenta exista.
4. Separar criador e avaliador quando o critério for subjetivo. Se definir "isso está bom" depende de julgamento, divida em dois agentes: um cria, outro avalia com mais rigor.
5. A conta precisa fechar. Um loop de 40 minutos que economiza uma tarde vale a pena. Um loop de três dias para uma tarefa que levaria uma ou duas horas fazendo você mesmo as correções não vale, por mais sofisticado que pareça.

Quando realmente vale a pena usar

Sempre que alguém disser "isso é o futuro, se você não fizer assim está ficando pra trás, o prompt morreu, agora é tudo loop", vale um pé atrás, não porque a pessoa esteja errada, mas porque o contexto importa. Às vezes quem fala isso é alguém trabalhando numa base de código gigante, com equipe grande, vários produtos e muita demanda simultânea. Nesse cenário, uma arquitetura mais complexa faz sentido, mesmo custando mais.

Já em projetos menores, como landing pages, organização de conteúdo, automações, CRMs para clientes ou aprender a usar o Claude Code melhor, um exército de agentes rodando o tempo todo raramente é necessário. É como colocar uma Ferrari pra rodar numa rua cheia de buraco e lombada: toda aquela potência não melhora a experiência ali, e pode até piorar.

A pergunta certa não é "qual é a arquitetura mais avançada que eu consigo montar", e sim "qual é a estrutura mais simples que resolve bem esse problema". Na maioria das vezes, a resposta é um loop solo bem feito: um agente, um objetivo claro, critério de conclusão, forma de verificação e limite de iterações. Isso já eleva bastante o resultado sem aumentar complexidade e custo à toa. Usar IA de forma profissional não é colocar o máximo de agentes possível trabalhando, é desenhar o processo certo para o tamanho do problema que você tem.