# Loop Engineering: projetando os loops que guiam agentes de IA

O gargalo dos agentes de IA deixou de ser a frase do prompt e passou a ser o desenho do loop: trigger, topologia, verifier e stop rules. Este guia ensina os fundamentos do loop engineering — do ReAct base ao catálogo de padrões — com exemplos reais do meu próprio sistema e um passo a passo para engenheirar qualquer loop com segurança.

- URL: https://fernando.moretes.com/studies/loop-engineering-agentes-de-ia

- Markdown: https://fernando.moretes.com/studies/loop-engineering-agentes-de-ia/study.md?lang=pt

- Type: Guia / Deep Dive

- Domain: IA / Agentes

- Date: 2026-06-29

- Tags: loop-engineering, ai-agents, ReAct, agentic-systems, LLM, orchestration, bedrock, stop-rules

- Reading time: 8 min

---

Em junho de 2026, Addy Osmani publicou um ensaio que nomeou algo que muitos engenheiros já sentiam mas não conseguiam articular: o trabalho de construir agentes de IA não é mais escrever prompts melhores — é projetar os loops que fazem o prompt trabalhar. Boris Cherny, criador do Claude Code, disse literalmente que seu trabalho agora é 'escrever os loops que dirigem o Claude'. Peter Steinberger resumiu: 'pare de fazer prompt nos seus agentes e comece a projetar os loops que fazem prompt neles'. Se você vem do mundo de software e nunca construiu um agente de IA, este guia começa do zero: o que é um loop agêntico, por que ele quebra, e como engenheirá-lo com a mesma disciplina que você aplica a qualquer sistema distribuído.

## O que você vai aprender

- A virada conceitual: por que prompt engineering cedeu lugar a loop engineering
- Os 4 componentes de todo loop: trigger, topologia, verifier, stop rules
- O loop base ReAct (perceber → raciocinar → agir → observar) passo a passo
- Catálogo de 5 padrões com trade-offs: retry, plan-execute-verify, reflection, while-not-done, human-in-the-loop
- O plano de controle: stop rules verificáveis, budgets, circuit breakers, observabilidade, idempotência
- Exemplos reais do meu próprio sistema (geração de artigos, e-book, áudio, keepalive)

## Glossário rápido — termos do loop engineering

- **Loop Engineering:** Disciplina de projetar o ciclo de controle que governa um agente de IA: o que dispara, como itera, quando para e quem verifica o resultado.
- **Trigger:** O evento que inicia o loop: pode ser uma mensagem de usuário, um cron job (agendamento), um evento de fila ou outro agente.
- **Topologia:** A forma do loop: single-agent (um agente itera sozinho), sub-loops (agentes filhos paralelos ou sequenciais), ou grafo de agentes.
- **Verifier:** O componente que decide se o resultado presta. DEVE ser um check automático e verificável — não a auto-avaliação do próprio agente (que é tendenciosa).
- **Stop Rule:** Critério verificável que encerra o loop: meta atingida, teto de iterações, budget de tokens/custo esgotado, ou detecção de no-progress.
- **Budget:** Limite explícito de recurso (tokens, custo em USD, tempo em segundos) alocado ao loop. Quando esgotado, o loop para — independente do resultado.
- **No-Progress:** Estado em que o agente itera mas o output não muda (estado externo estável). Detectado por hash ou diff entre iterações consecutivas.
- **Circuit Breaker:** Padrão de resiliência (igual ao de microserviços): após N falhas consecutivas, o loop abre o circuito e para de tentar, evitando desperdício de budget.
- **ReAct:** Padrão de loop base (Yao et al., 2022): Reason + Act. O agente raciocina sobre o estado, age (chama ferramenta), observa o resultado e repete.
- **Reflection / Reflexion:** Padrão (Shinn et al., 2023) em que o agente gera uma crítica do próprio erro, armazena na memória e injeta na próxima tentativa. Cada ciclo ~dobra o custo em tokens (estimativa).

## A virada: de prompt engineering para loop engineering

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.

## O loop base: ReAct passo a passo

ReAct (Yao et al., 2022) é o alfabeto do loop engineering. O nome vem de **Re**asoning + **Act**ing. 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.

## Anatomia de um loop engenheirado

Diagrama didático: trigger → loop do agente (ReAct: raciocinar → agir → observar, com ferramentas e memória) → verifier → checagem de stop rule → done ou iterar. Budget e observabilidade envolvem tudo. Gate human-in-the-loop opcional antes do verifier.

### ⚡ Trigger Zone

- User message (user)
- Cron / Event EventBridge (messaging)
- Queue SQS / SNS (messaging)

### 🧠 Agent Loop (ReAct)

- Reason chain-of-thought (ai)
- Act call tool / sub-agent (compute)
- Observe capture result (compute)
- Memory context / history (storage)
- Tools APIs / search / code (external)

### ✅ Verification Zone

- Human-in-the-Loop approval gate (user)
- Verifier auto check (not self-eval) (security)

### 🛑 Stop Rule Zone

- Stop Rule goal | iter | budget | no-progress (compute)
- DONE result emitted (edge)
- ITERATE back to reason (compute)

### 📊 Control Plane (wraps all)

- Budget tokens / cost / time (security)
- Observability trace per iteration (data)
- Checkpoint idempotent state (S3/DB) (storage)

### Fluxos

- user -> reason: dispara
- cron -> reason: agenda
- queue -> reason: evento
- reason -> act: próximo passo
- act -> tools: chama
- tools -> observe: retorna
- act -> observe: resultado
- observe -> memory: persiste
- memory -> reason: contexto
- observe -> hitl: se risco alto
- observe -> verifier: submete
- hitl -> verifier: aprova
- verifier -> stoprule: pass/fail
- stoprule -> done: meta atingida
- stoprule -> iterate: ainda não
- iterate -> reason: próxima iteração
- budget -> stoprule: força parada
- obs -> checkpoint: traço por iter
- checkpoint -> reason: resume após falha

## Os 4 componentes de todo loop — e por que cada um importa

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.

## Catálogo de padrões de loop — trade-offs lado a lado
| Critério | Padrão | Melhor para | Custo por iteração | Risco de não-terminar | Como termina |
| --- | --- | --- | --- | --- | --- |
| Retry / Circuit-Breaker | Falhas transitórias de ferramenta ou API | Baixo (repete o mesmo call) | Baixo se N fixo | Após N tentativas ou timeout | Geradores com 2 tentativas + abort por timeout |
| Plan-Execute-Verify | Tarefas estruturadas com critério de sucesso claro | Médio (3 fases por ciclo) | Baixo-médio | Verifier passa ou budget esgota | Geração de artigo: planeja seções → escreve → valida schema |
| Reflection / Auto-crítica | Qualidade alta necessária; erros sutis de raciocínio | Alto (~dobra a cada ciclo — estimativa) | Médio (pode ciclar em críticas sem convergir) | Crítica vazia ou budget de iterações | Revisão de capítulo de e-book com crítica armazenada em memória |
| While-Not-Done + Sub-agentes | Tarefas longas paralelizáveis (coding agents, e-books) | Alto (N sub-agentes × custo por capítulo) | Alto se orquestrador não tiver stop rule forte | Todos os sub-loops concluem ou orquestrador aborta | E-book capítulo-a-capítulo com cache por capítulo |
| Human-in-the-Loop | Ações irreversíveis ou de alto risco (publicar, pagar, deletar) | Variável (depende da latência humana) | Muito baixo (humano é o verifier) | Aprovação humana ou timeout de checkpoint | Gate de aprovação antes de publicar artigo gerado |

## Exemplos reais do meu sistema — o que aprendi na prática

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.

## Quando usar cada abordagem: one-shot × workflow × loop

### One-Shot (call único)

**Pros**
- Latência mínima, custo previsível, sem risco de não-terminar
- Fácil de testar e depurar

**Cons**
- Não corrige erros intermediários, sem uso de ferramentas dinâmicas
- Limitado pela janela de contexto

**Verdict:** Use para tarefas simples, bem definidas, com output de tamanho previsível.

### Workflow / DAG fixo

**Pros**
- Determinístico, auditável, fácil de monitorar
- Custo por execução previsível

**Cons**
- Não adapta a erros inesperados, requer redesenho para novos fluxos

**Verdict:** A maioria dos casos reais em produção. Use quando o fluxo é conhecido e estável. Workflow + RAG resolve 80% dos casos (estimativa).

### Loop Single-Agent

**Pros**
- Adapta a erros, usa ferramentas dinamicamente, corrige rota
- Topologia simples de rastrear

**Cons**
- Custo cresce com iterações, risco de loop infinito sem stop rule forte
- Latência alta para tarefas longas

**Verdict:** Use para tarefas abertas, verificáveis, com custo de iteração aceitável e stop rules explícitas.

### Loop Multi-Agente / Sub-loops

**Pros**
- Paralelismo real, divide tarefas muito longas, cache por sub-tarefa
- Falha isolada por sub-loop

**Cons**
- Alta complexidade de orquestração, custo de coordenação, difícil de depurar
- Risco de não-terminar se orquestrador não tiver stop rule forte

**Verdict:** Tendência de 2026 em coding agents. Use apenas quando a tarefa é paralelizável e o custo de coordenação é justificado.

## O plano de controle: onde os loops quebram de verdade

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.

## Guia passo a passo: como engenheirar um loop

- 1. DEFINA A META e um CHECK de sucesso verificável (não 'quando estiver bom' — um teste automatizado, schema, query).
- 2. ESCOLHA O TRIGGER: síncrono (usuário/HTTP) ou assíncrono (cron/fila/evento). Defina o contrato de latência.
- 3. ESCOLHA A TOPOLOGIA/PADRÃO: single-agent, plan-execute-verify, reflection, while-not-done+sub-agentes, ou combinação. Prefira o mais simples que resolve o problema.
- 4. DEFINA O VERIFIER: externo, automático, não-autorreferente. Qual check concreto diz que o resultado presta?
- 5. DEFINA STOP RULES + BUDGETS: teto de iterações, budget de tokens/custo/tempo, detecção de no-progress (hash/diff entre iterações).
- 6. ADICIONE OBSERVABILIDADE + CHECKPOINTS: traço por iteração, estado persistido externamente (S3/DB) para resumibilidade.

> **Minha leitura sênior — Fernando Azevedo:** O que me chama atenção no loop engineering não é a novidade do conceito — control loops existem desde os anos 50 em engenharia de controle. O que é novo é que agora o 'controlador' é um LLM com raciocínio emergente e custo por token. Isso muda o trade-off fundamentalmente: cada iteração custa dinheiro real e pode produzir output não-determinístico. A consequência prática é que stop rules e budgets deixam de ser 'boas práticas' e viram **requisitos de negócio**. Na minha experiência operando esses sistemas: (1) o erro mais comum é não ter verifier externo — o agente se auto-avalia e sempre acha que está bom; (2) o segundo erro mais comum é stop rule vaga — 'quando a tarefa estiver completa' sem definir o que 'completa' significa em termos verificáveis; (3) a maioria dos casos reais não precisa de loop autônomo — workflow + RAG resolve com muito menos risco. Loop agêntico é para tarefas genuinamente abertas onde o caminho não é conhecido de antemão. Se você sabe o caminho, use um DAG. Reserve o loop para quando você não sabe.

> **No próximo: orquestração multi-agente:** Quando um loop vira muitos: orquestração multi-agente, padrões de comunicação entre agentes, e como projetar o plano de controle de um sistema onde vários loops rodam em paralelo — incluindo como lidar com falhas parciais sem abortar o trabalho todo.

## Veredicto

Loop engineering é a resposta correta para a pergunta errada que a indústria fez por anos: 'como faço o modelo acertar com um prompt melhor?'. A pergunta certa é: 'como projeto o ciclo de controle que guia o modelo até o resultado correto, de forma verificável, dentro de um budget, e que para quando deve parar?'. Os quatro componentes — trigger, topologia, verifier, stop rules — são o mínimo não-negociável. O plano de controle (budgets, observabilidade, idempotência) é o que separa um loop que funciona em demo de um que funciona em produção. A maioria dos sistemas reais não precisa de loop autônomo — workflow + RAG resolve com menos risco, menor custo e maior previsibilidade. Use o loop agêntico quando a tarefa é genuinamente aberta, verificável e o custo de iteração é aceitável. Quando usar, engenheirar o loop com a mesma disciplina que você aplicaria a qualquer sistema distribuído crítico.

## Referências

- [Agentic Loops: From ReAct to Loop Engineering (2026 Guide) — Data Science Dojo](https://datasciencedojo.com/blog/agentic-loops-explained-from-react-to-loop-engineering-2026-guide/)
- [The Agentic Loop — A Practical Field Guide — dev.to / truongpx396](https://dev.to/truongpx396/the-agentic-loop-a-practical-field-guide-mnc)
- [Anthropic — Building effective agents](https://www.anthropic.com/engineering/building-effective-agents)
- [Yao et al. — ReAct: Synergizing Reasoning and Acting in Language Models (arXiv 2210.03629)](https://arxiv.org/abs/2210.03629)
- [Shinn et al. — Reflexion: Language Agents with Verbal Reinforcement Learning (arXiv 2303.11366)](https://arxiv.org/abs/2303.11366)
- [AWS — Amazon Bedrock AgentCore](https://aws.amazon.com/bedrock/agentcore/)

## Fontes do caso

- [Agentic Loops: From ReAct to Loop Engineering (2026 Guide)](https://datasciencedojo.com/blog/agentic-loops-explained-from-react-to-loop-engineering-2026-guide/)
- [The Agentic Loop — A Practical Field Guide](https://dev.to/truongpx396/the-agentic-loop-a-practical-field-guide-mnc)
- [Anthropic — Building effective agents](https://www.anthropic.com/engineering/building-effective-agents)
- [Yao et al. — ReAct: Synergizing Reasoning and Acting in LLMs](https://arxiv.org/abs/2210.03629)
- [Shinn et al. — Reflexion](https://arxiv.org/abs/2303.11366)
- [AWS — Amazon Bedrock AgentCore](https://aws.amazon.com/bedrock/agentcore/)