La semana pasada, Tom Osman publicó algo que acumuló 1.1 millones de visualizaciones en X. No era una demo de un modelo nuevo. Era una instrucción de una sola entrada que le dio a su agente en Codex: define el objetivo, catalogar cada funcionalidad de la plataforma como una historia de usuario, seguir con un loop de prueba de cada historia, luego corregir cada error. Solo.

El resultado: 183 historias de usuario, 105 rutas de página y semanas de QA manual automatizadas en un solo ciclo nocturno.

Lo que hizo Osman no es prompt engineering avanzado. Es algo cualitativamente distinto. Dejó de ser el que escribe prompts y se convirtió en el que construye el sistema que escribe prompts por él. Esa es la tesis de este post, y es la misma que LangChain articuló en el esquema de cuatro loops que publicó la semana pasada.

Loop 1: el agente que ya tienes

El primer loop es el que casi todo el mundo tiene: el agente llama una herramienta, lee el resultado, llama otra herramienta y sigue hasta que termina la tarea. Le das contexto, le das herramientas, lo dejas correr hasta que dice que terminó.

LangChain lo llama el primitivo base, y la descripción más honesta que encontré para este nivel es que es un autocompletado más caro. Si tu uso de IA se queda aquí, lo que tienes es una ventana de chat con pasos. Útil, pero no es el cambio de categoría que prometen los titulares.

Loop 2: el que verifica sin que tú estés

El segundo loop es donde empieza a ponerse interesante. El agente termina una tarea y en lugar de presentarte el resultado para que tú lo apruebes, un calificador lo revisa contra un criterio. Si no pasa la calificación, la retroalimentación vuelve al agente y reintenta. Sin intervención humana.

Hay dos tipos de verificación: determinista para lo objetivo (¿el enlace resuelve?, ¿el CI pasa?, ¿el scope coincide con la instrucción?) y criterio de LLM como juez para lo subjetivo (¿respondió la pregunta?, ¿el tono es correcto?, ¿la solución es segura?). El costo es real: 2 o 3 veces más tokens por tarea. Y el argumento que hace LangChain es correcto: una respuesta incorrecta en producción cuesta más que mil reintentos automatizados.

El loop 2 es donde el 90% de los equipos se detiene. Y es exactamente donde está la mayor parte del valor sin capturar, lo que conecta con el argumento de los agentes autónomos en LatAm: la verificación automática es lo que convierte un piloto en algo que puede escalar.

Loop 3: el que nadie tiene que invocar

El loop 3 hace algo cualitativamente distinto: el agente deja de esperar que alguien lo llame. Un mensaje en un canal de Slack lo activa. Un webhook de una integración lo activa. Un cron de las 3am lo activa. Nadie abre una terminal, nadie hace clic en un botón.

Aquí el agente deja de ser una herramienta que visitas y se convierte en algo que vive dentro de los sistemas donde el trabajo ya ocurre. Como lo argumenté en la IA como infraestructura: la infraestructura no se visita, está debajo de todo lo que ya haces. El loop 3 es el momento en que el agente se vuelve infraestructura.

Loop 4: el que se reescribe solo

El cuarto loop es el que Osman activó y el que causa la mayor incredulidad cuando lo describes. Cada ejecución deja un rastro. Un agente de análisis lee esos rastros, identifica los patrones de falla recurrentes, los sesgos sistemáticos, los tipos de tarea donde el agente bajo-rinde, y reescribe el prompt y la configuración del loop 1.

Al día siguiente, el agente empieza con una versión mejorada de sus propias instrucciones. Sin que nadie haya tocado el código. Sin que nadie haya analizado los logs manualmente.

La matemática que circula sobre esto es simple: una mejora del 1% diaria compone a 37 veces en un año. 1.01^365 = 37.8. Los detalles de cómo se mide esa mejora y cómo se valida que no está empezando en ninguna dirección son reales y requieren trabajo, pero el principio es correcto. El agente con loop 4 es cualitativamente distinto al agente que entregaste el primer día.

Lo que esto significa para construir con IA

La pregunta que más debería preocuparte en IA no es “¿qué modelo uso?” sino “¿en qué nivel de loop estoy operando, y qué me impide subir al siguiente?”. El modelo es intercambiable. El sistema de loops que construyes alrededor del modelo es lo que compone valor con el tiempo.

El harness que mantiene el agente honesto, lo hace verificar su propio output, lo activa por eventos y lo hace mejorar con sus propios rastros: eso es lo que no se compra en una suscripción. Como lo argumenté en el harness es el moat: el modelo es commodity, lo que construyes a su alrededor no lo es.

En IQ Source, lo que construimos en la fase de implementación de AI Maestro no es un agente con loop 1. Es el sistema de loops completo, con verificación, activación por eventos y trazabilidad para el loop de mejora. La diferencia entre un piloto que impresiona y un agente que sigue mejorando después de que nosotros nos vamos es exactamente la diferencia entre loop 1 y loop 4.

Construye el sistema de loops, no solo el agente