🧱 Padrões avançados

O padrão mais bruto e mais famoso da casa: o Ralph loop (Geoffrey Huntley / HumanLayer). É um loop de shell infinito que repete o MESMO prompt sem parar. Cada volta muta o código — e esse código mutado vira o estado inicial da próxima volta.

O que ver: o mesmo prompt entra em todas as voltas (a seta não muda); o que muda é o código no meio, que carrega o progresso para a próxima iteração. É o estado externalizado da 4.1 levado ao extremo.

# O Ralph one-liner — cole no seu terminal, na raiz do projeto
# PROMPT.md contém a tarefa; troque o agente pela ferramenta que você usa.

while :; do cat PROMPT.md | npx --yes @sourcegraph/amp ; done

Como verificar / quando usar: rode num repositório descartável (de preferência num worktree isolado — tópico 3) com um git status aberto noutra aba: você verá commits/mudanças surgindo a cada volta. Use para tarefas grandes e repetitivas com verificação embutida; pare cedo — Huntley alerta que rodar demais produz "bizarre emergent behavior". O loop infinito é poderoso e perigoso na mesma medida: combine SEMPRE com guardrails (tópico 4).

Owain Lewis (relatado) descreve a forma "frota": um loop é um job que o agente repete — acorda num agendamento ou evento, lê o estado do trabalho, faz UM job escopado dentro de permissões fixas, escreve o resultado, dorme, e repete. É o oposto do Ralph: disciplinado, pequeno, controlado.

O que ver: não é um agente gênio fazendo tudo — é uma frota de agentes pequenos, cada um com um job estreito e permissões fixas. A coordenação é externa (o control plane), não está na cabeça de nenhum agente.

Para rodar vários agentes em paralelo sem que eles pisem uns nos outros — e sem que algum faça algo irreversível — você precisa de isolamento. Três peças: worktrees, sandboxes e permissões fixas.

O consenso grassroots da comunidade é direto: "os guardrails são o trabalho de verdade, não os agentes." O agente é a parte fácil. O difícil — e o que separa um sistema seguro de um desastre — é desenhar os limites. O worker abre PR, mas nunca dá merge; um humano aprova.

# Cole no topo do PROMPT.md do seu worker (ajuste os nomes ao seu repo)

REGRAS (não negociáveis):
- Trabalhe APENAS nos arquivos sob .
- Abra um Pull Request ao terminar. NUNCA dê merge você mesmo.
- NUNCA toque em produção, em segredos (.env, chaves) nem em CI/CD.
- PROIBIDO: git push --force, deletar branches, alterar o histórico.
- PARE e peça aprovação humana antes de: ,
   ou .
- Se a verificação falhar 3 vezes, pare e escreva o que travou em BLOCKED.md.

Como verificar: rode o worker num worktree de teste e confira o resultado contra cada linha — abriu PR sem merge? não tocou em .env? parou quando bateu numa migração? Se alguma regra foi violada, o guardrail está fraco demais e o prompt precisa ser mais específico. O guardrail só é real quando você o testa contra um agente tentando contorná-lo.

Você viu o Maker→Checker na Trilha 2. Aqui ele sobe de nível: o checker fica adversarial. Em vez de só conferir, um segundo agente (ou painel) tenta QUEBRAR o trabalho — é prompted para refutar, achar o buraco, provar que está errado.

A frota cresce: um manager promptando agentes que promptam agentes — "Russian nesting dolls" (bonecas russas), aninhamento dentro de aninhamento. O padrão que organiza tudo é uma sequência: orquestrar → delegar (fan-out) → verificar.

O último padrão muda a unidade do loop: em vez de uma volta, um episódio inteiro. A cross-trial memory (memória entre tentativas, do paper Reflexion) faz o loop atravessar tentativas: agir → receber feedback → refletir em texto → guardar na memória episódica → tentar melhor na próxima.