🧱 Patrones avanzados

El patrón más básico y más famoso de la casa: el Ralph loop (Geoffrey Huntley / HumanLayer). Es un loop de shell infinito que repite el MISMO prompt una y otra vez. Cada vuelta modifica el código, y ese código modificado se convierte en el estado inicial de la siguiente vuelta.

Qué ver: el mismo prompt entra en todas las vueltas (la flecha no cambia); lo que cambia es el código en el medio, que lleva el progreso a la siguiente iteración. Es el estado externalizado de la 4.1 llevado al 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

Cómo verificar / cuándo usar: ejecútalo en un repositorio descartable (de preferencia en un worktree aislado — tema 3) con un git status abierto en otra pestaña: verás aparecer commits/cambios en cada vuelta. Úsalo para tareas grandes y repetitivas con verificación integrada; detente pronto — Huntley advierte que ejecutar demasiado produce "bizarre emergent behavior". El loop infinito es igual de poderoso y peligroso: combínalo SIEMPRE con guardrails (tema 4).

Owain Lewis (según se informa) describe la forma «flota»: un ciclo es un trabajo que el agente repite — se activa con una programación o un evento, lee el estado del trabajo, realiza UN job con alcance definido dentro de permisos fijos, escribe el resultado, se duerme y repite. Es lo opuesto a Ralph: disciplinado, pequeño y controlado.

Qué ver: no es un agente genio que lo hace todo: es una flota de agentes pequeños, cada uno con un job acotado y permisos fijos. La coordinación es externa (el control plane), no está en la cabeza de ningún agente.

Para ejecutar varios agentes en paralelo sin que interfieran entre sí —y sin que alguno haga algo irreversible— necesitas aislamiento. Tres piezas: worktrees, sandboxes y permisos fijos.

El consenso grassroots de la comunidad es directo: "los guardrails son el trabajo de verdad, no los agentes." El agente es la parte fácil. Lo difícil — y lo que separa un sistema seguro de un desastre — es diseñar los límites. El worker abre un PR, pero nunca hace merge; un humano lo aprueba.

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

Cómo verificar: ejecuta el worker en un worktree de prueba y comprueba el resultado línea por línea — ¿abrió un PR sin hacer merge? ¿no tocó .env? ¿Se detuvo al llegar a una migración? Si se violó alguna regla, la barrera de seguridad es demasiado débil y el prompt debe ser más específico. La barrera solo es real cuando la pones a prueba con un agente que intenta eludirla.

Ya viste Maker→Checker en la Ruta 2. Aquí sube de nivel: el checker queda adversarial. En vez de solo revisar, un segundo agente (o panel) intenta ROMPER el trabajo: recibe instrucciones para refutar, encontrar el fallo y demostrar que está equivocado.

La flota crece: un manager que da prompts a agentes que dan prompts a otros agentes —«Russian nesting dolls» (muñecas rusas), anidamiento dentro de anidamiento. El patrón que organiza todo es una secuencia: orquestar → delegar (fan-out) → verificar.

El último patrón cambia la unidad del loop: en vez de una vuelta, un episodio entero. La memoria entre pruebas (memoria entre intentos, del paper Reflexion) permite que el loop pase por varios intentos: actuar → recibir feedback → reflexionar en texto → guardar en la memoria episódica → hacerlo mejor la próxima vez.