Ingeniería de loops: la habilidad que sustituyó silenciosamente al prompt engineering

Entonces, ¿qué es exactamente la ingeniería de loops?

Empecemos por lo que se está diseñando. Un agente de IA, reducido a su esencia, es "un LLM en un bucle while con herramientas." Recibe una entrada, el modelo razona qué hacer, invoca una herramienta, observa el resultado, y vuelve a empezar hasta que la tarea está hecha o se alcanza un límite. Ese ciclo es el bucle del agente de IA, y es la única característica que separa a un agente de un chatbot: un chatbot responde en un solo paso, un agente persiste y se adapta a lo largo de muchos pasos.

La ingeniería de loops es la disciplina de hacer que ese bucle sea fiable. Como dijo Simon Willison al bautizar la práctica:

"Mi definición preferida de un agente LLM es algo que ejecuta herramientas en un bucle para lograr un objetivo. El arte de usarlos bien está en diseñar cuidadosamente las herramientas y el bucle que van a usar."

Simon Willison, Designing agentic loops (septiembre de 2025)

La forma más clara de ver dónde encaja esto es fijarse en cómo ha crecido la disciplina por capas. El prompt engineering vino primero: escribir una buena instrucción. Luego el context engineering: curar todo el conjunto de tokens que el modelo ve en cada turno, no solo el prompt. La ingeniería de loops se sitúa por encima de ambas, diseña el sistema de tiempo de ejecución alrededor del modelo.

Anthropic describe la capa intermedia como "la progresión natural del prompt engineering", y la misma lógica se extiende un peldaño más:

"Un agente que se ejecuta en un bucle genera cada vez más datos que podrían ser relevantes para el siguiente turno de inferencia, y esa información debe refinarse cíclicamente."

Anthropic, Effective context engineering for AI agents

Así que la relación no es competitiva, es anidada. El prompt engineering optimiza una única llamada. El context engineering optimiza el estado que el modelo ve en cada turno. La ingeniería de loops optimiza la maquinaria que decide si el agente llega alguna vez a un buen estado. Si has leído nuestro artículo sobre prompt engineering, este es el siguiente piso.

Por qué el bucle se convirtió en la palanca, y no el prompt

Durante la mayor parte de 2023 y 2024, lo más inteligente que podías hacer era aprender a hablarle al modelo. Eso funcionaba porque los modelos respondían en un solo paso. En el momento en que empezaron a ejecutarse en bucles, invocar herramientas y actuar a lo largo de muchos pasos, el prompt dejó de ser el cuello de botella. Lo que más probablemente rompe a un agente hoy no es una instrucción mal redactada, sino un bucle sin interruptor de apagado, sin estrategia de memoria, o sin forma de comprobar su propio trabajo.

Solomon Hykes, el fundador de Docker, capturó el peligro en una frase que todo el sector cita ahora:

"Un agente de IA es un LLM destrozando su entorno en un bucle."

Solomon Hykes, vía Simon Willison (AI Engineer World's Fair, junio de 2025)

Ese es el replanteamiento. Un modelo más potente en un bucle mal diseñado es más peligroso, no menos, porque ejecuta sus malas ideas con más competencia. La comunidad de profesionales lo entendió rápido. En Hacker News, una de las publicaciones más votadas sobre el tema se titula, sin rodeos, "The canonical agent architecture: a while loop with tools", y otro hilo popular sobre la efectividad irrazonable de un bucle de agente LLM está lleno de gente sorprendida de lo bien que rinde un bucle simple una vez que el andamiaje alrededor está bien hecho.

LangChain lo resumió en una ecuación clara: Agente = Modelo + Harness.

"La ingeniería de harness consiste en construir sistemas alrededor de los modelos para convertirlos en motores de trabajo. El modelo contiene la inteligencia y el harness hace que esa inteligencia sea útil."

LangChain, The anatomy of an agent harness

Llámalo ingeniería de loops, ingeniería de harness, o codificación agéntica (las etiquetas todavía se están asentando), la idea es la misma: si no eres el modelo, eres el bucle, y ahí es donde vive ahora la ingeniería.

Las cinco palancas de un bucle bien diseñado

Si recorres a quienes están definiendo este campo, Willison, Anthropic, LangChain, Thoughtworks, el bucle se descompone siempre en el mismo puñado de palancas. Estos son los diales que realmente se giran.

1. Herramientas (la interfaz agente-computadora). Lo que el agente puede realmente hacer. Anthropic dedicó más tiempo a optimizar las herramientas que el prompt en su trabajo sobre SWE-bench, y acuñó el término ACI (interfaz agente-computadora), el equivalente del agente a una UI. Willison prefiere comandos de shell sencillos para agentes de codificación porque "los agentes de codificación son realmente buenos ejecutando comandos de shell."
2. Condiciones de parada. Cuándo se le permite al bucle terminar, por éxito, por un tope máximo de iteraciones, por un límite de presupuesto, o cuando detecta que no está progresando. Un bucle sin lógica de terminación o declara la victoria antes de tiempo o nunca se detiene. Anthropic: "también es habitual incluir condiciones de parada (como un número máximo de iteraciones) para mantener el control."
3. Gestión del contexto. Qué sobrevive entre turnos. Las técnicas aquí son la compactación (resumir y reiniciar cerca del límite de la ventana), la toma de notas (un NOTES.md que el agente mantiene fuera de su contexto), y los subagentes que consumen decenas de miles de tokens cada uno pero devuelven un resumen ajustado de 1.000 a 2.000 tokens. El motivo por el que importa: la capacidad de recordar se degrada a medida que crece el número de tokens, así que hay que curar activamente (ver nuestra nota sobre el tamaño de la ventana de contexto).
4. Verificación. Cómo demuestra el bucle que realmente hizo lo que tenía que hacer. Esta es la palanca más repetida de todas. Willison dice que el valor de un agente de codificación "se amplifica enormemente con una suite de pruebas buena y que pasa limpiamente." El harness de Anthropic para agentes de larga duración usa una lista de funciones en JSON con más de 200 funciones de extremo a extremo, cada una marcada inicialmente como passes: false, de modo que el agente no pueda marcar una función como completada sin demostrarlo.
5. Barreras de seguridad. Lo que impide que el bucle haga daño. Sandboxes, credenciales estrechamente acotadas y presupuestos. Willison le dio a Claude Code su propia organización en Fly.io con un presupuesto de 5 dólares para que un bucle descontrolado no pudiera gastar dinero real.

Cuando un agente se comporta mal, la solución casi siempre está en una de estas cinco, no en un prompt reformulado. Aquí está el diagnóstico rápido al que recurro:

Ingeniería de loops, pero para el soporte al cliente

Aquí está la parte que la mayoría de la cobertura centrada en codificación pasa por alto. La versión más clara del trabajo de un loop engineer en el mundo real no es construir una CLI de codificación, es hacer que un agente de IA funcione en una cola de soporte real, y lo digo como alguien que construye estos agentes para ganarse la vida.

Un ticket de soporte es un bucle casi perfecto. El agente percibe el mensaje entrante, razona sobre la intención, recupera lo que necesita (historial de pedidos, documentación, estado de la cuenta), ejecuta una acción (un reembolso, un restablecimiento, una actualización del ticket), verifica el resultado, y luego resuelve o transfiere a una persona. Anthropic señala el soporte como "un encaje natural para agentes más abiertos" precisamente porque el trabajo necesita tanto conversación como acción, con un éxito que "puede medirse claramente mediante resoluciones definidas por el usuario."

Y cada una de las cinco palancas se corresponde con una decisión de soporte que a los compradores les importa más de lo que creen. Llevamos más de tres años poniendo agentes de IA en colas de soporte en vivo, y lo que decide si un despliegue funciona nunca es lo ingenioso del prompt. Es el bucle. La versión más afilada de esto que he escuchado vino de una responsable de CX de una marca de suplementos DTC en Gorgias y Shopify, gestionando unos 7.000 tickets al mes, que nos dijo en una llamada:

"La IA nunca podrá responder al 100% de las preguntas... Necesito una IA que solo maneje los tickets en los que tenga confianza y que deje en paz todos los demás."

Eso es un requisito de ingeniería de loops expresado en lenguaje llano. "Solo maneja aquello de lo que estás seguro" es una condición de parada y una barrera de seguridad fusionadas en una, y fue la única característica que decidió su decisión de compra. Un bot que intenta responder a todo se ve impresionante en una demo y silenciosamente destruye la confianza en producción. Este es el mismo patrón de fallo detrás de la mayoría de los problemas de los chatbots de IA: no hay puerta de confianza, así que responde cuando no debería. También es la línea que separa a un agente real de un chatbot basado en reglas, que no puede hacer ese juicio en absoluto.

La palanca de verificación tiene un análogo exacto en el soporte. En codificación, verificas con una suite de pruebas. En soporte, verificas simulando al agente contra tus propios tickets pasados antes de que toque a un cliente, observando qué habría dicho, dónde la cobertura es débil, y qué se le escapa. Ese es el equivalente en el mundo del soporte a la disciplina de Anthropic de "200 funciones, todas con passes: false", y por eso construimos la simulación dentro del agente de helpdesk de eesel en lugar de dejar que los equipos lo descubran en producción.

Las cifras respaldan por qué importa la ingeniería. En un informe de referencia de 2026, Notch sitúa a los chatbots tradicionales entre un 10 y un 25% de resolución, y a las plataformas agénticas (las que "se conectan directamente a sistemas de CRM, facturación y reclamaciones y ejecutan acciones") entre un 70 y un 85% de resolución de extremo a extremo. La brecha no es la calidad del modelo, cada nivel puede usar los mismos modelos de vanguardia. La brecha es si alguien diseñó el bucle a su alrededor. La frase más afilada del informe es un consejo de compra: la pregunta honesta que hay que hacerle a un proveedor "no es cuál es su tasa de resolución, sino qué cuenta como resuelto."

También puedes ajustar ese bucle en lenguaje llano en lugar de código, que es la parte que hace que la ingeniería de loops sea accesible para un equipo de soporte y no solo para ingenieros.

Construir el bucle tú mismo, o usar uno que ya está construido

Una vez que ves la automatización del soporte como ingeniería de loops, la pregunta de construir versus comprar se vuelve más clara. Puedes construir el bucle tú mismo sobre la API pura de Claude u OpenAI, muchos equipos técnicos lo hacen, y los artículos de buenas prácticas de Claude Code son un lugar genuinamente bueno para aprender el oficio. Pero el harness es la parte difícil, y es la parte que hay que seguir manteniendo. El propio trabajo de Anthropic sobre agentes de larga duración implicó una lista de verificación de más de 200 funciones, orquestación de subagentes, y lógica de compactación, y eso es solo para mantener a un agente de codificación en el buen camino. Un bucle de soporte en producción añade además enrutamiento por confianza, gestión multilingüe, reglas por tipo de ticket, y una transferencia limpia a humanos.

Un responsable de ingeniería en una empresa de hardware cripto, con una base de conocimiento de más de 300 artículos, resumió el cálculo tras decidirse a comprar:

"Podríamos haber intentado escribir nuestra propia aplicación LLM, pero no queríamos invertir nuestro tiempo en eso. Queríamos algo que no tuviéramos que mantener."

Karel, responsable de ingeniería en GENERAL BYTES (cliente de eesel)

Ese es el verdadero dilema. El bucle es ahora el producto, así que la pregunta es si quieres ser quien lo diseña y mantiene, o si prefieres comprar un bucle que ya está diseñado para el caso de soporte. Si estás evaluando esto último, nuestro repaso del mejor software de helpdesk con IA, el catálogo de ejemplos de agentes de IA, y nuestra selección de los mejores agentes de IA son un buen mapa de quién ha hecho ese trabajo de ingeniería y qué tan bien.

Prueba eesel

eesel AI es, en el marco de todo este artículo, un bucle que ya está diseñado para el soporte. Lo conectas a tu helpdesk (Zendesk, Freshdesk, Gorgias, Help Scout, y más de 100 más), y aprende de tus tickets y documentos pasados desde el primer día. Las cinco palancas vienen ya construidas para el caso de soporte: la simulación contra tus tickets históricos es el paso de verificación, el enrutamiento basado en confianza es la condición de parada, y las acciones acotadas junto con las exclusiones por tipo de ticket son las barreras de seguridad, todo configurable en lenguaje llano en lugar de código.

Por eso un equipo como Gridwise vio a eesel resolver el 73% de las solicitudes de nivel 1 en el primer mes, con el bucle funcionando primero de forma supervisada y ganando autonomía a medida que la simulación demostraba que era seguro. Obtienes el bucle diseñado, y la verificación para confiar en él, sin tener que montar y mantener el tuyo propio. Puedes empezar gratis y simularlo contra tu propio historial de tickets antes de que un solo cliente lo vea.