Un bucle oculta una decisión dentro de una caja negra: qué se ejecuta a continuación.
Cada vez que un bucle de agente decide si reintentar, escalar o continuar, esa decisión ocurre dentro del razonamiento interno del modelo, invisible para ti, no auditada después del hecho e imposible de inspeccionar sin releer la salida sin procesar del modelo y esperar que se haya explicado honestamente. Un grafo hace explícita esa misma decisión. Por escrito. Inspeccionable incluso antes de que comience la ejecución.
No es una distinción menor. Es el argumento real detrás de un artículo real de arXiv publicado en abril de 2026 que reformuló cómo deberían construirse los sistemas de agentes, y vale la pena ser directo sobre algo antes de que este curso avance más. El propio autor del artículo incluye un descargo de responsabilidad de equidad que establece claramente que se trata de un diseño no implementado, y si ofrece sus beneficios prometidos en la práctica sigue siendo una pregunta empírica abierta. Este curso enseña el marco de trabajo honestamente, incluyendo esa advertencia, porque comprender una propuesta real y rigurosamente argumentada que aún no se ha probado a escala es más útil que pretender que es un hecho establecido.
Al final de este curso, comprenderás qué es realmente la ingeniería de grafos, por qué existe como la capa superior a los bucles, los tres compromisos en los que se basa cada grafo en este marco, y cómo construir el primero, junto con un relato honesto de dónde está y no está la evidencia actualmente.
Por qué los bucles tienen un límite
Para entender por qué existen los grafos, necesitas entender precisamente dónde los bucles dejan de ser suficientes.
Un bucle, en el sentido agéntico que importa aquí, es un ciclo donde un agente intenta una tarea, observa el resultado y decide qué hacer a continuación, repetido hasta que se cumple alguna condición. Esto funciona notablemente bien para una amplia gama de tareas. También es, estructuralmente, una caja negra en el momento exacto que más importa: la decisión de qué sucede después.
Cuando el agente de un bucle decide reintentar un paso fallido, esa decisión provino del modelo razonando sobre su propio contexto y produciendo una elección. No puedes inspeccionar la decisión antes de que ocurra. Solo puedes observar el resultado después. Si el agente reintenta el mismo enfoque fallido cinco veces seguidas, quemando costo cada vez, nada en la estructura del bucle lo impidió, porque la decisión de reintentar residía enteramente dentro del juicio del propio modelo, no en ninguna regla externa y verificable.
Esto está bien para tareas de bajo riesgo y bajo costo donde un reintento ocasional desperdiciado no cuesta nada significativo. Se convierte en una responsabilidad real para trabajos de horizonte largo, costosos o de alto riesgo, exactamente la categoría de tareas a las que cada vez más se les confían los sistemas de agentes. El argumento central del artículo es que, a medida que los sistemas de agentes asumen trabajos más consecuentes, la opacidad de "qué se ejecuta a continuación" deja de ser una caja negra aceptable y comienza a ser el punto de fallo real que vale la pena abordar directamente con ingeniería.
Qué es realmente un grafo
Un grafo, en este marco, reemplaza la decisión implícita del modelo sobre el siguiente paso con una estructura explícita definida antes de que comience la ejecución.
En lugar de que un agente razone su camino hacia "debería reintentar" o "debería escalar" dentro de una ventana de contexto opaca, el grafo define, de antemano, exactamente qué estados existen, qué transiciones entre estados son válidas y qué condiciones específicas desencadenan cada transición. El agente todavía hace trabajo real dentro de cada estado. Lo que ya no hace es decidir invisiblemente la forma del proceso general sobre la marcha.
La estructura de cinco movimientos que describe cualquier turno único a través de un grafo como este: Planificar, Ejecutar, Recuperar, Escalar, Repetir. Planificar es donde la tarea se descompone en una secuencia definida. Ejecutar es donde el agente realmente hace el trabajo para el paso actual. Recuperar es lo que sucede cuando la ejecución falla, siguiendo un protocolo definido en lugar de un reintento improvisado. Escalar es el punto explícito y definido donde el grafo entrega el control a un humano en lugar de continuar intentando la recuperación automatizada. Repetir cierra el ciclo, moviéndose al siguiente paso en el plan.
Observa lo que cambió en comparación con un bucle. Cada uno de estos cinco movimientos es ahora un estado nombrado e inspeccionable en un grafo, con transiciones definidas entre ellos, en lugar de una decisión que ocurre silenciosamente dentro de una sola llamada al modelo.
Los tres compromisos
Cada grafo en este marco se basa en tres compromisos específicos. Comprender estos tres profundamente es el núcleo real de la ingeniería de grafos como disciplina, más que cualquier detalle de implementación específico.
Compromiso Uno: Plan Inmutable
El plan de ejecución no puede cambiar a mitad de la ejecución. Una vez que un plan se genera y se bloquea, existe como una versión fija durante la duración de esa ejecución. El agente no puede revisar silenciosamente su propio plan a mitad de la ejecución basándose en algo que notó, como a menudo hace un agente dentro de un bucle sin ningún registro externo de que la revisión ocurrió.
Esto suena restrictivo, y se pretende que lo sea. La restricción es todo el punto. Un agente que puede revisar libremente su propio plan a mitad de la ejecución es exactamente el agente cuyo comportamiento se vuelve imposible de auditar después del hecho, porque el plan que revisarías después no es el plan que realmente se siguió, es lo que sea en lo que se haya convertido el plan al final. Bloquear el plan intercambia flexibilidad real por inspeccionabilidad real. Ese intercambio no es gratuito, y vale la pena considerarlo honestamente en lugar de tratarlo como una mejora estricta en todos los casos. Una situación genuinamente novedosa que el plan original no anticipó se maneja peor con un plan inmutable que con un bucle que puede adaptarse libremente. El compromiso es una apuesta deliberada de que, para la categoría de tarea a la que se dirige este marco, predecible y auditable supera a máximamente adaptable.
Compromiso Dos: Capas Separadas
La planificación, la ejecución y la recuperación viven en tres capas independientes en lugar de un bucle enredado donde las tres ocurren dentro del mismo proceso de razonamiento continuo.
La capa de planificación produce el plan inmutable del compromiso uno y no hace nada más, no ejecuta pasos ni maneja fallos. La capa de ejecución ejecuta los pasos definidos e informa los resultados, no decide qué sucede en caso de fallo, solo qué sucedió. La capa de recuperación recibe informes de fallo y aplica un protocolo definido, no ejecuta nuevo trabajo directamente, solo decide cómo responder a lo que ya sucedió.
Esta separación refleja, deliberadamente, el mismo principio detrás de separar un Constructor de un Juez en un bucle de verificación, un rol que produce trabajo no debería ser el mismo rol que evalúa o decide sobre ese trabajo, porque colapsar los dos erosiona la independencia que hace que la verificación sea significativa en primer lugar. Aquí la separación es triple en lugar de doble, pero el razonamiento subyacente es idéntico: un sistema que planifica, ejecuta y se recupera todo dentro de un proceso indiferenciado no puede auditar significativamente ninguna de esas funciones de forma independiente, porque nunca son realmente distintas en el rastro que revisarías después.
Compromiso Tres: Escalación Estricta
La recuperación sigue un protocolo fijo en lugar de reintentar indefinidamente y esperar que algo funcione eventualmente.
Este es el compromiso que aborda más directamente el modo de fallo de explosión de tokens que plaga a los bucles sin condiciones de parada reales. Un protocolo de escalación estricta define, de antemano, exactamente cuántos intentos de recuperación están permitidos, exactamente qué cuenta como un intento de recuperación exitoso o fallido, y exactamente qué sucede en el momento en que se alcanza el límite definido, entregando el control a un humano, no intentando una variación más creativa del mismo enfoque fallido.
El análisis del artículo en 70 sistemas del mundo real encontró que una gran parte de las implementaciones de Bucles de Agente no tenían límites formales en los intentos de recuperación en absoluto, lo que significa que el comportamiento real cuando algo salía mal estaba determinado por lo que el modelo decidía en el momento, no por ninguna regla que un humano hubiera revisado y aprobado de antemano. La escalación estricta cierra esa brecha específica directamente.
Construyendo tu primer grafo
Aquí está el camino práctico para construir realmente uno de estos, traduciendo los tres compromisos en algo que puedas implementar en lugar de solo entender conceptualmente.
Comienza definiendo tus estados explícitamente, en papel, antes de escribir cualquier código o instrucción. Para una tarea típica, esto generalmente se ve como mínimo: Planificando, Ejecutando Paso N, Recuperándose de Fallo, Escalado, Completado. Escribe, para cada estado, exactamente qué sucede mientras el sistema está en ese estado y exactamente qué condiciones causan una transición fuera de él.
Escribe el paso de generación del plan para que su salida sea un artefacto fijo y versionado, no un documento vivo que el resto del sistema pueda editar silenciosamente. Una versión simple y práctica de esto es generar el plan como una lista numerada de pasos discretos, cada uno con un criterio de éxito explícito, y tratar esa lista como de solo lectura durante el resto de la ejecución. Cualquier necesidad genuina de desviarse de él debería desencadenar una escalación explícita a un humano, no una revisión interna silenciosa.
Construye la capa de ejecución para que solo informe resultados, pasar, fallar, con detalles específicos, nunca tome una decisión sobre qué sucede a continuación por sí misma. Esto refleja exactamente el rol de Constructor de un bucle de verificación, produciendo trabajo e informando sobre él honestamente, sin ser también el rol que decide si reintentar.
Construye la capa de recuperación con un protocolo explícito y numerado. Intenta un enfoque alternativo específico. Si eso falla, intenta un segundo enfoque específico diferente. Si eso falla, escala. El protocolo debe ser lo suficientemente concreto para que un humano que lo lea de antemano pueda predecir exactamente qué hará el sistema en cada etapa, en lugar de una instrucción vaga como "intenta arreglarlo un número razonable de veces".
Conecta el estado de escalación para que alcanzarlo sea un evento real y visible, no algo registrado silenciosamente y olvidado. Se debe notificar a un humano, con el historial completo de lo que se intentó y por qué falló cada intento, la misma disciplina recomendada para las condiciones de parada en los bucles de verificación en general.
Dónde ayuda realmente este marco, y dónde no
Ser honesto sobre los límites de la ingeniería de grafos es más útil que tratarlo como una mejora universal sobre los bucles en todas las situaciones, y el propio artículo respalda este marco más mesurado.
Los grafos realmente ayudan en tareas donde el espacio de lo que puede salir mal se comprende razonablemente bien de antemano, donde la auditabilidad importa más que la adaptabilidad máxima, y donde el costo de un ciclo de reintento ilimitado y sin control sería genuinamente costoso, ya sea en costo computacional o en la consecuencia de un mal resultado que llegue a un usuario real o un sistema real.
Los grafos son una peor opción para tareas genuinamente abiertas y exploratorias donde no puedes predecir significativamente la forma del fallo de antemano, y donde el valor del sistema proviene precisamente de su capacidad para improvisar una respuesta a algo que nadie anticipó. Bloquear un plan como inmutable, para una tarea que fundamentalmente requiere replanificación adaptativa a medida que surge nueva información, intercambia la capacidad exacta que hizo que valiera la pena automatizar la tarea con un agente en primer lugar.
La posición honesta y defendible, y la que toma el propio autor del artículo, es que este es un intercambio real que vale la pena comprender profundamente, no un reemplazo estrictamente superior para los bucles en todos los casos. Usa un bucle donde la adaptabilidad importa más que la auditabilidad. Usa un grafo donde ocurre lo contrario. La mayoría de los sistemas reales se benefician de tener ambos patrones disponibles y elegir deliberadamente entre ellos por tarea, en lugar de adoptar uno u otro como predeterminado permanente.
Un ejemplo práctico: Migración de código estructurada con grafos
Para hacer concretos la estructura de cinco movimientos y los tres compromisos, aquí se explica cómo se aplican a una tarea real y común: migrar un módulo heredado a una nueva versión de framework en una base de código.
El estado de Planificación se ejecuta una vez, al principio. Analiza el módulo, identifica todos los archivos que necesitan cambiar y produce una lista fija y numerada de pasos de migración, cada uno con un criterio de éxito explícito; por ejemplo, el paso 4 tiene éxito cuando el archivo actualizado se compila y el conjunto de pruebas existente para ese archivo se pasa sin modificación. Este plan se bloquea. Es el compromiso uno, inmutable, en la práctica.
El estado de Ejecución trabaja a través de los pasos del plan en orden. Para cada paso, aplica el cambio específico definido en el plan e informa el resultado, pasar o fallar, con la salida real del compilador o el resultado de la prueba adjunta como evidencia, nunca una autoevaluación de "parece correcto". Esta es la capa de ejecución del compromiso dos, estrictamente separada de la decisión sobre qué sucede si falla.
Cuando un paso falla, el grafo transita a Recuperándose, que sigue un protocolo definido en lugar de un reintento improvisado. Intento uno: reaplicar el mismo cambio con un alcance más limitado, aislando exactamente qué parte del archivo causó el fallo de compilación. Intento dos, si el primero falla: recurrir a un patrón de migración alternativo documentado para este tipo específico de fallo, extraído de una pequeña biblioteca de correcciones conocidas en lugar de inventado nuevo cada vez. Si ambos intentos definidos fallan, el grafo transita a Escalado, esto es el compromiso tres, escalación estricta, no un tercer intento improvisado.
El estado Escalado notifica a un humano directamente, con el historial completo adjunto: qué paso falló, qué intentaron ambos intentos de recuperación y la salida de error específica de cada uno. Un humano revisa este fallo específico con contexto completo, en lugar de descubrir días después que un agente había estado reintentando silenciosamente el mismo enfoque roto en un bucle todo el tiempo, quemando costo sin ningún registro de por qué.
Repetir cierra el ciclo para los pasos exitosos, moviendo el grafo al siguiente elemento en el plan bloqueado hasta que la lista se agota, momento en el cual la ejecución alcanza Completado.
Observa lo que esto te compra sobre la tarea equivalente ejecutada como un bucle no estructurado. Cada decisión, si reintentar, cómo y cuándo rendirse, es visible en la estructura definida del grafo incluso antes de que comience la ejecución, no se puede descubrir solo leyendo una transcripción después e infiriendo lo que el modelo debía estar pensando. Un revisor de código, o un auditor de cumplimiento, puede mirar solo la definición del grafo y saber exactamente de qué es capaz el sistema en cada escenario de fallo, sin haberlo visto nunca ejecutarse.
Ingeniería de grafos frente a ingeniería de bucles: cuándo usar cada uno
Dado que ambos patrones son reales, documentados y cada uno tiene fortalezas genuinas, aquí hay un marco de decisión práctico para elegir entre ellos para una tarea específica, en lugar de tratar cualquiera de ellos como un valor predeterminado permanente.
Recurre a un bucle cuando la tarea es genuinamente exploratoria, cuando no puedes predecir de antemano la forma de lo que podría salir mal, y cuando la capacidad del modelo para improvisar una respuesta a algo no anticipado es exactamente la capacidad en la que confías. Las tareas de investigación, la depuración abierta donde la causa raíz es genuinamente desconocida al principio, y el trabajo creativo donde una estructura rígida dañaría activamente la salida, todos favorecen la adaptabilidad de un bucle sobre la auditabilidad de un grafo.
Recurre a un grafo cuando la tarea se comprende lo suficientemente bien de antemano como para que puedas enumerar realmente los modos de fallo probables, cuando el costo de un ciclo de reintento ilimitado y no auditado sería genuinamente costoso, y cuando un revisor humano, ya sea un equipo de cumplimiento, un auditor de seguridad o simplemente tu yo futuro depurando un incidente de producción, necesitará inspeccionar exactamente de qué era capaz el sistema sin releer una transcripción de ejecución completa. Las migraciones, las transacciones financieras, cualquier cosa que toque datos regulados y el trabajo de agente desatendido de larga duración donde un fallo silencioso podría acumularse durante horas antes de que alguien lo note, todos favorecen la estructura de un grafo sobre la flexibilidad de un bucle.
Los dos patrones tampoco son mutuamente excluyentes dentro de un solo sistema más grande. Un diseño común y pragmático utiliza un grafo en el nivel externo, para la estructura general de la tarea y sus condiciones de parada, mientras permite que un bucle se ejecute dentro de un solo estado de Ejecutar para la subtarea genuinamente exploratoria de descubrir cómo implementar un paso específico. Esto te da la auditabilidad de un grafo en el nivel donde más importa, la forma general de lo que el sistema puede hacer, mientras preserva la adaptabilidad de un bucle en el nivel donde la improvisación genuina es realmente valiosa, los detalles de un trabajo acotado.
Probando un grafo antes de confiar en él
Antes de confiar en un sistema estructurado con grafos para cualquier cosa real, ejecútalo a través de pruebas de estrés diseñadas específicamente en torno a los tres compromisos, ya que cada compromiso tiene su propia forma de fallar silenciosamente si se implementa descuidadamente.
Para probar el compromiso del plan inmutable, construye deliberadamente un escenario a mitad de una ejecución donde el siguiente paso "obviamente correcto", si el sistema estuviera razonando libremente, se desviaría del plan bloqueado. Confirma que el sistema realmente escala a un humano en lugar de adaptar silenciosamente el plan por sí mismo. Si se adapta silenciosamente, el plan nunca fue realmente inmutable en la práctica, independientemente de cómo esté estructurado el código.
Para probar el compromiso de las capas separadas, verifica si los informes de fallo de la capa de ejecución contienen algún rastro de una decisión sobre qué debería suceder después, frases como "esto probablemente necesita un enfoque diferente" incrustadas en lo que debería ser un informe neutral de pasar o fallar. Si la capa de ejecución ya está formando opiniones sobre la recuperación, la separación de la capa de recuperación no es real, solo se ha renombrado.
Para probar la escalación estricta, alimenta deliberadamente al sistema con un fallo que ninguno de los intentos de recuperación definidos pueda arreglar, y confirma que escala limpiamente en el límite definido en lugar de intentar un tercer enfoque indefinido. Este es el equivalente en ingeniería de grafos de probar la condición de parada de un bucle contra una tarea genuinamente irresoluble, y detecta la misma clase de fallo silenciosamente costoso.
Más allá de estas tres pruebas específicas, rastrea una métrica específica a lo largo del uso real que la alternativa basada en bucles típicamente no puede darte limpiamente: la tasa a la que las ejecuciones alcanzan el estado Escalado, desglosada por qué intento de recuperación específico falló cada vez. Un grafo que escala constantemente en el mismo paso de recuperación específico te está diciendo que el protocolo definido de ese paso está mal calibrado, no que la tarea subyacente sea uniformemente difícil, el mismo valor de diagnóstico que rastrear los desencadenantes de la condición de parada proporciona para los bucles, solo que disponible aquí con más granularidad porque el punto de fallo es un estado nombrado e inspeccionable en lugar de un momento inferido dentro de una transcripción opaca.
Errores comunes al construir un grafo por primera vez
Un puñado de errores específicos aparecen repetidamente para las personas que construyen su primer sistema estructurado con grafos, y conocerlos de antemano ahorra tiempo real de depuración más adelante.
Tratar el plan como inmutable solo de nombre. Bloquear el plan en papel mientras aún se permite que la capa de ejecución se desvíe silenciosamente de él en la práctica produce lo peor de ambos mundos, sin adaptabilidad real y sin auditabilidad real tampoco, ya que el rastro ya no coincide con el plan bloqueado que revisarías.
Colapsar las tres capas de nuevo en una porque se siente más rápido de construir. La tentación de permitir que la capa de ejecución también decida sobre la recuperación, saltándose la separación del compromiso dos, anula el propósito real del marco. Si la planificación, la ejecución y la recuperación no son genuinamente independientes, has construido un bucle usando el vocabulario de un grafo, no un grafo real.
Escribir un protocolo de recuperación lo suficientemente vago como para que no sea realmente un protocolo. "Intenta un número razonable de enfoques alternativos" no es un protocolo de escalación estricta, es una instrucción suave con el mismo modo de fallo que un bucle ilimitado, solo que descrito usando el lenguaje de la ingeniería de grafos. Un protocolo real nombra el número específico de intentos y las condiciones específicas para cada uno.
Saltarse la evaluación honesta de la idoneidad. Construir un grafo para una tarea genuinamente abierta y exploratoria porque la ingeniería de grafos es el marco más nuevo y de sonido más riguroso, en lugar de porque la tarea realmente se beneficia del intercambio, produce un sistema que es más difícil de construir que un bucle y peor en el trabajo real de lo que habría sido un bucle.
El estado honesto de la evidencia
Cerrando con la advertencia con la que comenzó este curso, porque importa más aquí que en la mayoría de los escritos técnicos. Los tres compromisos descritos anteriormente son una propuesta real y cuidadosamente razonada, analizada contra 70 sistemas reales para identificar exactamente dónde fallan silenciosamente los bucles. Aún no están validados como proveedores de sus beneficios prometidos a escala en producción, por la declaración explícita del propio autor.
Esto no hace que el marco sea inútil. Lo convierte en un diseño genuinamente prometedor que vale la pena entender y experimentar deliberadamente, rastreando tus propios resultados honestamente en lugar de asumir que el argumento teórico se traduce automáticamente en la práctica. Si construyes un sistema estructurado con grafos usando este curso, lo más valioso que puedes hacer es medir si realmente reduce los modos de fallo específicos a los que se dirige, reintentos ilimitados, desviación del plan no detectada a mitad de la ejecución, decisiones de recuperación no auditadas, contra tu propio uso real, en lugar de asumir la mejora porque el argumento para ello es convincente en papel.
Esa disciplina, tratar un marco bien razonado como una hipótesis para probar en lugar de un hecho establecido para adoptar acríticamente, es en sí misma la meta-habilidad real debajo de todo en este curso. La ingeniería de grafos, la ingeniería de bucles, cualquier práctica nombrada en este campo de rápido movimiento, vale la pena aprenderla adecuadamente y vale la pena probarla honestamente contra tus propios resultados, en lugar de adoptarla puramente porque tiene un nombre y un artículo detrás.
Sigue a @cyrilXBT para obtener actualizaciones sobre este marco a medida que las implementaciones y los resultados del mundo real realmente comiencen a aparecer.
