Como funciona o loop agêntico do Claude Code

O Claude Code não segue uma lista fixa de passos: ele repete um ciclo até a tarefa terminar. Esta página explica como esse ciclo funciona e quando vale a pena dividir o trabalho entre vários agentes — e quando isso só cria mais problema do que resolve.

O que acontece a cada volta do loop?

Um agente do Claude Code passa por três fases em cada volta: reúne contexto (lê arquivos, roda um comando, consulta uma ferramenta), toma uma ação (edita código, executa um teste, chama uma tool) e verifica o resultado antes de decidir o próximo passo. Não existe uma quarta fase fixa de "planejar" nem uma de "fazer deploy" — o loop é essas três fases, repetidas quantas vezes a tarefa pedir.

É por isso que duas tarefas parecidas gastam números de iterações bem diferentes: renomear uma variável usada em três arquivos pode fechar numa volta só, enquanto depurar um teste que falha de forma intermitente pode levar dez, porque cada tentativa de correção precisa ser verificada antes da próxima.

Quando vale a pena abrir um subagent

Um subagent roda numa sessão separada e devolve só um resumo para o contexto principal — a exploração ruidosa (arquivos lidos, comandos que falharam, becos sem saída) fica de fora. Isso mantém a sessão principal enxuta mesmo em tarefas grandes.

A regra que decide se vale a pena: a tarefa delegada precisa ser estreita e verificável. "Revise a segurança destes 40 arquivos independentes" se divide bem entre subagents porque cada pedaço tem um critério de sucesso claro. "Melhore o backend" não delega bem para ninguém — nem para um subagent, nem para uma pessoa — porque não existe critério para saber quando terminou.

Delegar também é decidir qual modelo cada subagent usa. Uma tarefa mecânica — renomear uma variável no projeto inteiro — não precisa do modelo mais caro disponível; uma tarefa que exige julgamento sobre trade-offs arquiteturais precisa. Rotear pelo modelo mais barato que ainda resolve a tarefa corretamente é parte do design da delegação, não um ajuste de custo separado.

Por que rodar agentes em paralelo nem sempre funciona

Fan-out — disparar vários subagents ao mesmo tempo — só funciona quando as partes são de fato independentes. Duas tarefas que mexem no mesmo arquivo, ou que dependem do resultado uma da outra, quebram em paralelo do mesmo jeito que quebrariam se duas pessoas editassem o mesmo arquivo ao mesmo tempo sem combinar antes.

Rodar múltiplas sessões no mesmo repositório tem um problema concreto: elas disputam o mesmo working tree. Git worktrees resolvem isso dando a cada sessão sua própria cópia de trabalho, todas apontando para o mesmo repositório — sem o risco de uma sessão pisar no que a outra estava editando.

Por que vale a pena um segundo agente conferir o primeiro

Pedir para o mesmo agente revisar o próprio trabalho tem um viés estrutural: ele tende a confirmar as decisões que acabou de tomar. Um segundo agente, numa sessão separada e sem ver o raciocínio do primeiro, tem mais chance de pegar um erro real porque não carrega o mesmo ponto cego.

Isso só reduz falsos positivos de verdade se o agente verificador for independente — contexto próprio, não o resumo do primeiro — e tiver um critério objetivo para julgar. Sem essas duas condições, a "verificação" vira só uma segunda opinião enviesada pela primeira.