---
type: PLB
asset_id: PLB-EL-LoopEngineering-Playbook-v01
version: v01
status: Draft — para ratificación de Victor
owner: Victor Heredia
sherpa_owner: Jay
ratificador: Victor Heredia
intellibank: IB-EL-EmpowerLabs
subbank: PB-EL-Project-Bank/PB-EL-Plataforma
fecha_creacion: 2026-06-13
proposito: Playbook de Loop Engineering para el equipo de desarrollo de EmpowerLabs. Qué es un loop, su anatomía, las 4 rutas de uso, el catálogo Forward Future (31 loops), los caveats, y el mapeo de qué loops explorar en nuestras apps (IntelliBanks, Rebelocity Club, MasterPlaybooks), con foco en el loop sub-50ms page-load. Punto de partida para ajustar el mindset del equipo dev.
fuente: "(1) Forward Future / Matthew Berman — '7 INSANE loops' (youtube F4a8aMLb678) + repo github.com/Forward-Future/loop-library (README + SKILL.md) + catálogo live signals.forwardfuture.ai/loop-library/catalog.md (31 loops, jun-2026, MIT). (2) Nate Herk / AI Automation — 'Finally. Agent Loops Clearly Explained' (youtube EuzYhzB0vbI) — validado: aporta la capa de juicio (topologías + cuándo NO usar loops). Origen del término 'loop engineering': Addy Osmani (Google); atribución Boris Cherny (Anthropic, Claude Code) verificada. Autorización de navegación dada por Victor."
referencia_canonica:
  - "[[PP-EL-LoopX-MacroLoopX-Arquitectura-v01]] (distinguir: MacroLoopX = business loops; este playbook = engineering loops)"
  - "[[PLAN-EL-DesarrolloPlataformaComunidades-v01]] · PB-REB-Rebelocity (RClub) · IB-MPX-MasterPlaybooks · IntelliBanks"
tags: [PLB, loop-engineering, loops, dev-team, mindset, ForwardFuture, MatthewBerman, IntelliBanks, Rebelocity, MasterPlaybooks, performance]
---

# Playbook — Loop Engineering
## Manual del equipo de desarrollo · cómo sacar trabajo confiable de agentes IA con loops

> **Para qué es esto:** ajustar el mindset del equipo dev. Pasar de "le pido a la IA que haga algo una vez" a "le doy a la IA un *loop*: una meta, una forma de verificarse, y una condición de paro — y la dejo trabajar hacia el objetivo." Partimos del trabajo de Forward Future (Matthew Berman, Loop Library, MIT) y lo aterrizamos a nuestras apps.

---

## §0 · El cambio de mindset (léelo primero)

La frase que resume todo (Berman): *"Los loops son el mayor desbloqueo para quien construye software con IA ahora mismo."*

Un **prompt one-shot** le pide al agente que haga algo **una vez**. Un **loop** le da una **meta**, una **forma de medir si la alcanzó**, y permiso para **seguir iterando hasta lograrla** — quitando al humano del centro para que el agente avance rápido y solo. El equipo deja de "pedir cambios" y empieza a "definir metas verificables y dejar que el agente las persiga."

No es autonomía infinita: un buen loop **está acotado** — tiene un check real, un punto de paro claro, y un momento para devolver el control a un humano cuando hace falta juicio o aprobación.

---

## §0.1 · Validación de las 2 fuentes (no son buenas solo porque las mandaron)

Analizamos dos videos. Veredicto honesto:

| | **Matthew Berman** (Forward Future) | **Nate Herk** (AI Automation) |
|---|---|---|
| Aporta | El **catálogo** y los loops de ingeniería concretos (el "qué loops correr") + la skill instalable | La **capa de juicio**: cuándo NO usar loops, topologías de construcción, anti-hype |
| Fortaleza | Loops reproducibles, accionables, con harness | Mindset crítico, honesto sobre límites y costo |
| Debilidad | Sesgo "token-maxer" (correr loops siempre); algo de hype | Pocos loops nuevos (usa los de Berman); demos flojos (Abbey Road, thumbnail); opinión > framework |
| Exactitud | Alta | Alta en lo esencial; **1 desliz**: dice que Peter Steinberger "trabaja en OpenAI" (no confirmado; es dev independiente). La cita real es de **Boris Cherny, Anthropic** |

**Dato verificado:** el término *loop engineering* lo acuñó **Addy Osmani (Google)**; Boris Cherny (head de Claude Code) sí dijo *"ya no prompteo a Claude; mi trabajo es escribir loops."* Ninguno de los dos videos cita a Osmani — el crédito de origen es suyo.

**Por qué nos sirve el video 2 más que el 1 para el equipo:** el riesgo de nuestro equipo dev no es "no conocer loops", es **sobre-ingenierizarlos** (montar flotas 24/7 que escalan bugs). Nate aporta justo el contrapeso: *"la mayoría de las tareas NO necesitan un loop"* y *"que alguien como Steinberger lo haga no significa que aplique a ti."* Eso es el mindset correcto. Por eso integramos su capa de juicio (§3.5 y §7).

---

## §1 · Qué es un loop (definición canónica)

Un loop responde **cuatro preguntas** (README Forward Future):

1. ¿Qué intenta lograr el agente? (la **meta**)
2. ¿Cómo sabrá si el último intento funcionó? (el **check**)
3. ¿Qué hace con lo que aprendió? (la **siguiente acción**)
4. ¿Cuándo termina o pide ayuda? (el **paro / handoff**)

Ejemplo (del README):
- **One-shot:** "Haz este sitio más rápido."
- **Loop:** "Encuentra la página más lenta, haz una mejora enfocada, y vuelve a medir. Conserva el cambio solo si ayuda. Repite hasta que cada página cumpla el objetivo o un paso deje de producir mejora significativa."

> Piensa en un loop como **un playbook con feedback incorporado.**

---

## §2 · Anatomía: Trigger + Goal, y el ciclo de 6 pasos

**Necesitas dos cosas para armar un loop:** un **Trigger** (qué lo arranca) y un **Goal** (a dónde llega).

**Triggers — 3 formas:**
- **Manual** — tú le dices al agente "corre este loop". (En Codex/Claude Code: `/goal …`.)
- **Schedule** — agendado (cada noche, semanal).
- **Action** — disparado por un evento (al abrir un PR, al llegar un ticket).

**Goals — 2 tipos (¡el punto más importante!):**
- **Verifiable** — algo concreto y medible determinísticamente. *Ej.: "cada página carga en <50 ms", "100% de cobertura de tests".* **Estos son los mejores loops.**
- **LLM-as-judge** — el modelo decide cuándo se cumplió. *Ej.: "refactoriza hasta que estés satisfecho con la arquitectura."* Más potente pero **más frágil** (dejas el gusto/juicio al modelo).

**El ciclo de 6 pasos (harness canónico del Loop Library skill):**

1. **Observe** — lee el estado fresco y recoge la evidencia acordada.
2. **Choose** — elige la acción de mayor valor según criterios explícitos.
3. **Act** — haz **un** cambio acotado y reversible (o produce un candidato).
4. **Verify** — corre el **mismo** check de aceptación bajo condiciones registradas.
5. **Record** — guarda acción, evidencia, resultado y trabajo restante.
6. **Repeat o Stop** — sigue solo mientras haya progreso medible y no se exceda el límite; si no, entra a un **estado terminal** nombrado.

**Estados terminales (nómbralos):** éxito · no-op limpio · bloqueado · requiere-aprobación · agotado (presupuesto) · estancado (sin progreso). **Nunca reportar un error o presupuesto agotado como éxito.**

---

## §3 · Las 4 rutas de uso (cómo el equipo opera con el Loop Library skill)

El skill `loop-library` (instalable: `npx skills add Forward-Future/loop-library --skill loop-library -g`) da 4 rutas. Pensar siempre "la ruta más pequeña útil":

| Ruta | Cuándo | Qué hace |
|---|---|---|
| **Find** | Tengo un problema, quiero un loop ya probado | Recomienda 1–3 loops publicados que encajen |
| **Audit / Loop Doctor** | Tengo un loop pero falla / es inseguro | Diagnostica y repara solo debilidades materiales (checks débiles, autoridad insegura, repetición sin límite, estado viejo, paro poco claro) |
| **Adapt** | Un loop publicado casi sirve | Cambia umbrales, herramientas, cadencia, owners o checks sin debilitar el ciclo de feedback |
| **Design** | No hay loop que encaje | Entrevista corta en lenguaje simple → produce un loop nuevo, acotado |

---

## §3.5 · Topologías de loop + qué hace que un loop funcione (del video 2)

**3 formas de construir un loop** (Nate Herk) — elegir la más simple que sirva:

1. **Solo loop** — un agente: razona → actúa → observa → repite. *La más común; muchas veces un terminal + buen prompt basta.* No necesitas arquitectura de flota.
2. **Maker-checker** — un agente hace, **otro** califica y da feedback. (= loops 019 Clodex / 020 Loop Harness del catálogo). Para output de alto impacto: el que crea no aprueba.
3. **Manager + helpers** — un orquestador dirige sub-agentes. Solo cuando la tarea lo justifica (escala bugs si no entiendes lo que haces).

> El ciclo mental de Nate es **Reason → Act → Observe** (variante del 6-pasos del §2 y del OODA). Metáfora útil para el equipo: *"un intern listo al que no microgestionas — le das una meta, hace su trabajo, se revisa solo, y vuelve solo cuando terminó."*

**Qué hace que un loop funcione (checklist de 8 — usar antes de armar cualquier loop):**
`☐ meta verificable` · `☐ paro duro (hard stop)` · `☐ buenas herramientas (para verificar)` · `☐ memoria` · `☐ checker separado` · `☐ planear primero` · `☐ logging` · `☐ que tenga sentido con el costo`.

**Las 2 preguntas obligatorias antes de escribir el goal:** (a) **¿Qué significa "done"?** (lo más objetivo posible: "itera hasta que métrica X = resultado Y"). (b) **¿Cómo va a verificar?** (visual / test funcional / screenshot / flujo) — y dale al agente las herramientas para hacer ese check. *Un loop es tan bueno como su done-check.*

---

## §4 · Catálogo Forward Future (31 loops · jun-2026)

Agrupados por categoría. Los de **Engineering / Evaluation / Operations** son los que tocan a nuestro equipo dev; **Content / Design** los puede usar MediaFactory.

### Engineering
| # | Loop | Goal | Para qué |
|---|---|---|---|
| 001 | **The docs sweep** | LLM-judge | Mantener docs/README/runbooks al día con el código; cierra con PR |
| 002 | **Architecture satisfaction** | LLM-judge | Refactor incremental hasta arquitectura satisfactoria (live-test + autoreview + commit) |
| 003 | **Sub-50 ms page-load** ⭐ | Verifiable | Optimizar hasta que cada página cargue <50 ms bajo el mismo benchmark |
| 004 | **Production error sweep** | Verifiable | Revisar logs de prod → causa raíz → fix → verifica → PR |
| 005 | **100% test coverage** | Verifiable | Agregar tests hasta 100% de cobertura |
| 007 | **Logging coverage** | LLM-judge | Cobertura de logs útil/testeada en cada path importante (sin exponer datos sensibles) |
| 008 | **Nightly changelog** | Verifiable | Cada noche, changelog con lo que el usuario debe saber |
| 011 | **Test-suite speed** | Verifiable | Acelerar la suite sin perder cobertura ni cambiar comportamiento |
| 012 | **Repository cleanup** | Verifiable | Recuperar trabajo valioso y limpiar ramas/PRs/worktrees stale |
| 016 | **Ticket-to-PR-ready** | Verifiable | Ticket/bug → parche listo para review (repro → causa → fix mínimo → regresión) |
| 019 | **Clodex adversarial-review** | Verifiable | Claude construye, Codex revisa adversarialmente cada ronda |
| 020 | **Loop Harness verification** | Verifiable | Trabajo recurrente: un agente genera, **otro** verifica (no el mismo) |

### Evaluation
| # | Loop | Goal | Para qué |
|---|---|---|---|
| 009 | **Quality streak** | Verifiable | N casos realistas exitosos seguidos; cada falla → regresión + fix → reinicia racha |
| 010 | **Full product evaluation** ⭐ | LLM-judge | N escenarios cubriendo cada capacidad mayor; arregla y re-corre hasta pasar la barra |
| 021 | **Boeing 747 benchmark** | Verifiable | Benchmark estándar de referencia |
| 023 | **Self-improving champion** | Verifiable | Mantener un "campeón" y retarlo con retadores hasta superarlo |
| 024 | **Devil's-advocate** | LLM-judge | Crítica adversarial de un diseño hasta robustecerlo |

### Operations
| # | Loop | Goal | Para qué |
|---|---|---|---|
| 013 | **Stale-safe batch release** | Verifiable | Combinar y liberar solo cambios completos y actuales |
| 014 | **Production data cleanup** | Verifiable | Limpiar registros que no cumplen la definición + mejorar el clasificador |
| 015 | **Post-release baseline** | Verifiable | Tras release, correr benchmarks y fijar la nueva línea base |
| 017 | **Customer AI deployment** ⭐ | Verifiable | Meter un workflow IA en un proceso real de cliente con aprobaciones, rollout y ROI |
| 030 | **Five-minute repo maintainer** | Verifiable | Mantenimiento exprés del repo |
| 031 | **Recent-feedback sweep** | LLM-judge | Convertir feedback reciente en fixes verificados |

### Otros (Engineering avanzado / Content / Design)
006 SEO/GEO visibility ⭐ (Content) · 018 Product update podcast (Content) · 022 War Loops: frontend reconstruction (Design) · 025 fresh-clone · 026 Infinite Clickbait thumbnail (Design) · 027 autonomy-loop builder-reviewer · 028 Codex completion-contract · 029 Revolve versioned-experiment.

> Catálogo vivo: `signals.forwardfuture.ai/loop-library/catalog.md`. El skill consulta el catálogo live como fuente de verdad.

---

## §5 · El loop estrella para nosotros — Sub-50 ms page-load (003)

El que más te gustó. Anatomía completa para que el equipo lo entienda:

- **Objetivo (verifiable):** cada página de la app carga en <50 ms.
- **Prompt:** *"Continúa optimizando el código para velocidad. Después de cada cambio significativo, mide el page-load en cada página bajo las mismas condiciones de prueba repetibles. Continúa hasta que cada página cargue en menos de 50 ms."*
- **Verify:** cada página <50 ms con el mismo benchmark, sin regresiones.
- **Trigger:** manual (`/goal …`), o **action** (al abrir un PR, para que ningún PR rompa el presupuesto de carga).
- **Requisito (Use when):** un set definido de rutas + un **harness de performance estable** + un objetivo de 50 ms que mapea a una métrica y entorno específicos. *(Sin harness de medición no hay loop verifiable — primero se monta el benchmark.)*
- **Corrió ~50 min** en el caso de Berman, recorriendo cada página y optimizándola.

---

## §6 · Mapeo a nuestras apps (lo que pediste) 🎯

Foco: qué loops explorar en **IntelliBanks**, **Rebelocity Club** y **MasterPlaybooks**. ⭐ = empezar por aquí.

### IntelliBanks (vault de conocimiento · dashboards · registry)
| Loop | Por qué encaja | Goal |
|---|---|---|
| **001 Docs sweep** ⭐ | Mantener el registry y la documentación del vault sincronizados con los activos reales (ya es un dolor que atacamos con skills) | LLM-judge |
| **012 Repository cleanup** ⭐ | Higiene del vault: archivos huérfanos/volados, versiones stale (espejo del vault-orphan-rescue) | Verifiable |
| **003 Sub-50 ms page-load** | Para los dashboards/visualizadores cuando vivan como app con rutas (no HTML suelto) | Verifiable |
| **010 Full product evaluation** | Evaluar la experiencia de consulta del IntelliBank (¿encuentra el usuario lo que busca?) | LLM-judge |
| **007 Logging coverage** | Si hay capa de app/MCP sobre el vault, trazar accesos y fallas | LLM-judge |

### Rebelocity Club (comunidad · RClub · puntos/membresías · eventos · Njuko→GHL)
| Loop | Por qué encaja | Goal |
|---|---|---|
| **003 Sub-50 ms page-load** ⭐ | La plataforma de comunidad/portal del miembro debe sentirse instantánea | Verifiable |
| **004 Production error sweep** ⭐ | Confiabilidad de inscripción/pagos/eventos (flujo Njuko→GHL) — cero errores sin atender | Verifiable |
| **007 Logging coverage** | Trazar el pipeline Njuko→GHL de punta a punta para diagnosticar fallas | LLM-judge |
| **014 Production data cleanup** | Limpiar datos de miembros/inscripciones que no cumplen la definición | Verifiable |
| **010 Full product evaluation** | Evaluar el onboarding gamificado y el journey del miembro | LLM-judge |
| **017 Customer AI deployment** | Meter workflows IA (recordatorios, enriquecimiento, soporte) con aprobaciones y ROI | Verifiable |

### MasterPlaybooks (reader · catálogo · MPI · plataforma pública)
| Loop | Por qué encaja | Goal |
|---|---|---|
| **006 SEO/GEO visibility** ⭐ | Es plataforma pública de contenido — descubribilidad en buscadores Y motores de respuesta IA es crítica | Verifiable |
| **003 Sub-50 ms page-load** ⭐ | El reader y el catálogo deben cargar instantáneo (retención + SEO) | Verifiable |
| **010 Full product evaluation** | Evaluar la experiencia del reader/MPI con escenarios realistas | LLM-judge |
| **001 Docs sweep** | Mantener catálogo y docs de la plataforma al día | LLM-judge |
| **008 Nightly changelog / 018 Podcast** | La factoría editorial comunica novedades a usuarios | Verifiable / judge |
| **004 Production error sweep** | Confiabilidad del reader/checkout | Verifiable |

**Patrón transversal (las 3 apps):** monta primero el **harness de medición** (rutas + benchmark reproducible) → corre **003 sub-50ms** como acción en cada PR → suma **004 error sweep** y **007 logging** nocturnos → **010 full product eval** semanal. Es el "kit de loops base" de cualquier app del ecosistema.

---

## §7 · Caveats (dilos al equipo antes de soltarlos)

1. **No sirve para construir features desde cero.** Berman: *"no he encontrado forma de construir features con loops."* El loop es para metas con check claro (optimizar, cubrir, limpiar, evaluar), no para "construye el sistema de permisos completo" (no sabes qué dirección tomará). El ejemplo del clon de Excel corrió **días** y tuvo que detenerlo.
2. **Los loops son caros.** Queman tokens autónomamente hasta cumplir la meta — de 10 minutos a días. Para "token-maxers" son fantásticos; con presupuesto limitado, vigílalos. **Define presupuesto y estado terminal "agotado".**
3. **LLM-as-judge es frágil.** Cuando el modelo decide si la meta se cumplió, dejas gusto/juicio al modelo. Prefiere metas **verifiables**; reserva judge para refactor/calidad con rúbrica.
4. **Guardrails de producción.** Acciones destructivas, irreversibles, de producción, financieras, de privacidad o de mensajes externos **requieren aprobación humana explícita**. Diseñar el loop **no** autoriza activarlo en prod.
5. **La mayoría de las tareas NO necesitan un loop** (Nate Herk). El loop justifica su costo solo cuando el primer intento probablemente no será el final Y hay un check claro. No montar flotas 24/7 por moda — **eso escala bugs**. Regla: si ningún feedback nuevo cambiaría la siguiente acción, usa un one-shot, no un loop.
6. **Anti-cargo-cult.** Que Cherny/Steinberger corran loops 24/7 no significa que aplique a EmpowerLabs. Empezar por loops por-cadencia o por-evento (no continuos), medir valor real, y escalar solo lo que mueve la aguja.

---

## §8 · No confundir con MacroLoopX

- **MacroLoopX** ([[PP-EL-LoopX-MacroLoopX-Arquitectura-v01]]) = los **5 business-loops** del negocio (Productización → DemandGen → Ventas → Operación → Mejora). Orquestan la empresa.
- **Loop Engineering** (este playbook) = **engineering-loops**: agentes de código que iteran hacia una meta técnica verificable. **Viven dentro del LoopXOP (Operación/Delivery)** y de la factoría de desarrollo — son una *técnica de ejecución*, no un business-loop. Mismo apellido ("loop"), capa distinta.

---

## §9 · Gobernanza WORX para loops

- **Tripleta** por cada loop que se institucionaliza: Owner (dev) + Sherpa + Ratificador (Victor para los que tocan prod).
- **Matriz de autonomía** (hereda de MacroLoopX §4.2): bajo riesgo/alto volumen → agente autónomo, audita por muestreo; alto riesgo (prod, datos, releases) → **humano decide siempre**, human-above-the-loop.
- **Verificación independiente** para output de alto impacto (loop 020 Loop Harness / 019 Clodex): el que genera no aprueba.
- **Vault-First:** cada loop institucionalizado se documenta como activo (prompt + trigger + goal + guardrails) en el banco de la app.

---

## §10 · Quick start para el equipo (esta semana)

1. **Instalar el skill:** `npx skills add Forward-Future/loop-library --skill loop-library -g`.
2. **Elegir 1 app piloto** (sugerencia: MasterPlaybooks o RClub, que son web públicas).
3. **Montar el harness** de page-load (rutas + benchmark reproducible).
4. **Correr el loop 003 sub-50ms** manualmente la primera vez; observar; luego ponerlo como **action en cada PR**.
5. **Sumar 004 (error sweep)** y **007 (logging)** como loops nocturnos.
6. **Documentar** cada loop institucionalizado como activo en el banco de la app (Vault-First) + reportar aprendizajes a LoopXKZ (CAS-/IDE-).

---

## §11 · Estado del arte de Loops (investigación profunda + fuentes)

> Esto ubica los 2 videos en el mapa real. Lo que Berman y Herk explican es la **punta divulgativa** de un cuerpo más profundo — académico e industrial. Conviene que el equipo lo conozca para no quedarse en el "tip de YouTube".

### 11.1 Origen del término (jun-2026)
"Loop engineering" no nació en los videos. Cronología verificada: **Peter Steinberger** lo lanzó en X el **7-jun-2026** ("ya no deberías promptear agentes; deberías diseñar los loops que los promptean"); **Addy Osmani (Google, Director Cloud AI)** lo nombró y estructuró ese mismo día en su ensayo *Loop Engineering*; ambos haciendo eco de **Boris Cherny (head de Claude Code, Anthropic)**: *"ya no prompteo a Claude; tengo loops que lo promptean… mi trabajo es escribir loops."* Berman y Herk vinieron después, divulgando.

### 11.2 El linaje académico (de dónde sale esto realmente)
| Raíz | Aporte | Relevancia |
|---|---|---|
| **OODA loop** (John Boyd, militar) | Observe-Orient-Decide-Act como flywheel de decisión | El ancestro conceptual (también citado por ExO/Salim) |
| **ReAct** (Yao et al., 2023) | Intercalar *razonar* y *actuar* paso a paso | El "reason→act→observe" de Herk es esto |
| **Reflexion** (Shinn et al., 2023) | RL verbal: Actor + **Evaluador** + Auto-reflexión; basta señal coarse éxito/falla | El núcleo del "verify + iterate" — el agente aprende de su propia crítica |
| **Self-Refine** | generar → criticar → refinar | El bucle de mejora de calidad de Nate (curva attempts×quality) |
| **Anthropic — Building Effective Agents** (dic-2024) | Patrón **evaluator-optimizer**: un LLM genera, otro evalúa, repite hasta criterio | El fundamento del "maker-checker" y del `/goal` |
| **RLVR** (RL with Verifiable Rewards) | Entrenar/operar contra recompensas verificables | Por qué los goals **verifiables** son superiores a LLM-as-judge |

### 11.3 Las 5 piezas de un loop (Addy Osmani — más riguroso que el catálogo)
Un loop de producción se arma con 5 primitivos + memoria (mapea 1:1 a Codex y Claude Code):
1. **Automations** (el "latido": discovery+triage en cadencia · `/loop`, cron, hooks, GitHub Actions)
2. **Worktrees** (aislar agentes en paralelo · `git worktree`, `isolation: worktree`)
3. **Skills** (`SKILL.md` — codificar el conocimiento del proyecto para que el agente no adivine)
4. **Plugins/Connectors (MCP)** (conectar el loop a tus herramientas reales: issues, DB, Slack)
5. **Sub-agents** (uno propone, **otro verifica** — el maker-checker)
+ **Memoria/estado en disco** (markdown/Linear — "el agente olvida; el repo no").
> `/goal` = corre hasta una **condición verificable**, y un modelo *separado* juzga si terminó (maker-checker aplicado al stop). `/loop` = re-corre en cadencia.

### 11.4 Técnicas y herramientas del ecosistema
- **Ralph Wiggum loop** (Geoffrey Huntley): el loop en su forma más cruda — `while :; do cat PROMPT.md | claude-code; done`. La clave es el **reset de contexto**: cada iteración es un agente nuevo con contexto limpio que lee el estado del repo desde disco, hace una unidad de trabajo, commitea y sale. Reportó un MVP cotizado en $50K hecho con **$297 en tokens** (~170x). Implementación de referencia: `vercel-labs/ralph-loop-agent`.
- **Loop Library** (Forward Future/Berman) — catálogo de loops (§4).
- **loop-engineering toolkit** (Cobus Greyling): `loop-audit`, `loop-init`, `loop-cost` — herramientas para auditar/iniciar/costear loops.
- Primitivos nativos: `/goal` y `/loop` en **Codex** y **Claude Code**.

### 11.5 La cara crítica (lo que la divulgación minimiza)
- **Reward hacking / specification gaming**: el agente puede subir la métrica reportada sin mejorar la calidad real (arxiv 2402.06627 *In-Context Reward Hacking*; *RewardHackingAgents* 2603.11337). **Implicación:** separa la señal de trabajo del gate de aceptación fresco (ya lo dice la SKILL.md).
- **LLM-as-judge es manipulable**: los modelos-juez pequeños son vulnerables a "false positives" por formato engañoso; las recompensas holísticas/sparse se hackean más fácil. **Implicación:** usa juez fuerte e independiente, o mejor, goal verificable.
- **OODA loop problem** (Schneier, 2025): a mayor autonomía, mayor superficie de ataque y de gobernanza.
- **Comprehension debt + cognitive surrender** (Osmani): mientras más rápido el loop produce código que no escribiste, más crece la brecha entre lo que existe y lo que entiendes. *"Dos personas arman el mismo loop y obtienen resultados opuestos: una lo usa para ir más rápido en lo que entiende; la otra para evitar entender. El loop no sabe la diferencia. Tú sí."*

### 11.6 Dónde se para EmpowerLabs
Nuestra ventaja: ya tenemos **Skills (vault) + Memoria en disco (IntelliBanks/XDoc) + Sub-agents/Sherpas + Gobernanza WORX** — 4 de las 5 piezas de Osmani ya instaladas. El gap es **Automations** (cadencia/hooks) y los **harness de verificación** por app. Loop Engineering no es algo que adoptamos de cero: es **formalizar y poner cadencia** a lo que el ecosistema ya hace.

### 11.7 Bibliografía (citable)
- Osmani, A. — *Loop Engineering* (addyosmani.com/blog/loop-engineering) · *Agent Skills*, *Long-running Agents*, *Comprehension Debt*, *Cognitive Surrender*.
- Anthropic — *Building Effective Agents* (anthropic.com/news/building-effective-agents) + *Building Agents with the Claude Agent SDK*.
- Shinn et al. — *Reflexion: Language Agents with Verbal Reinforcement Learning* (arXiv 2303.11366).
- Yao et al. — *ReAct: Synergizing Reasoning and Acting in Language Models* (arXiv 2210.03629).
- Huntley, G. — *Ralph Wiggum as a software engineer* (ghuntley.com/ralph) · *everything is a ralph loop*.
- Forward Future / Berman — *Loop Library* (signals.forwardfuture.ai/loop-library) · repo `Forward-Future/loop-library`.
- Greyling, C. — *Loop Engineering* (toolkit `cobusgreyling/loop-engineering`).
- Schneier, B. — *Agentic AI's OODA Loop Problem* (2025).
- arXiv — *In-Context Reward Hacking* (2402.06627); *RewardHackingAgents* (2603.11337); *Landscape of Agentic RL for LLMs* (2509.02547).
- The New Stack — *Loop Engineering* (Cherny/Anthropic).

---

## NEXT

| NEXT | Asignado | Eje |
|---|---|---|
| Ratificar este playbook y elegir la app piloto | Victor | Dev / Estrategia |
| Instalar el loop-library skill en el entorno del equipo dev | Equipo dev | Setup |
| Montar el harness de performance de la app piloto (prerequisito del 003) | Equipo dev | Infra |
| Institucionalizar el "kit base" (003 + 004 + 007 + 010) por app, documentado en su banco | Jay + dev | Producción |
| Decidir presupuesto de tokens y política de aprobación para loops en prod | Victor | Gobernanza |
| Sembrar ideas derivadas en el Idea Bank (loop-as-service para clientes HIOrg/DemandGenPack) | Jay | Idea Bank |

## CHANGELOG

| Fecha | Cambio | Por |
|---|---|---|
| 2026-06-13 | Creación. Playbook de Loop Engineering desde Forward Future (Matthew Berman · Loop Library MIT). Definición, anatomía (trigger+goal, ciclo 6 pasos, terminal states), 4 rutas, catálogo de 31 loops, caveats, mapeo a IntelliBanks/Rebelocity/MasterPlaybooks (foco sub-50ms), distinción vs MacroLoopX, gobernanza WORX y quick start. | Jay |
| 2026-06-13 | v01.1 — Validada e integrada 2da fuente (Nate Herk · youtube EuzYhzB0vbI). +§0.1 validación comparativa de las 2 fuentes (verificada atribución Cherny/Anthropic + origen Addy Osmani/Google; desliz "Steinberger en OpenAI" marcado). +§3.5 topologías (solo / maker-checker / manager-helpers) + checklist de 8 ingredientes + 2 preguntas del done-check. +caveats 5-6 (la mayoría de tareas no necesitan loop · anti-cargo-cult). | Jay |
| 2026-06-13 | v01.2 — Investigación profunda del estado del arte (+§11): origen verificado (Steinberger→Osmani→Cherny, 7-jun-2026), linaje académico (OODA·ReAct·Reflexion·Self-Refine·evaluator-optimizer·RLVR), las 5 piezas de Osmani, técnica Ralph (Huntley), toolkit Greyling, cara crítica (reward hacking · LLM-as-judge frágil · comprehension debt) y bibliografía citable. Dónde se para EmpowerLabs (4/5 piezas ya instaladas). | Jay |