🗺️ Por que não há definição única
Seu instinto de confusão estava certo. Em 45 fontes verificadas, dois grandes vendors e o blogueiro mais citado convergiram numa frase tidiosa, mas fora dela, as definições fraturam em 11 escolas distintas. O eixo que organiza tudo vai do mínimo ao máximo.
Leia o espectro: à esquerda, o loop é uma frase ("um LLM usando ferramentas num loop"). À direita, vira um sistema agendado, multi-sessão, que se auto-desenha. As 11 escolas se espalham por aqui.
🧩 Duas coisas viajam sob "loop"
O ciclo de cognição interno do agente (reason-act-observe) e um loop de orquestração externo, agendado/automatizado/desenhado por um humano, dentro do qual o agente roda. Confundir os dois é a fonte de metade dos mal-entendidos.
📦 Minimalista: "ferramentas num loop"
A convergência formal, numa frase: "um LLM (ou modelo) chamando ferramentas num loop até a tarefa terminar". Simon Willison, Anthropic e LangChain dizem quase isso, palavra por palavra. O loop é trivial; o artesanato são as ferramentas, o prompt e a condição de parada.
"Um LLM agente roda ferramentas num loop para atingir um objetivo."
"LLMs usando ferramentas, de forma autônoma, num loop."
"Um modelo chamando ferramentas num loop até a tarefa terminar."
💡 A frase virou saco de pancada
Hoje essa definição minimalista é também o alvo que praticantes atacam por ser "simples demais para ser útil" (swyx cita a frase só para rebatê-la). Ou seja: é a base — mas o debate de fronteira já saiu dela.
🔄 ReAct: reason → act → observe
A escola mais "acadêmica" e a única que nomeia um ciclo de cognição interno: cada iteração é pensamento → ação → observação, repetindo até terminar. É de um paper (Yao et al., 2022) e virou vocabulário padrão em docs e frameworks.
📊 Quem está nessa escola
É a maior por número de fontes: o paper do ReAct, surveys de arquitetura, e frameworks como smolagents, LlamaIndex e Pydantic AI. Quando uma doc fala "Thought / Action / Observation", é esta escola.
✅ Verificação: própria × separada
Duas escolas elevam a verificação a etapa nomeada — e discordam de quem confere.
Auto-verificação
O mesmo agente confere o próprio trabalho: reunir → agir → verificar → repetir (SDK da Anthropic). Voyager faz isso num gate de correção de código.
Avaliador separado
Um segundo agente dá nota à saída do gerador; o loop roda de novo até PASS. O gerador nunca se auto-aprova (evaluator-optimizer).
🔗 Onde isso te leva
O avaliador separado é a raiz do padrão Maker → Checker que você monta na mão na Trilha 2, e do verificador adversarial que você vê na Trilha 4. Guarde a ideia: quem faz não dá a própria nota.
🏗️ Runner × loop autônomo
Outra divisão: quem é dono do loop? Para os vendors, um objeto de runtime (o Runner). Para os autônomos, ninguém — ele se auto-prompta e roda sozinho.
🏗️ Runner / runtime
Um orquestrador é dono do loop. Uma "run" = um turno: chama o modelo, inspeciona a saída, ramifica (rodar ferramentas / handoff / retornar), até um ponto de parada ou max_turns.
OpenAI SDK, Google ADK, AWS Bedrock — todos formais.
🛰️ Loop autônomo
Roda sem supervisão em direção a uma meta: se auto-prompta ou acorda por agendamento, completa um ciclo, checa o estado contra o critério, grava o resultado e repete — sem humano re-promptando.
AutoGPT é a âncora: auto-prompt → responde → repete até a meta.
🛰️ As escolas de borda (e uma armadilha)
No extremo "máximo" e nas margens vivem as escolas mais provocativas — e uma pura armadilha de nome.
🛰️ Loop engineering
"Pare de promptar o agente; projete o loop que prompta o agente" (Steinberger). O humano vira arquiteto. É o tema inteiro da Trilha 4.
🧠 Loop de memória entre tentativas
O loop atravessa episódios: agir → feedback → refletir em texto → guardar na memória → tentar melhor na próxima (Reflexion). Aprende por linguagem, não por re-treino.
🧱 "Loop não é o primitivo certo"
swyx: o loop é só a peça de controle de fluxo de um sistema de 6 elementos. Outros surveys descrevem o agente como módulos (perfil/memória/planejamento/ação), sem nomear "loop".
🚨 A armadilha terminológica: "loop" ≠ HITL
Zapier, LangChain HITL e Microsoft HITL usam "loop" para significar human-in-the-loop (supervisão humana: aprovar, escalar, dar feedback) — e não definem nenhum loop de agente.
Erro clássico do iniciante: copiar um guia de HITL achando que é um padrão de build de loop. São coisas diferentes.
⚖️ Os 6 eixos de discordância
As frases de uma linha escondem 6 eixos onde as definições brigam de verdade. Saber os eixos te deixa ler qualquer definição nova e localizar onde ela cai.
| Eixo | As posições que aparecem |
|---|---|
| Quem é dono do loop | o próprio modelo · um Runner/orquestrador · um humano que projeta o loop |
| O que termina o loop | o modelo decide · um avaliador (PASS) · teto duro (max_turns) · um operador/CTRL+C |
| Verificar é um passo? | sim, pelo próprio · sim, por avaliador separado · não há passo explícito |
| Escopo de 1 iteração | uma chamada de ferramenta · uma sessão/context window inteira · um episódio (com memória) |
| Ferramentas são essenciais? | sim, são o ponto do loop · não, o loop é decisão/reflexão; ferramentas opcionais |
| "Loop" é o primitivo certo? | sim, o agente é um loop · é só uma peça de um sistema maior · "loop" = HITL, não o agente |
🧩 O que isso prova
Tire as brigas e sobra o núcleo invariante do módulo 1.2 (modelo, iteração, estado, objetivo). É nele que um iniciante pode confiar — o resto é estilo de cada autor.
Você acha um guia "human-in-the-loop". Pode usá-lo como receita para montar um loop de agente?
🧾 Resumo do Módulo
Próximo:
Trilha 2 — Quando (e quando NÃO) usar loop