🧩 Fundamentos do Loop Engineering

Loop Engineering e a abordagem onde sistemas automatizados (loops) disparam, monitoram e iteram sobre agentes de IA em ciclo continuo, substituindo o prompting manual humano.

Entender a definicao precisa evita confusao com automacao generica. O termo tem significado especifico no contexto de coding agents.

Loop-driven vs prompt-driven. O humano define o sistema, nao cada prompt. Analogia com cron jobs + agentes de IA.

Boris Cherny, Head of Claude Code, gerencia dezenas de milhares de agentes por dia usando loops. Ele nao digita prompts: monta sistemas que fazem isso por ele.

A credibilidade da fonte importa. Boris esta no centro do desenvolvimento de Claude Code e pratica loop engineering em escala industrial.

Escala de milhares de agentes/dia. Prompting como sistema, nao como interacao. Anthropic como referencia pratica.

Peter Steinberger criou o OpenClaw e roda loops que fazem o prompting de Claude automaticamente, com orchestrator + workers e state management externo.

E um caso real de implementacao fora da Anthropic. Mostra que a abordagem funciona para desenvolvedores independentes, nao so para quem cria a ferramenta.

OpenClaw como harness. Separacao orchestrator/worker. State externo (Postgres). Autonomia do agente.

No prompting manual, o humano interage diretamente com o agente a cada passo. No loop-driven, o humano define o sistema uma vez e o loop executa N rodadas automaticamente.

A distincao e fundamental para saber quando cada abordagem faz sentido. Loop-driven nao substitui prompting manual em todos os casos.

Interacao sincrona vs assincrona. Custo de atencao humana. Escala vs precisao. Trade-off de controle.

Loop Engineering combina o conceito de tarefas agendadas (como cron jobs no Linux) com a capacidade de raciocinio dos LLMs. O loop dispara, o agente decide o que fazer.

A analogia ajuda a desmistificar: nao e magia, e automacao com uma camada inteligente. Quem entende cron jobs ja tem meio caminho andado.

Trigger temporal vs condicional. Job = sessao do agente. Exit condition = criterio de parada. Idempotencia.

O termo Loop Engineering ganhou tracao apos Boris Cherny descrever publicamente como a Anthropic usa loops internamente. Cole Medin questiona: "merece seu proprio buzzword?"

Separar sinal de ruido. Nem tudo que ganha nome proprio e revolucionario. Entender o contexto evita adotar cegamente.

Hype cycle. Naming como marketing. Substancia vs branding. Critica honesta de Cole Medin.

O comando /loop define intervalos de execucao para o agente, como "a cada 5 minutos". E o mecanismo de recorrencia que mantem o agente ativo.

Sem loop, o agente para quando termina uma tarefa. Com loop, ele acorda periodicamente para verificar se ha trabalho novo.

Intervalo de polling. Wake-up automatico. Diferenca entre loop e single-shot. Custo de tokens por ciclo ocioso.

/goal define um criterio objetivo de conclusao. O agente continua iterando ate atingir o goal ou esgotar tentativas. E a exit condition do loop.

Sem goal claro, o loop roda infinitamente gastando tokens sem resultado. O goal e o que transforma um loop em algo util.

Exit condition explicita. Verificacao automatica de completude. Fallback e retry limits. Goal vs deadline.

/routines sao tarefas agendadas com schedule definido (ex.: "a cada hora, revise a spec"). Diferente do /loop generico, routines tem proposito especifico e recorrente.

Routines sao o mecanismo mais pratico para tarefas de manutencao: code review periodico, sync de docs, health checks.

Schedule tipo cron. Routine vs loop ad-hoc. Composicao de multiplas routines. Prioridade entre routines conflitantes.

Os tres primitivos nao operam isolados. Um sistema tipico combina /loop como heartbeat, /goal como criterio de saida e /routines como tarefas de manutencao paralelas.

Entender a composicao e o passo de "sei o que cada peca faz" para "consigo montar um sistema funcional".

Pipeline como grafo. Dependencias entre blocos. Prioridade de execucao. Diagnostico quando um bloco falha.

O plan.md e o documento markdown que define as tarefas para o loop processar. Funciona como um contrato: o orchestrator le, executa item por item, e marca como concluido.

Um plan.md mal escrito gera loops ineficientes. A qualidade do input determina a qualidade do output, mesmo em sistemas automatizados.

Estrutura de task list. Granularidade ideal de tarefas. Criterios de aceitacao por item. Versionamento do plano.

Loop sem exit condition (roda pra sempre), goal vago ("faca algo bom"), routine que conflita com o loop principal. Sao armadilhas que queimam tokens sem resultado.

Evitar esses erros desde o inicio poupa dinheiro e frustracao. A maioria dos iniciantes cai nos mesmos buracos.

Loop infinito. Goal ambiguo. Conflito de routines. Max iterations como safety net. Budget limits.

O orchestrator e a sessao de agente que le a spec, decide quais tarefas executar, dispara workers e valida resultados. Ele nao executa codigo diretamente.

O orchestrator e o ponto de falha mais critico. Se ele toma decisoes ruins, todos os workers produzem lixo. Entender seu papel e essencial.

Separacao de concerns. Decisao vs execucao. Modelo do orchestrator (pode ser mais barato). Retry logic no orchestrator.

Workers sao sessoes de agente que recebem uma tarefa especifica do orchestrator e a executam. Podem rodar em paralelo usando worktrees para isolamento.

Workers sao onde o trabalho real acontece. Entender como isola-los, monitorar e coletar resultados e a parte pratica do loop engineering.

Worktrees como sandbox. Paralelismo real. Coleta de resultados. Worker timeout. Isolamento de estado.

Em vez de depender do context window do LLM para manter estado, o loop grava estado em um banco externo (Postgres, Neon). Isso evita context bloat e permite resumir sessoes.

Context bloat e a causa #1 de degradacao em loops longos. State externo e a solucao arquitetural que torna loops viaveis em escala.

Banco como fonte de verdade. Context window como cache, nao storage. Neon branching para workers. Schema do state store.

Fluxo: spec entra -> orchestrator planeja -> spin workers -> workers executam -> resultados voltam ao state -> orchestrator valida -> proxima onda ou conclusao.

Visualizar o fluxo completo ajuda a debugar quando algo da errado. Cada passo e um ponto potencial de falha que precisa de tratamento.

Round como unidade de trabalho. Fan-out (orchestrator -> workers). Fan-in (workers -> orchestrator). Validacao entre rounds.

Com state externo, se o agente cair no meio de um round, o orchestrator pode retomar de onde parou. O estado no banco sobrevive a crashes, timeouts e desconexoes.

Loops longos inevitavelmente falham em algum ponto. Durabilidade e o que diferencia um brinquedo de um sistema de producao.

Checkpoint no state store. Resume from last good state. Idempotencia de workers. Cleanup de workers orfaos.

Observabilidade e a capacidade de ver o que o loop esta fazendo em tempo real: decisoes do orchestrator, progresso dos workers, custo acumulado, erros.

Sem observabilidade, voce roda um loop cego. "Run for a day, come back to crap" e o sintoma de falta de monitoramento.

Agent Control Plane. Cost tracking por round. Decision log do orchestrator. Human-in-the-loop checkpoints.