O que é loop engineering e quando deixar um agente de IA em loop

De onde veio o termo, e por que ele ainda é informal

O nome apareceu em junho de 2026, entre usuários de agentes de código. Em 7 de junho, Addy Osmani publicou um texto que define loop engineering como deixar de ser a pessoa que dá o próximo comando ao agente e passar a desenhar o sistema que faz isso, e credita a mudança a falas de Peter Steinberger e Boris Cherny.

No fim do mesmo mês, o blog do Claude, da Anthropic, abriu um guia de loops dizendo que se fala muito em loop engineering, ou em desenhar loops em vez de escrever prompts, e definiu loops como agentes que repetem ciclos de trabalho até cumprir uma condição de parada.

Não há definição oficial, e o termo se sobrepõe a outros: Osmani coloca o loop um andar acima do harness, e a LangChain trata loop engineering como uma versão simples de um grafo. O que vale levar é a prática por trás do nome.

O loop dentro do agente e os loops em volta dele

Todo agente já roda um loop interno: reúne contexto, age com uma ferramenta, verifica o resultado e repete até não ter mais o que fazer. No Claude Agent SDK, cada volta é um turno, e o loop termina quando o modelo responde sem pedir ferramenta. Loop engineering trata sobretudo dos loops de fora, que decidem quando esse ciclo começa de novo.

No /goal, a cada vez que o agente tenta parar, outro modelo confere a condição e o devolve ao trabalho até a meta ser cumprida ou o número de turnos definido acabar.

O que um loop bem desenhado precisa ter

Um loop sem critério de sucesso para cedo demais ou não para. Os textos que espalharam o termo concordam em poucas peças.

• Meta verificável: O que é pronto, dito de forma que um teste ou um avaliador consiga conferir, como uma suíte verde ou uma nota mínima de Lighthouse.
• Verificação automatizada: Testes, linters e os passos de conferência manual escritos como skill, para o agente checar o próprio trabalho de ponta a ponta.
• Condição de parada e teto: Número máximo de turnos e orçamento de custo por execução.
• Isolamento: Cada execução em seu próprio git worktree, para dois agentes não mexerem nos mesmos arquivos.
• Estado fora da conversa: Um arquivo de progresso ou um quadro de tarefas que a próxima execução lê ao começar.
• Saída revisável: O resultado termina em um pull request ou em um relatório, nunca direto em produção.

O Zorbit, produto próprio da Master Timm, segue esse desenho para agentes de código: agenda execuções por cron ou em DAG, roda cada tarefa em um git worktree até o pull request e audita o custo e os tokens de cada execução.

Quando usar loops na empresa, e quando não usar

Loops rendem quando o trabalho se repete e uma máquina consegue conferir o resultado. Sem essas duas condições, um loop só automatiza a incerteza.

• Bons candidatos: Corrigir testes até a suíte passar, atualizar dependências com o CI verde, fazer a triagem diária de issues, perseguir uma meta de desempenho com número definido.
• Maus candidatos: Tarefas sem critério de acerto, decisões de produto, mudanças que dependem de alguém do negócio.
• Tarefas pequenas: Um pedido simples não precisa de loop nem de vários agentes; em alguns casos, um modelo menor e mais barato resolve.
• Ações com efeito fora do repositório: Pagamento, e-mail para cliente ou alteração em produção pedem aprovação humana dentro do loop, não depois.

Fora do código, o mesmo desenho aparece em agentes de IA autônomos com tarefas agendadas, como OpenClaw e Hermes Agent, que configuramos com permissões, canais e memória sob controle.

Riscos de deixar um agente em loop

Osmani resume o problema em uma frase: um loop que roda sem supervisão também erra sem supervisão. Os riscos são conhecidos, e os controles também.

• Custo: Cada volta consome tokens, e um loop longo ou frequente demais multiplica a conta; o intervalo deve seguir a frequência com que o dado muda, e um orçamento por execução encerra o loop no limite.
• Vitória declarada cedo: Com verificação fraca, o agente dá a tarefa por concluída sem que ela esteja; a meta precisa de um teste que possa falhar de verdade.
• Código que ninguém leu: Quanto mais rápido o loop entrega, maior a distância entre o que está no repositório e o que o time entende; a revisão humana do pull request continua obrigatória.
• Permissões amplas sem ninguém olhando: Um loop autônomo roda com o mínimo de acesso, sem segredos de produção e com comandos liberados por lista.