Estructura mínima para montar agentes que no se queden dando vueltas.
Empezar con el test →La mayoría de empresas todavía usa la IA como si fuese un becario al que hay que dictarle cada paso. Le pides una cosa, revisas, corriges, vuelves a pedir. Sigues siendo tú quien opera el sistema.
Un loop cambia la relación. En vez de promptear cada paso, defines un objetivo, un ciclo de trabajo, una forma de comprobar si el resultado vale y una condición de parada. A partir de ahí, el agente ejecuta un circuito acotado.
Eso es Loop Engineering: diseñar el bucle donde trabaja el agente.
Un loop mal definido consume tokens, produce ruido y obliga a revisar más de lo que ahorra. Un loop bueno hace una tarea repetida, deja evidencia y se para antes de convertirse en un problema.
Antes de montar un loop, pasa este filtro. Marca lo que aplica a tu tarea.
Cuatro son obligatorias. Tres son las que evitan sustos.
Una frase concreta, observable y pequeña. Si cabe en una reunión estratégica, es demasiado grande. Si cabe en una tarea recurrente, empieza a tener forma de loop.
El agente necesita saber de dónde parte y dónde dejar rastro. Qué documentos puede usar, qué criterios respetar, qué decisiones ya están tomadas y dónde guardar el resultado.
Un loop sin estado repite trabajo. Con estado, el agente sabe qué hizo, qué falló y qué queda pendiente.
La secuencia que el agente repite. Si tiene veinte pasos, suele estar mal pensado. Una versión simple:
Cómo comprobamos si el output vale. Puede ser una prueba automática, una checklist o una revisión humana breve.
Sin eval, el loop genera cosas. Con eval, trabaja con criterio.
Cuando algo falla, el agente necesita saber qué hacer. Define una regla simple:
Lo que separa un loop útil de una máquina de gastar tokens. Un loop debe parar cuando:
Si no sabes cuándo debe parar, no debería empezar.
Hay acciones que se preparan, pero no se lanzan sin una persona delante. Requieren aprobación:
El loop hace el trabajo pesado. La responsabilidad sigue siendo tuya.
Usa esto como base cuando quieras diseñar un loop.
Nombre del loop: Objetivo: Qué resultado concreto tiene que conseguir el agente. Entrada: Qué información recibe en cada ciclo. Contexto: Qué documentos, criterios, reglas o herramientas puede usar. Ciclo: 1. 2. 3. 4. Eval: Cómo sabemos que el resultado es válido. Feedback: Qué hace si el resultado no pasa el eval. Condición de parada: Cuándo termina, cuándo reintenta y cuándo avisa. Salida: Dónde deja el resultado y con qué formato. Revisión humana: Qué acciones no puede ejecutar sin aprobación. Límite: Número máximo de vueltas, coste o tiempo permitido.
Buen primer loop: entrada clara, herramientas concretas, forma objetiva de comprobar si se resolvió.
El agente no tiene permiso para "arreglar el proyecto". Tiene permiso para investigar un fallo concreto, probar una hipótesis y dejar evidencia. Esa diferencia parece pequeña, pero cambia todo.
Un loop no es peor por ser pequeño. Normalmente es mejor.
Si alguien del equipo no puede explicar el proceso en cinco minutos, el agente tampoco lo va a arreglar. Solo le dará velocidad al desorden.
Sin respuesta a "cómo sabemos que esto está bien", el loop depende de que tú revises cada salida. Y entonces has vuelto al punto de partida.
Si el agente no deja rastro de lo que ha intentado, cada vuelta empieza desde cero. Consume tiempo, tokens y paciencia.
Un loop necesita un máximo de vueltas, un máximo de tiempo o una razón clara para parar. Sin eso, estás confiando en que el agente tenga prudencia. Mala idea.
Primero que prepare. Luego que proponga. Más adelante, si el proceso está probado, más autonomía. Saltarse ese orden suele salir caro.
No montes una plataforma. Monta esto.
Pequeño, limitado, revisable. Justo como debería empezar.
Mándame el proceso con este formato y lo revisamos juntos.
Proceso: Cada cuánto se repite: Quién lo hace ahora: Qué entrada recibe: Qué salida produce: Cómo sabes que está bien: Qué riesgo tendría si falla:
La IA no arregla el caos. Lo recorre más rápido.
Escribir a José en LinkedIn →