De prompter a loop designer: el roadmap de 10 pasos

### 01. Un loop es un prompt en un timer

Sacale el misticismo y un loop es una sola idea: en vez de que vos mandes el próximo prompt, lo manda el sistema. Corre el agente, mira el resultado, decide si el trabajo está terminado, y si no, lo corre de vuelta.

Un while loop con un modelo adentro.

` Timer → Prompt → Agente corre → Chequea contra objetivo → Listo `

Ese cambio de marco mental es TODO el shift de prompter a diseñador. El prompter optimiza el mensaje individual. El diseñador optimiza el ciclo: qué lo dispara, qué lo frena, qué recuerda entre vueltas. Una vez que ves al agente como un loop y no como un chat, cada paso siguiente es simplemente darle forma a una parte de ese ciclo.

Cuando armé el ADMP triage pipeline, lo primero que hice fue definir el ciclo: llega un mensaje con "AAA", se fetchea contenido de X, se analiza, se guarda en Sheets, se responde con menú de outputs. Todo automático. Yo solo veo el resultado final y elijo qué output generar. El loop ya hizo el 80% del trabajo antes de que yo toque una tecla.

### 02. El harness va primero

Un loop es tan bueno como el entorno donde corre. Ese entorno es el harness: el modelo, las herramientas que puede usar, los permisos sobre esas herramientas, y el contexto que lee al inicio de cada corrida.

Envolvé un loop alrededor de un harness débil y no obtenés autonomía — obtenés basura, pero más rápido.

Antes de automatizar nada, una corrida manual tiene que funcionar perfecto. Un CLAUDE.md con hechos estables, un objetivo de verificación claro, las herramientas correctas conectadas. El loop reusa todo eso en cada iteración. Cada debilidad del harness se multiplica por la cantidad de veces que el loop corre.

Este es probablemente el error más común que veo. Gente que arma loops sin haber logrado que una sola corrida manual funcione bien. Es como construir una fábrica antes de saber si el prototipo anda. El Content-OS que armé pasó semanas corriendo manual antes de que lo pusiera en cron. Cada viernes yo ejecutaba el pipeline a mano. Cuando estuvo sólido, lo puse en un timer y nunca más lo toqué.

### 03. Self-improving es el sistema, no el modelo

La frase "agente que se auto-mejora" invita a un malentendido que conviene matar temprano. El modelo no está aprendiendo. Sus pesos no cambian entre tus corridas.

Lo que mejora es el sistema alrededor: la memoria que acumula, los skills que se afilan a medida que se agregan edge cases, el grader que lo mantiene honesto. Esta es la versión honesta de la idea, y es importante porque te dice dónde poner el trabajo. No estás esperando que el modelo se vuelva más inteligente. Estás construyendo un entorno que se vuelve más inteligente, corrida tras corrida, con el mismo modelo en el centro todo el tiempo.

Mis loops no son más inteligentes que hace 6 meses porque el modelo mejoró. Son más inteligentes porque los skills tienen más edge cases cubiertos, la memoria tiene más patrones detectados, y sé exactamente qué herramientas darle a cada parte del ciclo.

### 04. Definí un objetivo y un grader independiente

Un loop necesita una condición de freno que no sea "el agente siente que terminó". /goal te da una: un objetivo contra el que el loop itera hasta que un chequeo independiente dice que se cumplió.

La palabra clave es independiente. Lo que decide "listo" no debería ser lo mismo que hizo el trabajo. Esa separación es lo que hace que un loop sea confiable en vez de una máquina que se felicita a sí misma.

En el ADMP triage, el "grader" es la combinación de reglas: ¿el contenido se clasificó correctamente? ¿Los hooks son específicos o genéricos? ¿El strategic value está bien asignado? El loop no se auto-califica — las reglas están definidas de antemano y el sistema las chequea.

### 05. Separá el maker del checker

La razón por la que un grader separado le gana al self-review es estructural, no de esfuerzo. Un modelo juzgando su propio output ve su propio razonamiento y prefiere conclusiones consistentes con lo que ya escribió.

Un agente separado, con su propio context window fresco, ve solo el artefacto y el estándar. No tiene interés en las decisiones del maker.

Definí un verificador como subagente. Ahora el loop tiene un maker y un checker, y el checker es el que tiene la llave.

En Content-OS, esto es literal: el writer genera el draft, y el sistema corre el verifier (6 preguntas binarias) + la rúbrica de bookmarkability (12 puntos). Si no pasa 4/6 y 8/12, no se publica. Punto. El writer no se califica a sí mismo.

### 06. Ponelo en un timer, después en la nube

Una corrida goal-driven todavía espera que la arranques. El próximo movimiento es una cadencia. /loop re-ejecuta un prompt en un intervalo, así el agente avanza sobre un backlog en vez de esperar que un humano tipee.

Después sacá tu laptop de la ecuación. Las cloud routines corren una configuración guardada en infraestructura gestionada, con la máquina apagada.

Un timer convierte una corrida en un hábito. La nube convierte el hábito en infraestructura.

Mi GSC loop corre todos los días a las 7am, fetchea datos de Search Console para dos dominios, compara contra el estado anterior, y me reporta solo si hay cambios. Cuando no hay novedades, silencio absoluto. Hace 6 meses que no toco ese cron job. Funciona solo.

### 07. Componé los difíciles con workflows

Algunos trabajos son demasiado estructurados para un solo loop: masivamente paralelos, multi-etapa, o que necesitan varias perspectivas independientes. Para esos, el agente escribe su propio plan de orquestación y lo sigue estrictamente.

Tres formas ganan su lugar en la mayoría de los loops: fan out and synthesize (dividir trabajo, correr en paralelo, combinar), verificación adversarial (un maker y un checker independiente por tarea), y loop hasta que una condición de freno se cumpla. El workflow es tan bueno como los subagentes y skills que puede llamar.

### 08. Dale memoria al loop

Este es el paso que convierte un loop configurado en un sistema que mejora. El agente olvida todo entre corridas. El loop no tiene por qué.

Un state file registra qué se intentó, qué funcionó, qué falló, y qué sobrevivió como regla. Dos reglas hacen que haga compound en vez de solo crecer: escribir antes de irse (cada corrida termina actualizando el archivo) y leer al empezar (cada corrida arranca cargándolo). Si salteás cualquiera de las dos, mañana arranca de cero.

Mi GSC loop mantiene un gsc_loop_state.json que trackea qué queries están en striking distance, cuáles están en declive, y qué acciones ya se tomaron. Sin ese archivo, cada corrida sería la primera corrida.

### 09. Destilá lecciones en skills

Un state file es memoria de proyecto. Muere con el proyecto. Las lecciones que son generales — las que ayudarían en el próximo proyecto también — se gradúan a skills: procedimientos que el agente corre, y que se afilan cada vez que fallan de una forma nueva.

Cuando un loop choca contra una pared, la lección va al skill, y todo loop futuro en todo proyecto futuro la hereda. Esa es la diferencia entre un agente que re-deriva tu entorno cada vez y uno que se para sobre todo lo que aprendió antes.

Esto es exactamente lo que hago con los skills de Hermes. Cada vez que un loop falla de una forma nueva, el edge case va al SKILL.md. La próxima corrida en cualquier proyecto ya sabe cómo manejarlo.

### 10. Cerrá el loop, y hacelo fail safe

Ahora las piezas se traban entre sí. Cada corrida produce output. El verificador lo califica. El veredicto se escribe en memoria. Las lecciones generales se destilan en skills. La próxima corrida hereda skills más afilados y memoria más rica. El modelo nunca cambió. El sistema alrededor se volvió más filoso. Eso es lo que "self-improving" significa honestamente.

Un loop autónomo también tiene que fallar de forma segura, porque nadie está mirando cada iteración. Para eso existen los guardrails: paredes que el modelo no puede hablar para atravesar. Un hook es un límite duro, no una sugerencia. Ruteá el trabajo por costo: el orquestador en el modelo pesado, los pases de alto volumen en modelos más baratos, y un fallback para tareas que el tier top rechaza.

Un loop que corre solo y no puede hacer nada irreversible es uno que podés dejar andando sin miedo.