🧱 Advanced patterns

The roughest and most famous pattern in the house: the Ralph loop (Geoffrey Huntley / HumanLayer). It’s an infinite shell loop that repeats the SAME prompt endlessly. Each pass mutates the code—and that mutated code becomes the starting state for the next pass.

What to look at: the same prompt goes into every round (the arrow doesn’t change); what changes is the code in the middle, which carries progress into the next iteration. It’s the externalized state from 4.1 taken to the extreme.

# 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

How to verify / when to use: run it in a disposable repository (preferably in an isolated worktree — topic 3) with a git status open in another tab: you'll see commits/changes appear on each turn. Use it for large, repetitive tasks with built-in verification; stop early — Huntley warns that running too long produces "bizarre emergent behavior." The infinite loop is powerful and dangerous in equal measure: ALWAYS pair it with guardrails (topic 4).

Owain Lewis (as reported) describes the “fleet” approach: a loop is a job the agent repeats — wakes up on a schedule or event, reads the state of the work, does ONE scoped job within fixed permissions, writes the result, sleeps, and repeats. It’s the opposite of Ralph: disciplined, small, controlled.

What to look at: it's not a genius agent doing everything—it's a fleet of small agents, each with a narrow job and fixed permissions. Coordination is external (the control plane), not in any agent's head.

To run several agents in parallel without them stepping on each other's toes—and without any of them doing something irreversible—you need isolation. Three pieces: worktrees, sandboxes, and fixed permissions.

The grassroots community consensus is direct: "the guardrails are the real work, not the agents." The agent is the easy part. The hard part—and what separates a safe system from a disaster—is designing the boundaries. The worker opens a PR, but never merges it; a human approves it.

# 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.

How to verify: run the worker in a test worktree and check the result against every line — opened a PR without merging? didn't touch .env? did it stop when it hit a migration? If a rule was violated, the guardrail is too weak and the prompt needs to be more specific. The guardrail is only real when you test it against an agent trying to get around it.

You saw Maker→Checker in Track 2. Here it levels up: the checker stays adversarial. Instead of just checking, a second agent (or panel) tries to BREAK the work — it’s prompted to refute it, find the flaw, prove it wrong.

The fleet grows: a manager prompting agents that prompt agents — "Russian nesting dolls," nesting within nesting. The pattern that organizes everything is a sequence: orchestrate → delegate (fan-out) → verify.

The last pattern changes the unit of the loop: instead of one iteration, a episode entire. The cross-trial memory (memory between attempts, from the Reflexion paper) lets the loop span multiple attempts: act → receive feedback → reflect in text → save to episodic memory → try again, better, next time.