06Capítulo 6: Agentes: o loop que trabalha sozinho

Um agente é um modelo com ferramentas rodando em loop. Recebe um objetivo, decide o próximo passo, executa, olha o resultado e repete até terminar ou até precisar de você. Claude Code, o modo agente do Copilot e o agente do Cursor funcionam assim.

Não tem peça nova aqui. É tudo o que você viu nos capítulos anteriores: o modelo (1), o contexto (2), as ferramentas (3) e os servidores MCP (4 e 5). O que muda é quem aperta “enviar” de novo.

Por que o loop muda tudo

Num chat comum, o loop é você: copia o erro, cola, recebe a sugestão, aplica, roda de novo, copia o novo erro. No agente, o próprio modelo roda o teste, lê a falha, ajusta e roda de novo.

A diferença não é o modelo ficar mais esperto. É ele poder ver o resultado do que fez. Lembra do capítulo 1? O modelo escreve com a mesma confiança quando acerta e quando erra. Num loop com testes, o erro aparece na saída do teste e ele corrige antes de te mostrar.

Quando vale usar

Funciona bem quando:

• Existe um jeito de saber que terminou. Testes passando, build compilando, lint limpo, a página abrindo sem erro.
• O trabalho tem muitas etapas mecânicas. Renomear algo em 40 arquivos, atualizar uma dependência e consertar o que quebrar, escrever testes para um módulo inteiro.
• É preciso investigar antes de mudar. Achar onde uma função é usada, entender um fluxo antes de mexer nele.

Funciona mal quando:

• Não há como verificar. “Melhore este código” não tem fim definido.
• A decisão é sua. Arquitetura, escolha de biblioteca, o que entra ou não no produto.
• A ação não tem volta. Deploy em produção, migração de banco, apagar dados. Aqui o agente prepara e você executa.

Como pedir

Compare dois pedidos para a mesma tarefa. O primeiro:

Arruma o login.

O segundo:

O login com Google falha em produção com redirect_uri_mismatch (log abaixo). Descubra a causa, corrija e adicione um teste que reproduz o problema. Terminou quando pnpm test passar. Não altere a configuração do provedor no console do Google; se for preciso, me diga o que mudar lá.

O segundo pedido tem cinco coisas que o primeiro não tem:

1. O problema com evidência. O erro exato e o log.
2. O objetivo. Causa, correção e teste.
3. O critério de pronto. pnpm test passando. É a condição de saída do loop.
4. Os limites. O que ele não pode tocar.
5. O que fazer no limite. Em vez de travar ou improvisar, ele te diz o que mudar.

Para tarefas grandes, peça um plano antes de qualquer código. Leia, ajuste e só então mande executar. O Claude Code tem um modo de planejamento para isso, e os outros agentes respondem bem a “antes de mudar qualquer coisa, me mostre o plano”.

Subagentes

Em tarefas maiores, um agente pode delegar partes para outros agentes, cada um com o próprio contexto. Um investiga onde algo é usado, outro revisa a segurança da mudança, e só o resumo de cada um volta para o agente principal.

Isso resolve dois problemas: protege a janela de contexto do agente principal (capítulo 2), que não se enche com tudo o que os outros leram, e permite trabalho em paralelo. No Claude Code, subagentes são definidos em arquivos dentro de .claude/agents/, cada um com uma descrição de quando deve ser chamado e quais ferramentas pode usar.

Permissões

Agentes pedem permissão antes de ações sensíveis, e quase todos deixam você liberar algumas de vez. A regra prática:

• Libere o que é seguro e repetitivo: ler arquivos, rodar os testes, rodar o lint.
• Mantenha a confirmação para o que tem efeito fora da sua máquina: push, deploy, mensagens, chamadas a APIs pagas.
• Nunca libere o que apaga ou sobrescreve dados que você não consegue recuperar.

Por que ser tão cuidadoso com algo que, afinal, está trabalhando para você? Porque o agente lê muita coisa que não foi você que escreveu. O último capítulo é sobre isso.