La estética de la ingeniería de loops (The Art of Loop Engineering)

• Para usar agentes de forma estable en tareas útiles, no basta con un buen modelo: se necesita un harness diseñado para el conjunto de tareas
• El loop de agente más básico consiste en darle contexto al LLM y llamar herramientas de forma repetida hasta que la tarea termine
• A partir de ahí, se construyen agentes más eficaces apilando (stacking) loops de validación, loops basados en eventos y loops de hill climbing
• Cada capa de loop puede instrumentarse con primitivas de LangChain, y se explica con el ejemplo de un agente interno de redacción de documentación
• El verdadero potencial no está en el modelo en sí, sino en los loops que se construyen alrededor del agente

---

Loop 1: loop de agente

• Un agente es, en esencia, un modelo que llama herramientas de forma repetida hasta completar una tarea
• create_agent de LangChain proporciona este loop: al elegir un modelo y conectar herramientas (tools), queda listo un loop de agente funcional
  • Las herramientas son los elementos que permiten al agente actuar en el mundo real
• En el ejemplo del agente interno de documentación, el primer paso del loop recibe una solicitud de mejora de documentación; el modelo planifica y redacta los cambios, y usa herramientas para clonar el repo, leer archivos, escribir documentación y abrir un pull request, entre otras acciones

Nivel 2: loop de validación

• El loop de agente procesa tareas, pero no siempre produce resultados correctos o consistentes en el primer intento; cuando la consistencia importa, se lo envuelve en un loop de validación que revisa la salida y, si es insuficiente, devuelve feedback al modelo
• El loop de validación agrega un grader que compara la salida del agente con una rúbrica (rubric) y, si falla, devuelve el resultado junto con feedback
  • El grader puede ser determinista o de tipo agente; LLM as a judge es el ejemplo típico
  • RubricMiddleware maneja este patrón, o también puede conectarse mediante el hook after_agent de create_agent
• En el ejemplo de redacción de documentación, el grader ejecuta pruebas después de cada intento para verificar que todos los enlaces funcionen correctamente, que pasen todos los checks de CI y que el diff se limite al alcance solicitado, detectando tipos de errores sin revisión manual
• Agregar validación incrementa la latencia y el costo por ejecución, pero vale la pena en la mayoría de los usos de producción donde la calidad es más importante que la velocidad

Nivel 3: loop basado en eventos

• Una de las partes más importantes del desarrollo de agentes es la capa de integraciones (integrations layer), que conecta al agente con el ecosistema para que se ejecute en segundo plano
• Un loop basado en eventos ejecuta el agente cuando ocurre un evento, como la llegada de un documento nuevo, la activación de un schedule o la llegada de un webhook
  • El agente no es algo que se llama manualmente, sino un componente que funciona de forma continua dentro de un sistema más grande
• LangSmith Deployment ofrece infraestructura de triggers y soporta schedules cron y webhooks
  • Un ejemplo popular de uso de cron son los heartbeats de openclaw, que convierten al agente en un asistente activo siempre encendido
• El agente de documentación se ejecuta con Fleet, un builder de agentes no-code; los channels y schedules de Fleet manejan triggers basados en eventos y cron
  • Cuando llega un mensaje al canal de Slack #docs-plz, el canal ejecuta el agente de documentación

Nivel 4: loop de hill climbing

• Si los tres loops anteriores automatizan el trabajo, el cuarto loop automatiza la mejora (improvement) en sí misma
• Cada ejecución del agente genera un trace que registra el comportamiento del modelo, las herramientas llamadas, el feedback del grader y otros datos; ese trace contiene señales de alto valor sobre qué funciona y qué no
• El loop de hill climbing ejecuta un agente de análisis sobre los traces y, como resultado, reescribe la configuración del harness con ajustes mejorados
  • Esto incluye ajustes de prompts/herramientas o ajustes del grader
  • En LangSmith, este cuarto loop se instrumenta con Engine, el agente de análisis de traces
• En el ejemplo del agente de documentación, se ejecuta engine sobre los traces para detectar problemas; cuando varios traces señalan un problema potencial, se registra un issue que solicita cambiar el prompt o la herramienta problemática
• La clave es que la flecha de retorno no vuelve simplemente al inicio, sino que entra hacia adentro y actualiza directamente el loop de agente; cada ciclo del loop externo hace que el loop interno sea más eficaz

• Perspectivas a futuro

  • La configuración de prompts y herramientas es lo más fácil de mejorar, pero no es la única opción; los equipos que operan modelos open-weight pueden conectar el loop de hill climbing con fine-tuning con RL para mejorar el modelo en sí usando traces o resultados de evaluación como señales de entrenamiento
  • El contexto auxiliar, como memoria o skills recuperadas, también puede mejorarse de la misma forma; el loop es un patrón, y qué optimizar depende del usuario

Supervisión humana y expertise

• La automatización no significa quitar a las personas del loop; en todas las capas existen puntos donde la supervisión humana aporta valor
  • Un grader automático puede verificar que los enlaces funcionen correctamente, pero detectar que el framing es incorrecto para la audiencia objetivo es tarea de una persona; el juicio que surge del contexto, la experiencia y el criterio es donde se necesita revisión humana
• Parte de la expertise debe codificarse en los prompts/herramientas, pero para acciones sensibles como transacciones financieras o tareas sobre bases de datos, la revisión humana en tiempo real es indispensable
• LangChain facilita instrumentar estos puntos de contacto en todos los loops
  • Loop de agente: exigir input humano antes de acciones sensibles o llamadas a herramientas
  • Loop de validación: que una persona actúe como grader en workflows sensibles
  • Loop de aplicación: que una persona apruebe la salida antes de devolverla al usuario final
  • Loop de hill climbing: que las mejoras del harness pasen por revisión humana antes del despliegue
• Todos los frameworks open source de LangChain ofrecen human in the loop como primitiva de primera clase

Resumen general

• Resumen de cómo se apilan los cuatro loops
  • Loop de agente: el modelo llama herramientas repetidamente hasta completar la tarea → automatización de tareas; las primitivas son create_agent y los modelos compatibles con LangChain
  • Loop de validación: califica la salida con una rúbrica y, si falla, reintenta con feedback → garantiza calidad y precisión de la tarea; la primitiva es RubricMiddleware
  • Loop basado en eventos: los eventos disparan ejecuciones del agente que actualizan sistemas reales → automatización de tareas a gran escala; las primitivas son LangSmith Deployment basado en triggers cron/webhooks o Fleet channels
  • Loop de hill climbing: los traces de ejecuciones en producción mejoran la configuración del harness mediante un agente de análisis → mejora del harness; la primitiva es LangSmith Engine
• Esto es lo que swyx llama loopcraft, es decir, la ingeniería de loops real; líderes como Steipete, Boris y Andrej también llegaron a la misma conclusión: el potencial de los agentes está en los loops que se construyen alrededor de ellos
• Los loops 1 y 2 se han tratado durante mucho tiempo, pero ahora el foco debe pasar a los loops 3 y 4, donde los agentes se integran en el ecosistema, mejoran continuamente según criterios definidos y acumulan valor de forma compuesta
• Satya señala el interés a nivel organizacional y menciona que las empresas que construyen temprano loops de aprendizaje, donde el juicio humano y el capital en tokens se acumulan juntos de forma compuesta, obtienen una ventaja difícil de replicar