⚖️ Agentic × Loop × Graph

La capa que todos conocen: la instrucción que escribes para el modelo. Es donde la mayoría empieza — y donde la mayoría se atasca.

Porque casi todo problema de «la IA no hizo lo que quería» se resuelve intentando mejorar el prompt, incluso cuando el defecto está en una capa superior.

El prompt es la capa más barata de cambiar y la más limitada. Por sí solo, nunca resuelve lo que exige memoria, herramientas o repetición.

Archivos, historial, documentación: todo lo que entra en la ventana de contexto antes de que el modelo decida el siguiente paso.

Un contexto incorrecto produce decisiones incorrectas incluso con un prompt perfecto. Y demasiado contexto satura la ventana y degrada la atención del modelo.

La ventana de contexto es un recurso finito. Lo que la llena —logs sin procesar, borradores antiguos, razonamiento previo— es el enemigo silencioso de esta capa.

La infraestructura que rodea al modelo: herramientas disponibles, permisos, captura de salida, reintentos, presupuesto de tokens.

El harness define el límite de capacidad del agente. Un modelo brillante sin la herramienta adecuada no ejecuta nada: solo describe lo que haría.

El harness es la frontera entre «el modelo pensó» y «el modelo actuó». Ahí entran en juego los permisos, la seguridad y los costos.

Cuántas veces lo intenta el agente y cómo sabe que terminó. Y toda la Trilha 2, resumida en una frase.

Sin loop, cada intento está aislado: no hay corrección. Con loop, el sistema puede equivocarse, medir y volver a intentarlo.

El loop necesita un verificador y una condición de parada. Sin ambos, no es un loop: es una repetición ciega.

Un conjunto de loops conectados por aristas explícitas — la capa que solo tiene sentido después de dominar las cuatro anteriores.

Subir al grafo sin un loop sólido debajo solo multiplica el problema: ahora tienes varios loops malos comunicándose entre sí.

El grafo no sustituye las capas inferiores: las organiza. Cada nodo del grafo aún necesita su propio prompt, contexto, harness y loop.

El harness del loop cabe en un script: entrada, contexto, presupuesto, retry, salida. El del grafo se parece más a un runtime distribuido: enrutamiento de mensajes entre nodos, aislamiento de fallas de un nodo, consistencia del estado, creación dinámica de nodos, observabilidad de quién se ejecutó, cuándo y con qué latencia.

Y por eso los frameworks ganan impulso cuando la conversación pasa de loop a grafo: el problema de infraestructura cambia de categoría, no solo de tamaño.

No es "más loops": es un problema de sistema distribuido. La falla parcial, el estado compartido y la observabilidad se vuelven obligatorios, no opcionales.

Describes el objetivo, proporcionas herramientas y el modelo decide qué hacer. Sin un ciclo definido ni una prueba de salida explícita.

Y el punto de partida más común y más rápido de montar, y también el más difícil de prever o depurar cuando algo sale mal.

El juicio del modelo sustituye una estructura diseñada por ti. Funciona bien en tareas cortas; se degrada en tareas largas o repetidas.

Dejas de escribir prompts y empiezas a diseñar el ciclo y la condición de parada: descubrir, planificar, actuar, verificar, parar.

Y el salto de calidad más barato que existe: el mismo modelo, con un ciclo diseñado, se equivoca menos y converge más rápido.

El verificador se convierte en el límite de calidad: es el tema completo de la Ruta 2. Aquí solo vuelve a aparecer como pieza de la comparación.

Varios nodos, cada uno con su propio ciclo, y el camino entre ellos definido antes de ejecutarlos, sin que el modelo lo infiera en tiempo real.

Y es el único de los tres formatos que permite paralelismo real y contextos separados por rol. También es el más caro de mantener.

La arista explícita es la diferencia central: el flujo de control se convierte en algo que puedes leer en un diagrama, no algo que reconstruyes a partir de una transcripción.

Como bucle único, un agente hace todo en una sola ventana, lee las fuentes una por una y revisa su propio texto en el mismo contexto (sella). Como grafo: investigador (abre N fuentes en paralelo) → escritor (solo las notas, contexto limpio) → revisor (contexto nuevo, solo ve el texto y el criterio, y tiene una arista de retorno «reprobado»).

Ver el mismo caso en los tres formatos es la única forma de comparar sin retórica: los números y los errores quedan visibles uno al lado del otro.

Fan-out (investigador en paralelo) y contexto limpio por rol (el escritor solo ve las notas, el revisor solo ve el texto y el criterio) son las dos diferencias que realmente importan.

Nodos paralelos especializados con contextos limpios y separados; fan-out y fan-in como movimientos de primera clase; flujo de control legible como diagrama, en vez de reconstruido a partir de una transcripción.

Son las tres ventajas que un bucle, por bien escrito que esté, no puede reproducir, porque un bucle es secuencial por definición.

Ninguno de estos beneficios es retórico: cada uno resuelve un fallo estructural específico del loop único que se vio en la Trilha 2.

Tres prompts que mantener en lugar de uno; un esquema de estado entre nodos (¿qué le entrega exactamente el investigador al escritor?); y nuevos modos de falla: una fusión que se traga una fuente, un enrutamiento que va y vuelve, un estado que se filtra de un nodo a otro.

Para una tarea que se ejecuta todos los días, vale la pena; para una que se ejecuta una vez, es un impuesto puro. Saber esto evita adoptar un grafo por moda.

El caso degenerado: un grafo de UN nodo con todas las herramientas y un loop reinventado; la estructura no está haciendo nada.

El bucle no murió: se convirtió en el nodo del grafo. No pasas del bucle al grafo; compones bucles en grafos cuando un bucle deja de ser suficiente.

Este mito hace que la gente descarte los loops antes de dominarlos — y dominar mal los loops abajo garantiza un grafo deficiente arriba.

Composición, no sustitución. Todo nodo del grafo, cuando se abre, es un bucle con su propio verificador y condición de parada.

Uno es un grafo de INFORMACIÓN que el agente consulta; el otro es un grafo de EJECUCIÓN: quién se ejecuta y en qué orden. El mercado los mezcla todo el tiempo.

Confundir los dos hace que compres la herramienta equivocada para el problema que tienes: GraphRAG no orquesta agentes, y viceversa.

El grafo de conocimiento responde «qué sé». El grafo de ejecución responde «quién hace qué y en qué orden». Son dos grafos diferentes con el mismo nombre de marketing.

DSPy optimiza programas de modelos de lenguaje —prompts y parámetros—, no grafos de conocimiento. Es una atribución errónea común en las conversaciones sobre ingeniería de grafos.

Repetir la atribución equivocada hace que busques DSPy para un problema que no resuelve e ignores las herramientas que sí lo resolverían.

DSPy = optimización de programas. No lo confundas con el almacenamiento o la consulta de grafos: son categorías distintas de herramientas.

Anthropic no anunció ninguna disciplina llamada graph engineering: usa orquestación escrita en código, que es distinto de lanzar una metodología con ese nombre.

Citar «Anthropic lanzó graph engineering» como fuente de autoridad es un error factual específico que circula bastante; conviene saber señalarlo.

Orquestar agentes con código (grafos, colas, enrutamiento) es una práctica de ingeniería antigua. La etiqueta "graph engineering" es reciente; la práctica no lo es.

Surgieron de un estudio específico sobre diagramas industriales, no de un benchmark general de agentes. Repetir esto como si aplicara a cualquier sistema es deshonesto.

Es el ejemplo más claro de una cifra de marketing que circula sin contexto — útil para reconocer el patrón en cualquier otra cifra suelta que aparezca.

Pregunta siempre: benchmark de qué tarea, comparado con qué baseline y medido por quién. Sin eso, el número es solo ruido con apariencia de dato.

La máquina de estados, XState y la orquestación en grafo de LangGraph, AutoGen y Google ADK son anteriores al término. Lo nuevo en 2026 es el VOCABULARIO.

Evalúa el patrón, no la etiqueta. Esa es la conclusión práctica: la mayoría de los agentes todavía no necesita un grafo — muchas tareas siguen siendo un modelo, un ciclo de herramientas y una buena condición de parada.

La máquina de estados finita es el antecesor directo. Volver a nombrarla no hace que la idea sea nueva, pero tampoco la vuelve inútil.