De agente a bucle y a grafo: una arquitectura de producción para sistemas agentes

Una publicación muy compartida en X, con fecha del 18 de agosto de 2026, atribuye un tutorial de dos horas a Andrew Ng y presenta una útil progresión del alcance de ingeniería: el primer agente funcional en el minuto 9:14, bucles en el 33:11, la transición de bucles a grafos en el 1:02:46, agentes que modifican su propio código en el 1:30:15 y una capa de orquestación que unifica el sistema en el 1:49:05. Este artículo utiliza ese esquema con marcas de tiempo como punto de partida para la arquitectura de producción; no depende de que la atribución sea correcta.

Independientemente de si esas etiquetas se convierten en vocabulario canónico, la progresión es útil porque cada paso plantea una cuestión de sistemas diferente. Un solo agente introduce preguntas sobre capacidades y uso de herramientas. Un bucle duradero añade preocupaciones sobre el estado, la recuperación, el contexto y la aprobación. Un grafo añade topología, coordinación y delegación. La automodificación plantea cuestiones de verificación, contención y promoción. La orquestación convierte el sistema combinado en un problema operativo.

1. El primer agente es una capacidad; el bucle lo convierte en un sistema

El primer hito en el post mencionado es el más fácil de reconocer: lograr que un agente funcione. Se le da a un modelo un objetivo, una interfaz de herramientas y suficiente estado para elegir una acción. Ese es el momento en que un modelo de lenguaje deja de ser solo un generador de texto y comienza a participar en un sistema.

Pero la acción única no es donde se acumula la complejidad operativa. La complejidad aparece cuando el agente debe continuar: observar el resultado, decidir si la tarea ha terminado, llamar a otra herramienta, sobrevivir a una llamada fallida, compactar el contexto, solicitar aprobación o reanudar el trabajo al día siguiente.

Es por eso que el artículo de TrueFoundry de junio sobre ingeniería de bucles definió la disciplina de esta manera:

La frase es importante porque desplaza la atención de un único prompt heroico. Una vez que el bucle realiza un trabajo útil sin supervisión, las cuestiones de diseño se convierten en problemas de sistemas habituales: dónde reside el estado, qué acciones se pueden reintentar, cuántas veces puede repetirse un fallo, cuándo debe intervenir un humano, qué código se puede ejecutar, a qué credenciales se tiene acceso y cómo se reconstruye una ejecución posteriormente.

2. Un grafo no reemplaza al bucle; organiza bucles y otros nodos

El siguiente salto conceptual del post de X —la conversión de bucles en grafos— es donde el entusiasmo puede ocultar la ingeniería útil. Un grafo no significa "más agentes" por definición. Un grafo de producción puede contener agentes, funciones deterministas, enrutadores, uniones, colas, puntos de control humanos, evaluadores, escrituras en bases de datos y servicios comunes.

La guía de ingeniería de grafos de TrueFoundry de julio resumió la relación en siete palabras:

El grafo o el orquestador se encarga de cuestiones como: ¿Qué nodo se ejecuta a continuación? ¿Pueden ejecutarse dos ramas en paralelo? ¿Qué resultado desbloquea una unión? ¿Qué sucede cuando una rama falla? ¿Qué agente puede delegar en otro? ¿Qué ruta requiere un punto de control humano? Un bucle de varios pasos dentro de un nodo agente gestiona un conjunto diferente de preguntas: qué contexto ve el agente, qué herramienta selecciona, cómo maneja las observaciones, cuándo reintenta y cuándo su trabajo local está completo.

Primero, separemos dos significados de "grafo"

El enfoque en redes sociales utiliza la expresión "grafos de conocimiento agentes". Esa terminología puede fusionar dos arquitecturas distintas. Un grafo de conocimiento representa entidades y relaciones en la información. Un grafo de ejecución de agentes representa actores, nodos computacionales, transiciones, dependencias y el estado del trabajo. Uno puede alimentar al otro, pero responden a preguntas diferentes.

Si un agente de investigación consulta un grafo de conocimiento y luego delega la validación a un segundo agente, el grafo de conocimiento es parte de lo que el sistema sabe; el grafo de ejecución describe lo que el sistema hace.

3. Los bordes son el punto donde muchos controles empresariales se vuelven ejecutables

Un diagrama de grafos se vuelve operativo cuando los nodos y los bordes tienen autoridad. Un borde puede significar «llamar a este modelo», «invocar esta herramienta MCP», «transferir este registro de cliente a otro agente», «escribir este parche» o «desplegar este artefacto». Una vez que esas transiciones tienen consecuencias, la topología y la gobernanza se vuelven inseparables, aunque la evaluación de nodos, el estado del grafo y la autorización posterior sigan siendo partes igualmente importantes de la estrategia de control.

La reciente publicación de TrueFoundry sobre ingeniería de grafos resume la postura empresarial en una frase breve:

‍