Loop Engineering: projetando os loops que guiam agentes de IA

Durante anos, a sabedoria convencional era: se o modelo errar, melhore o prompt. Isso funcionava quando um agente era essencialmente um call único, você envia uma pergunta, recebe uma resposta, fim. Pense nisso como uma função pura: f(prompt) → resposta. O problema é que tarefas reais raramente cabem em um call. Escrever código, pesquisar um tema, gerar um relatório longo, todas essas tarefas exigem múltiplos passos, uso de ferramentas externas e correção de erros intermediários.

Quando você encadeia esses passos em um loop, o agente age, observa o resultado, raciocina sobre o que fazer a seguir e age de novo, o prompt individual deixa de ser o gargalo. O gargalo passa a ser o design do loop: o que dispara o ciclo, como o agente decide o próximo passo, quem verifica se o resultado presta, e, criticamente: quando o loop para. Um loop sem stop rule clara é um while(true) com cartão de crédito: ele itera até o budget acabar ou você matar o processo. Loop engineering é a disciplina de projetar esse ciclo de controle com a mesma seriedade que você projeta um pipeline de dados ou um sistema de mensageria.

ReAct (Yao et al., 2022) é o alfabeto do loop engineering. O nome vem de Reasoning + Acting. A sequência é:

1. Perceber (Observe): o agente recebe o estado atual, a tarefa original, o histórico de iterações anteriores e o resultado da última ação.
2. Raciocinar (Reason): o agente produz um 'pensamento', uma cadeia de raciocínio interna que decide o próximo passo. Isso é o que o modelo escreve antes de chamar uma ferramenta.
3. Agir (Act): o agente executa uma ação, chamar uma API, buscar na web, escrever em um arquivo, invocar um sub-agente.
4. Observar (Observe): o resultado da ação é capturado e adicionado ao contexto. Esse resultado alimenta o próximo ciclo de raciocínio.

A analogia de engenharia é um control loop de sistemas de controle: sensor → controlador → atuador → sensor. Cada observação é o feedback que fecha o loop. O que torna o ReAct poderoso não é nenhuma das etapas individualmente, é o fato de que cada observação muda o contexto do próximo raciocínio. O agente aprende com o que acabou de fazer, dentro da mesma sessão, sem retreinamento.

Todo loop agêntico, independente do padrão, tem exatamente quatro componentes que você precisa projetar explicitamente:

1. Trigger: O que inicia o ciclo. Pode ser síncrone (mensagem de usuário, chamada HTTP) ou assíncrono (cron job via EventBridge, evento em fila SQS, outro agente). A escolha do trigger determina a cadência e o contrato de latência do loop.

2. Topologia: A forma do loop. Single-agent itera sozinho, simples, fácil de rastrear, mas limitado em paralelismo. Sub-loops com sub-agentes permitem dividir tarefas complexas (ex: cada capítulo de um e-book processado por um sub-agente independente), mas adicionam complexidade de orquestração e custo de coordenação.

3. Verifier: Quem decide se o resultado presta. Este é o componente mais subestimado. A armadilha clássica é usar o próprio agente para se auto-avaliar, o modelo é tendencioso em favor do próprio output. Um verifier real é externo: um teste automatizado, uma consulta a banco de dados, uma validação de schema, uma chamada a outro modelo especializado em crítica.

4. Stop Rules: O critério de parada. Sem stop rule verificável, você tem um loop infinito. As quatro stop rules fundamentais são: (a) meta atingida por check automático, (b) teto de iterações, (c) budget de tokens ou custo esgotado, (d) detecção de no-progress. Critério vago: 'quando estiver bom', é a causa número um de loop infinito em produção.

Construí e opero vários loops agênticos neste site. Aqui estão os que ensinaram mais:

Geração diária de artigos (EventBridge → Lambda → Bedrock): O trigger é um cron job às 06:00. O loop usa Bedrock AgentCore Web Search para fundamentar o conteúdo. O verifier checa se o artigo tem as seções obrigatórias via schema. O fail-safe é crítico: se a busca falha, o loop não aborta, cai para grounding apenas do texto-fonte. Isso é um circuit breaker de ferramenta, não do loop inteiro.

E-book capítulo-a-capítulo: Em vez de passar o livro inteiro no contexto (o que estouraria a janela e o custo), o loop itera capítulo a capítulo. Cada capítulo é um sub-loop independente com cache próprio. Se um capítulo falha, o sub-loop reprocessa apenas aquele capítulo, o estado do livro (quais capítulos estão prontos) vive em S3, não na memória do agente.

Cron de áudio às 02:00 (idempotente): O ponteiro no S3 ('qual arquivo de áudio já foi gerado') é o estado da verdade. Se o Lambda re-executa por qualquer motivo, ele lê o ponteiro, detecta que o arquivo já existe e pula. Isso é idempotência por design, o estado externo governa, não o estado em memória.

Loop de keepalive (projetado ao vivo): Para manter um render longo vivo dentro de uma janela curta, projetei um heartbeat que envia um sinal a cada N segundos. A stop rule é simples: se o render terminou (check no S3), o heartbeat para. Meta-exemplo de como uma stop rule verificável elimina o problema de não-terminar.

A parte mais difícil do loop engineering não é o loop em si, é o plano de controle: o conjunto de mecanismos que garante que o loop termina, é observável e pode ser retomado após falha.

Stop rules verificáveis: A regra de ouro é que toda stop rule deve ser verificável por um check automático, não por julgamento do agente. 'Quando o artigo estiver bom' é vago. 'Quando o schema de validação passar E o artigo tiver mais de 800 palavras' é verificável. Critério vago é a causa número um de loop infinito.

Budgets explícitos: Cada loop deve ter um teto de tokens, custo em USD e/ou tempo em segundos. Quando o budget esgota, o loop para, independente do resultado. Isso é análogo ao timeout que você já usa em qualquer chamada de rede. O custo cresce a cada iteração (especialmente em reflection, onde ~dobra, estimativa), então o budget é a última linha de defesa.

Observabilidade por iteração: Cada iteração deve emitir um traço: o que o agente pensou, qual ação executou, qual foi o resultado, qual é o estado do budget. Sem isso, depurar um loop em produção é como depurar um sistema distribuído sem logs.

Idempotência e resumibilidade: O estado do loop deve viver em armazenamento externo (S3, banco de dados), não na memória do processo. Se o processo morre e re-executa, ele lê o estado externo e continua de onde parou, exatamente como um job de processamento em batch bem projetado.