Qué ver: ocho herramientas que, juntas, forman un loop confiable. No son una por una: es el kit completo. Cada sección de abajo es una pieza; un loop sólido las tiene todas encajadas.
🎯 Objetivo verificable
El ingrediente número uno: define "listo" de una manera que una máquina pueda verificarlo: no "dejarlo bien". Si el propio loop no puede mirar el resultado y responder sí o no, nunca sabrá cuándo detenerse.
Lee el diagrama: las ocho piezas no compiten: se suman en un solo loop. Si falta una de las ocho, el loop queda frágil justo en ese punto.
✓ Verificable por máquina
- ✓"Todas las pruebas en /tests pasan al ejecutar
npm test." - ✓«Menos de 50 palabras Y menciona el precio».
- ✓«El script se ejecuta sin errores y genera el CSV».
✗ Solo tú sabes evaluarlo
- ✗«Déjalo bien».
- ✗«Mejora el texto».
- ✗«Limpia esto».
🛑 Parada obligatoria
Todo loop necesita una parada forzada: máximo de intentos, presupuesto de tokens o tiempo. Siempre. Es lo que impide que el agente se ejecute para siempre cuando no logra alcanzar el objetivo.
# Três sabores de hard stop — escolha o que cabe na sua tarefa
Pare quando todos os testes passarem, OU após 10 tentativas. # máx. tentativas
Pare quando o objetivo for atingido, OU após gastar 50k tokens. # orçamento
Pare quando terminar, OU após 15 minutos de execução. # tempoCómo verificar: lee tu prompt y busca la palabra "o". Si no hay un límite además del objetivo, el loop no tiene freno: agrega uno antes de ejecutarlo.
🧠 Por qué «siempre»
Un loop sin límite es la principal fuente de sorpresas: o se queda atascado repitiendo la misma corrección, o consume una cuenta de tokens mientras duermes. Es barato escribir el límite estricto y caro olvidarlo.
🔧 Buenas herramientas
Las acciones que el agente puede realizar deben ser confiables e descritas claramente. Una herramienta que falla en silencio o cuyo nombre no indica lo que hace se convierte en ruido que confunde al loop.
💡 La artesanía está en las herramientas
Anthropic es directa: «es crucial diseñar conjuntos de herramientas y su documentación con claridad». El loop en sí es trivial; el verdadero trabajo está en cuáles herramientas tiene el agente y qué tan bien descritas están.
✓ Buena herramienta
- ✓El nombre dice lo que hace:
rodar_testes. - ✓Devuelve el resultado real (salida, código de error).
- ✓Falla de una forma que el agente entiende.
✗ Mala herramienta
- ✗Nombre vago:
processar. - ✗El éxito y el fracaso parecen iguales.
- ✗Hace demasiadas cosas a la vez.
🧠 Memoria
Guarda el historial de lo que ya se intentó, pero resume, no acumules todo. Un archivo breve de notas que el agente vuelve a leer es mejor que volcar cada paso de nuevo en el contexto, que se infla y se vuelve caro.
🧩 Resumir > acumular
Un buen patrón: el agente mantiene un PROGRESS.md con 3–5 líneas: qué ya funciona, qué falta todavía, qué NO repetir. En cada vuelta relee este resumen en vez del registro completo. La memoria que cabe en un párrafo sobrevive entre sesiones; un historial gigante no.
✅ Un checker independiente
Separa a quien hace de quien juzga: generar → juzgar → corregir → repetir. El agente que produce el trabajo nunca debe calificarse a sí mismo: un evaluador independiente es mucho más honesto.
Lee el diagrama: el maker genera, el checker juzga. Si lo rechaza, vuelve para corregirlo; si lo aprueba, está listo. Como son roles separados, el «aprobado» significa algo de verdad.
¿Por qué el maker no debería ponerse su propia nota?
🗺️ ¿Planificar primero?
No todos los loops necesitan un plan. Para un job grande y de varios pasos, pide un plan antes de actuar, así el agente no se pierde a mitad de camino. Para un trabajo pequeño, omite el plan: solo causa demoras.
✓ Planifica primero cuando…
- ✓La tarea tiene muchos pasos dependientes.
- ✓Equivocarse al principio sale caro más adelante.
- ✓Quieres revisar el proceso antes de que actúe el agente.
↩ Omite el plan cuando…
- ·Es una corrección pequeña y directa.
- ·El camino es obvio: ejecutar → leer → corregir.
- ·Planificar tomaría más tiempo que simplemente hacerlo.
🧾 Logging
Guarda cada pensamiento, acción y resultado del bucle. Cuando algo salga mal — y saldrá — el registro te permite entender qué pasó, incluso a las 3 de la mañana, sin haberlo seguido todo en vivo.
🔍 El log es tu cámara de seguridad
Sin log, un loop que falló es una caja negra: solo ves el resultado roto, no el camino hasta llegar a él. Con log, lees la secuencia de decisiones, encuentras dónde salió mal y corriges el instrucción — no la salida.
qué pensó
qué hizo
qué resultó
💸 Cost sense
Los loops consumen tokens rápido — cada iteración es una nueva llamada al modelo. Empieza con algo pequeño y limitado: una tarea breve, pocos intentos. Solo cuando funcione, amplía el alcance y el límite.
🧩 Pequeño primero, siempre
La intuición sobre el costo importa porque el precio sube de forma invisible: 10 vueltas × contexto grande × modelo caro se convierte en una cuenta sorpresa. Empieza con un max_turns bajo y una tarea pequeña; mira cuánto costó una vuelta y luego decide si vale la pena escalar.
🚦 Haz esto / Omite esto (por ahora)
✓ Haz
- ✓Empieza con 1 tarea pequeña y repetible.
- ✓Define «listo» verificable por máquina.
- ✓Siempre incluye un máximo de intentos.
- ✓Usa un 2.º agente para evaluar trabajo importante.
✗ Sáltalo por ahora
- ✗Swarms 24/7 de 10 agentes creando prompts para 10.
- ✗Ejecutar sin condición de parada.
- ✗Confiar en "parece listo" sin una comprobación real.
- ✗Poner una en loop tarea de una sola vez.
🧾 Resumen del módulo
Siguiente:
3.4 — Los 8 errores comunes