Alex Prompter corre con presupuesto. Como la mayoría. Estos son los cinco plays que usa en lugar de un loop genérico. Los probé. Funcionan.
### 1. Pensar antes de gastar tokens
La mayoría del costo de un loop se va en recuperación. El agente arranca con una instrucción vaga. Adivina qué quisiste decir. Deriva. Y quema turnos corrigiendo la deriva que él mismo generó.
La alternativa: decirle exactamente qué querés. Archivos a tocar. Estructura esperada. Lo que NO debería hacer. Esto no es "ser más específico". Es darte cuenta de que el 70% del gasto de un loop viene de no haber pensado cinco minutos antes de soltar al agente.
En Hermes hacemos esto con los briefs. Antes de disparar el writer, ya definimos tesis, estructura, datos clave y tono. El agente no adivina. Ejecuta. Un brief de 200 palabras te ahorra 10 turnos de corrección.
### 2. Planificar en markdown antes de codear
Escribí el plan en markdown. Archivos. Dependencias. Orden de implementación. Qué va en cada módulo.
El plan te cuesta un turno. El loop sin plan te cuesta diez.
Esto aplica a código, pero también a contenido. Cuando arranco un artículo en Content-OS, primero va el brief. Después el draft. Nunca al revés. Un plan malo pero escrito es mejor que un plan excelente en tu cabeza.
### 3. Agentes especializados en vez de un loop genérico
Un agente que sabe de frontend. Otro de backend. Otro de tests. Cada uno hace una cosa y la hace bien.
No hay deriva porque no hay ambigüedad. El agente de frontend no se mete con la base de datos. El de tests no rediseña la UI.
En mi stack, Hermes orquesta pero no ejecuta todo. OpenClawAir toma tareas pesadas de código. Content-Writer solo escribe. Content Scout solo busca. Cada agente con un scope definido, sin permiso para irse del carril.
### 4. Tests como condición de salida
El loop para cuando los tests pasan. Sin tests, el agente puede dar vueltas 40 turnos "verificando" sin entregar nada.
La condición de salida explícita es lo que separa un loop de una hemorragia de tokens.
En contenido aplico lo mismo pero con checklist. El verifier tiene 6 checks binarios. Si el draft no pasa 4 de 6, no se publica. Sin checklist, el agente podría reescribir párrafos infinitamente persiguiendo una versión "mejor" que no existe.
### 5. Review humano en puntos clave
No hace falta revisar cada línea. Pero sí en dos o tres checkpoints: después del plan, después de la primera implementación, antes del deploy.
El agente es rápido. El humano es criterio. La combinación es imbatible.
En mi flujo de publicación, los únicos checkpoints con intervención humana son: ¿el ángulo tiene sentido? ¿Los datos son reales? ¿Suena a mí? Tres preguntas. Treinta segundos cada una. Lo demás lo resuelve el sistema solo.
