Aula · Loops, goals e agentes de longa duração · 2026

Pare de ser a coisa dentro do loop

Sete formas de fazer um agente trabalhar sem você promptar — como cada uma funciona por dentro, quando usar cada uma, e os freios que as mantêm sob controle.

A ideia central desta aula. Quase todo erro de automação com agentes vem de usar a primitiva errada: polling onde o disparo era um evento, sessão local onde precisava de nuvem, loop temporal onde o fim era uma condição. Três perguntas resolvem a escolha: (1) precisa sobreviver ao laptop fechado? (2) o que encerra o trabalho — tempo, condição ou evento? (3) quem decide o ritmo — você ou o modelo? No fim, você pratica contra oito cenários e roda um loop no simulador, volta a volta.

01A anatomia de um loop

A definição que sustenta tudo: um loop é cron mais um decisor no corpo. Um cron job executa um script fixo; um loop executa um modelo que olha o estado atual, decide o próximo passo, age, verifica o que produziu e decide se continua. A decisão é do agente — não é um branch hardcoded seu.

cronquando rodar

decisoro que fazer agora

loopum cérebro no meio do timer

Repare na caixa verifica: ela é o que separa um loop confiável de uma máquina de gerar erros confiantes. Loop sem feedback compõe erros na mesma velocidade em que compõe commits. Guarde essa caixa — ela volta na seção do validador e no simulador.

02As sete primitivas, desenhadas

2.1 — `/loop 5m` · tempo fixo

Você conhece o ritmo certo de checagem. O harness agenda um cron determinístico dentro da sessão; cada tick injeta o prompt quando a sessão está idle.

# ritmo conhecido: CI roda em ~4 min
/loop 5m check CI on the open PR; if red, fix and push
# fila de jobs que enche a cada poucos minutos
/loop 3m drain the failed-jobs queue, requeue with fix

Limites documentados: mínimo 1 minuto; máximo 50 crons por sessão; jitter de até 30 min em recorrentes; morre com a sessão e expira em 7 dias por design — um guardrail contra loops esquecidos.

2.2 — `/loop` dinâmico · o modelo escolhe o ritmo

Você não sabe o intervalo certo. Ao final de cada iteração, o próprio Claude chama a tool ScheduleWakeup e escolhe quando acordar de novo, entre 1 minuto e 1 hora — espaçando conforme o que observou.

# ETA incerto: deploy leva 10–20 min, ninguém sabe ao certo
/loop watch the Railway deploy; notify me on success or failure
# o exemplo canônico do Boris Cherny (criador do Claude Code)
/loop babysit all my PRs. Auto-fix build issues, and when comments
      come in, use a worktree agent to fix them

Repare no que está escrito no segundo exemplo: não os passos, mas a intenção e o comportamento de parada. O loop prompta o agente a cada tick; o conteúdo de cada tick é decidido na hora, olhando o estado real dos PRs.

Detalhe: em Bedrock/Vertex/Foundry não há ScheduleWakeup — vira intervalo fixo de 10 min.

2.3 — `/goal` · condição encerra, não tempo

O fim do trabalho é algo que fica verdadeiro, não uma hora que chega. Após cada turno, um modelo pequeno (padrão Haiku) lê a conversa e avalia a condição. Falsa? Novo turno, com a razão da falha como guia. Verdadeira? Encerra e registra achieved.

# condição verificável + hard stop embutido
/goal all tests in test/auth pass and lint is clean,
      or stop after 20 turns

# gerenciamento
/goal          # status
/goal clear    # cancela (aliases: stop, off, reset, none, cancel)

Condição boa vs condição ruim Boa: npm test exits 0 and typecheck is clean — o avaliador confirma lendo o output que apareceu na conversa. Ruim: o código está bom e bem organizado — subjetiva; o avaliador não tem como julgar, e o goal nunca fecha (ou fecha errado). Regra de bolso: condição de goal é o que um estagiário confirmaria olhando o terminal. Máximo de 4.000 caracteres; requer trust dialog. doc oficial

2.4 — `/schedule` · routines na nuvem

A única primitiva nativa que sobrevive ao seu laptop fechado. Cada execução é uma sessão fresh numa VM da Anthropic, clonando a branch default. Três gatilhos: horário (cron), webhook do GitHub, ou POST na API.

/schedule daily PR review at 9am
/schedule tomorrow at 3am, run the content pipeline for the queue
/schedule list

Limites documentados: mínimo 1 hora entre execuções; requer plano Pro/Max/Team/Enterprise; MCP connectors funcionam, MCP servers locais não.

2.5 — Background e Monitor · evento dispara, não relógio

Quando o gatilho é algo acontecendo — uma linha de erro no log, um processo terminando — polling por tempo chega atrasado e desperdiça ticks. run_in_background solta o processo sem bloquear; Monitor streama cada linha de output para o agente reagir na hora.

Limites documentados: Monitor indisponível em Bedrock/Vertex/Foundry e com telemetria desabilitada; tudo morre com a sessão.

2.6 — Subagents, workflows e Agent Teams · escala paralela agora

Nem todo trabalho autônomo é recorrente. Migrar 200 arquivos, revisar 12 dimensões, processar uma fila inteira — isso é fan-out: um orquestrador dispara N tasks em paralelo, cada uma com implementador, verificadores e fixer, e retorna quando tudo converge. Teams adicionam comunicação lateral entre agentes de longa duração.

Limites documentados: subagent não spawna subagent; Agent Teams são experimentais (flag de ambiente), um time por sessão, sem resume de teammates in-process.

2.7 — Agent SDK · o loop externo é seu código

O degrau de produção. Você escreve o while em Python ou TypeScript; o agente é uma chamada dentro dele. Durabilidade vem de artefatos persistidos (git, arquivos, banco) — não da sessão.

Padrão recomendado pela Anthropic em Effective harnesses for long-running agents: um agente initializer prepara o ambiente na primeira run; um agente worker faz progresso incremental a cada sessão; o log da conversa e os artefatos são a fonte de verdade.

03A escada histórica

Isso não nasceu ontem. A confusão nas discussões existe porque a palavra "loop" esconde cinco coisas de gerações diferentes:

Nota de honestidade intelectual Esta escada vem do debate público de 2026 (Steinberger, Cherny e a discussão em volta). A linhagem é real, mas os números virais que circulam junto — 259 PRs em 30 dias, o teto de gastos da Uber — são relatos do discurso, sem fonte primária verificada aqui. E a nomenclatura exata varia por ferramenta e versão. O que fica de durável é o conceito dos dois gatilhos — objetivo e tempo — porque toda arquitetura de agente autônomo que você encontrar vai ser alguma combinação dos dois. É a próxima seção.

04Dois gatilhos: `/goal` vs `/schedule`

Os dois comandos respondem perguntas diferentes — e é por isso que não competem entre si:

/goal

responde: quando parar?

Disparo: vocêroda uma vez, manual
Loop de execuçãorepete até a validação passar
Término definitivometa cumprida, fim

tem fim · não tem gatilho próprio

/schedule

responde: quando começar?

Disparo: o relógioex.: todo dia às 3h
Uma passadaexecuta a rotina do tick
Dormeespera o próximo horário

tem gatilho próprio · não tem fim

O loop de orquestração é a fusão dos dois: o relógio dispara, e a cada disparo um decisor roda até concluir a unidade de trabalho. Na linha do tempo:

O EIXO DO TEMPO É CRON PURO — O QUE ACONTECE DENTRO DE CADA BARRA É O QUE CRON NUNCA TEVE

A leitura da terceira linha é o ponto-chave: cada barra começa num tick do relógio (herança do /schedule), mas tem largura diferente porque roda até a unidade de trabalho estar validada (herança do /goal) — e o conteúdo de cada barra é decidido na hora pelo modelo, olhando o estado atual do repositório, dos PRs, dos comentários. É por isso que "é só um cron job" está meio certo e meio errado.

05O validador por dentro

O /goal só termina quando um avaliador — separado, menor, de contexto limpo — confirma a conclusão. A arquitetura que faz o ciclo convergir em vez de tentar às cegas:

Quem faz não é quem avalia

Verificar é mais barato que produzir, e o contexto limpo importa tanto quanto a separação: depois de vinte voltas, o executor está contaminado pelas próprias racionalizações. O juiz chega frio, sem investimento emocional no trabalho.

Julga evidências, não opiniões

O validador não "lê e acha que ficou bom". Ele checa fatos que apareceram na conversa: suíte verde? Build passou? Diff dentro do escopo? Critérios atendidos um a um? Sem evidência executável, ele vira só um segundo palpiteiro.

A qualidade do veredito é a qualidade da meta

O validador só decide o que você tornou decidível. Escrever metas validáveis é a nova habilidade de especificação — mais próxima de critérios de QA do que de prompts bonitos.

O validador também desconfia

O modo de falha clássico é o reward hacking: o executor deleta o teste que falhava, marca skip, hardcoda a resposta. Por isso a meta boa também protege a integridade da evidência: o número de testes diminuiu? Algum assert enfraqueceu? O diff saiu do escopo?

# meta ruim — impossível de validar
/goal melhore a performance do app

# meta boa — cada critério é um teste binário
/goal reduza o tempo de resposta do endpoint /search para menos de
200ms p95. Critérios: o benchmark em bench/search.js passa; todos os
testes existentes continuam verdes; nenhum arquivo fora de src/search/
foi alterado. Or stop after 25 turns.

Quando reprova, o validador devolve o motivo ("teste X falhou com erro Y") — que vira o guia do próximo turno. É isso que transforma o ciclo em convergência em vez de tentativa cega.

06Receitas prontas — projetos e dia a dia

Copie, troque os substantivos, rode. Cada receita indica a primitiva certa e o porquê.

No dia a dia — `/loop`

# 1. A babá de PRs (vigilância contínua, ritmo incerto)
/loop babysit my open PRs: auto-fix build failures, address review
      comments in a worktree agent, re-request review when green

# 2. Acompanhar um deploy sem saber o ETA
/loop watch the staging deploy; when it finishes, smoke-test the
      login flow and tell me the result

# 3. Manter a branch sempre integrável
/loop keep this branch rebased on main; resolve trivial conflicts,
      stop and ask me when a conflict touches business logic

# 4. Triagem de issues enquanto você trabalha
/loop triage new GitHub issues: label them, close duplicates,
      ask for a repro when the report has none

# 5. Caçar flakiness com estatística (ritmo conhecido)
/loop 30m run the e2e suite, log failures with seeds; after 5 runs,
      summarize which tests are flaky and why

Em projetos — `/goal`

# 6. Migração até ficar verde (o clássico)
/goal the db layer migration is complete: npm test, lint and
      typecheck all pass, or stop after 25 turns

# 7. Subir cobertura com integridade protegida
/goal coverage in src/payments is at least 80 percent, existing
      tests untouched and still green, or stop after 30 turns

# 8. Zerar dívida de tipos
/goal zero typescript errors with strict mode enabled in apps/web,
      no ts-ignore added, or give up after 2 hours

# 9. Bug com prova de regressão (anti reward-hacking)
/goal the bug in issue #142 is reproduced by a new failing
      regression test, then fixed: that test passes, the whole
      suite stays green, diff confined to src/auth/

# 10. Documentação que prova que funciona
/goal the commands in README and docs/setup.md run end to end on
      a clean checkout without manual fixes, or stop after 15 turns

Em rotinas — `/schedule`

# 11. Revisão matinal do que entrou ontem
/schedule daily at 9am: review yesterday's merged PRs, summarize
      risks and anything that needs a follow-up issue

# 12. Higiene semanal de dependências
/schedule weekly monday 7am: check outdated dependencies, open one
      bump PR with changelog notes and migration warnings

# 13. Revisão automática de cada PR (gatilho de evento na nuvem)
/schedule on every opened PR: review for security issues and
      style violations, comment inline

# 14. O job noturno pontual (one-off, laptop fechado)
/schedule tomorrow at 3am, process the queued items in the content
      pipeline; validate one item before running the batch

A fusão — relógio dispara, meta encerra

# 15. O loop de orquestração da seção 04, em uma linha
/schedule nightly at 2am: pick the oldest issue labeled good-first,
      work it until tests and lint are green, open a PR — one issue
      per night, skip if none qualify

A receita 15 é a terceira linha do diagrama da seção 04 em forma de comando: o relógio decide quando começar, a condição decide quando parar, e o modelo decide o que fazer no meio.

07Os três freios de produção

O custo migrou: uma vez que o modelo escreve o código por quase nada, a parte cara é o loop rodando. E o modo de falha que assusta produção é o loop que não para. Todo loop sério converge para três paradas obrigatórias:

Freio	Pergunta que responde	Como aplicar
Limite de iterações	"E se nunca convergir?"	Bound no /goal ("or stop after 25 turns"); contador no loop do SDK. Chegou no teto: pare e chame um humano.
Detecção de estagnação	"E se girar em falso?"	Comparar estado entre ticks (diff, hash de artefato); abortar se ficar idêntico 3 voltas seguidas.
Teto de custo	"E se a conta explodir?"	Orçamento de tokens/dólares por execução e por dia. A expiração de 7 dias do /loop é este freio, embutido.

A versão romântica: mil agentes constroem sua empresa enquanto você dorme. A versão de produção: a maior parte do trabalho é garantir que eles param.

08A árvore de decisão

09Três casos resolvidos passo a passo

Caso A — Pipeline de conteúdo rodando de madrugada

"Quero processar a fila do pipeline hoje às 3h da manhã. Vou dormir, laptop fecha."

Sobrevive ao laptop fechado? Precisa — isso elimina /loop, /goal, Monitor e teams de uma vez.
Infra gerenciada serve? Sim, é uma execução pontual. → /schedule tomorrow at 3am, process the queued items (receita 14).
Onde entra a verificação? No próprio prompt da routine: validar uma unidade antes do batch e escrever um relatório de falhas como artefato.

Caso B — Refatoração que precisa terminar, não importa em quantos turnos

"Migrar o db layer e só parar quando test + lint + typecheck estiverem verdes."

Laptop fechado? Não — você está por perto, é trabalho de sessão.
O que encerra? Uma condição verificável. → /goal ... all pass, or stop after 25 turns (receita 6).
Freios: o bound de 25 turnos é o limite de iterações; a condição em si é a verificação. Sem o bound, um goal mal escrito é o loop-que-não-para.

Caso C — Babá de PRs durante a tarde de trabalho

"Enquanto trabalho em outra coisa, quero CI verde e comentários de review respondidos nas minhas PRs abertas."

Laptop fechado? Não — sessão aberta a tarde toda.
O que encerra? Nada encerra: é vigilância contínua por tempo. → /loop.
Ritmo conhecido? Não — comentários chegam quando chegam. → dinâmico (receita 1). O modelo espaça os wakeups sozinho e a expiração de 7 dias é o freio de custo embutido.

10Simulador: um loop, volta a volta

Rode o ciclo abaixo e observe as três coisas desta aula acontecendo: o decisor escolhendo o próximo passo, o validador reprovando com motivo, e os freios contando ao fundo. A meta usa a receita 9 — bug com prova de regressão e escopo protegido.

loop-runner — meta: corrigir busca quebrada

/goal corrigir o bug de acentuação na busca. Critérios: search.spec.js 100% verde · build ok · diff restrito a src/search/ · or stop after 8 turns

loop carregado. freios: máx. 8 voltas · teto US$ 5,00 · estagnação em 3 voltas iguais.

pressione "rodar 1 volta" para iniciar.

volta 0/8 custo US$ 0,00/US$ 5,00 testes — estado ocioso

Repare: ninguém disse como corrigir. A meta declarou a intenção e os critérios de parada — o resto é o loop promptando o agente a cada volta, e o motivo de cada reprovação virando o guia da volta seguinte.

11Pratique: oito cenários

Feedback imediato. Meta: 8/8, justificando mentalmente em menos de 30 segundos.

1. "Subi um deploy no Railway que leva uns 10 a 20 minutos, não sei exatamente quanto. Quero que o agente acompanhe e me avise quando terminar ou falhar."

/loop 1m check the deploy /loop check the deploy (dinâmico) /goal the deploy is finished /schedule

2. "Refatoração grande: quero que o agente continue, turno após turno, até todos os testes de test/auth passarem e o lint ficar limpo — sem eu pedir 'continua' toda hora."

/loop 10m continue a refatoração Agent Team com 3 teammates /goal all tests in test/auth pass and lint is clean, or stop after 20 turns Bash run_in_background

3. "Quero um resumo das PRs mergeadas do dia, toda manhã às 9h, mesmo com meu Mac desligado."

/schedule daily PR review at 9am /loop 24h resumo das PRs /goal com condição de horário cron do macOS chamando claude -p

4. "Vou rodar o dev server e quero que o agente observe o log e corrija na hora qualquer erro que aparecer, enquanto eu testo no browser."

/loop 1m leia o log /schedule hourly /goal no errors in the log Monitor / Bash run_in_background

5. "Um sistema que roda toda noite, lê issues e abre PRs em 30 repos, em produção, com crash recovery — independente de qualquer sessão aberta."

/loop dinâmico numa sessão aberta para sempre Agent SDK + scheduler próprio (ou /schedule como versão gerenciada) /goal abrir PRs em todos os repos Agent Teams

6. "Migrar 200 arquivos para a nova API agora, em paralelo, enquanto acompanho. Não é recorrente — é um trabalho grande de uma vez."

/loop 5m migre o próximo lote /schedule Workflow / subagents em paralelo (fan-out) /goal all 200 files migrated

7. "Quero que toda PR aberta no repo dispare automaticamente uma revisão de código — sem ninguém pedir, e sem depender da minha máquina."

Monitor observando gh pr list /loop 5m revise PRs novas /schedule com trigger de GitHub (webhook) /goal todas as PRs revisadas

8. "Comecei um /goal ambicioso ontem à noite numa sessão e ele ainda está rodando, queimando turnos sem progresso visível. Qual era o erro de design?"

Deveria ter usado /loop, que expira sozinho Faltou bound na condição ("or stop after N turns") e a condição era vaga demais para o avaliador confirmar /goal não funciona à noite, só com a sessão ativa Deveria ter usado Agent Teams para ir mais rápido

12Para o quadro

Sobre o papelPare de ser a coisa dentro do loop — escreva o loop uma vez, dê a ele feedback para se verificar e freios para parar, e vá decidir o que construir em seguida.

Sobre os gatilhos/goal sabe quando parar, /schedule sabe quando começar — e o loop de orquestração sabe as duas coisas, mais o que fazer no meio.

Sobre a metaO validador não decide se o trabalho está bom; decide se as evidências provam os critérios. Meta sem critérios prováveis não é meta — é desejo.

E a provocação final: o loop é encanamento; o ativo é a skill que ele chama. Um loop sem skills reutilizáveis é um while true em volta de um estranho — re-deriva tudo e queima dinheiro. Um loop que chama uma biblioteca de skills nomeadas, testadas e afiadas é um sistema que compõe. A regra prática: fez algo mais de uma vez? Vira skill. Fez algo difícil? Vira skill depois — para a próxima vez sair de graça.

# o on-ramp é literalmente uma linha — copie e troque os substantivos
/loop babysit all my PRs. Auto-fix build issues, and when comments
      come in, use a worktree agent to fix them

Alan Nicolas ♾️

Home