Grafos de agentes: por qué la orquestación seria es un problema de grafo

Cada vez que sale un modelo con más ventana de contexto, alguien me escribe para decirme que la orquestación de agentes acaba de quedar resuelta. Metes el repositorio entero, pides el resultado, listo. Vi esa película en tres generaciones de tecnología, y siempre termina igual.

Pasé dos décadas construyendo búsqueda enterprise antes de Arvor — Solr, Lucene, índices de miles de millones de documentos. La lección es aburrida y universal: la capacidad bruta nunca arregló un modelado malo. Un índice más grande no arregla un esquema malo. Un contexto más grande no arregla un trabajo mal descompuesto.

En 2026, la orquestación seria de agentes es un problema de grafo. El equipo que lo entiende deja de pelear con el modelo y empieza a pelear con el problema correcto.

Un solo agente es un grafo de un solo nodo

Cuando le entregas todo a un agente con contexto gigante, no eliminaste el grafo: lo colapsaste en un único nodo y perdiste todo lo que la estructura te daba.

Un solo agente no elimina el grafo: lo colapsa en un único nodo. El grafo devuelve aislamiento, paralelismo y un punto de verificación explícito.

Perdiste aislamiento: un paso que sale mal contamina todos los siguientes, porque el razonamiento defectuoso sigue en la ventana. Perdiste paralelismo: diez verificaciones independientes se vuelven diez pasos en serie. Perdiste reintento granular: cuando falla, rehaces todo en lugar del pedazo que se rompió. Y perdiste observabilidad — “el agente se equivocó en algún lugar de estos 400 mil tokens” no es un diagnóstico, es una queja.

Hay un costo más sutil: dentro de una ventana enorme todo compite por atención, y esa pelea no se gana redactando mejor el prompt — se gana decidiendo qué entra en cada nodo.

Nodos, aristas y la parte aburrida que nadie quiere hacer

Un nodo es una unidad de trabajo con entrada declarada y salida verificable. Si no puedes escribir su criterio de aceptación en una frase, no es un nodo: es un deseo.

Una arista es una dependencia real: B corre después de A porque B consume la salida de A. Y acá está la parte aburrida que casi nadie hace: la mayoría de las aristas que dibujan los equipos no son dependencias, son el orden en que a alguien se le ocurrieron las tareas. Secuencia accidental ascendida a arquitectura.

Distinguir dependencia real de hábito de escritura es lo que convierte una lista de tareas en un grafo. Ahí está la ganancia: todo lo que no depende de nada puede correr al mismo tiempo.

Fan-out, fan-in, pipeline y barrera

Cuatro patrones cubren casi todo:

Fan-out manda el mismo insumo a varios nodos con objetivos distintos, en paralelo. Cada uno con contexto pequeño y misión estrecha.

Fan-in agrega. Es el patrón que más se hace mal, porque los equipos tratan la agregación como resumen. Un nodo de fan-in necesita regla de conflicto: ¿qué pasa cuando dos verificadores no coinciden? Sin esa regla, el agregador elige la respuesta mejor escrita, no la correcta.

Pipeline encadena pasos en serie. La latencia se suma y, peor, el error se propaga. Haz la cuenta honesta: doce pasos con 95% de acierto cada uno dan poco más de 54% de probabilidad de salir entero. Los equipos los construyen porque son más fáciles de escribir, y después le echan la culpa al modelo por el cara o cruz.

Barrera es lo opuesto: nada avanza hasta que todo llegue. Cuesta latencia y compra consistencia — es lo que impide un merge antes de que build, tests, type check y lint vuelvan todos en verde.

En el pipeline cada verificación sigue apenas termina; en la barrera, nada avanza hasta que llegan todas.

La verificación adversarial es un nodo, no un adjetivo

“Revisa tu trabajo” al final del prompt no es verificación. Es el mismo modelo, con el mismo contexto y el mismo sesgo, preguntándose si le gustó lo que hizo. La respuesta siempre es sí.

La verificación de verdad es un nodo aparte en el grafo: contexto propio, objetivo invertido (encontrar el defecto, no confirmar el acierto) y acceso únicamente al artefacto, nunca al razonamiento de quien lo generó — un verificador que lee ese razonamiento queda capturado por él. Solo avanza lo que sobrevive al intento de tumbarlo.

Y tu mejor verificador casi nunca es un LLM: compilador, tests, type checker, linter y validación de esquema son baratos, deterministas y sin opiniones. Gasta el modelo en lo que la máquina no revisa — intención, reglas de negocio, contratos implícitos — y deja el resto a herramientas que no alucinan.

Tres grafos que pagan el trabajo de diseñarlos

Revisión de código con verificadores en paralelo. Fan-out del diff hacia nodos especializados: seguridad, riesgo de regresión, contrato de API, cobertura de tests. Cada uno con contexto pequeño y un único criterio. Fan-in en un nodo que deduplica y ordena por severidad, con precedencia definida. Un solo agente leyendo el diff completo encuentra lo obvio y se queda sin aire.

Migración con worktrees aisladas. Una worktree de git por módulo. El aislamiento deja de ser promesa y pasa a ser propiedad del sistema: dos nodos no pueden escribir el mismo archivo porque ni ven el mismo directorio de trabajo. Barrera antes del merge, y el rollback se vuelve descartar una worktree. Es el patrón que corremos con Relentless.

Investigación multi-modal. Fan-out por fuente — documentación interna, código, web, planillas — con la herramienta correcta por nodo, y fan-in con precedencia explícita para cuando las fuentes se contradicen. Sin esa regla, el agregador le cree a la más elocuente. Es lo que aprendimos construyendo gobernanza en BRAIN MAKER: la procedencia no es adorno, es el criterio de desempate.

Cuándo gana el grafo determinista — y cuándo pierde

El grafo gana cuando el trabajo es descomponible, el criterio de aceptación es verificable por máquina, necesitas auditar el resultado o repetir la misma salida mañana, o el costo importa — porque un nodo pequeño corre bien en un modelo más chico.

El grafo pierde cuando el problema es exploratorio y todavía no sabes los pasos. Dibujar un grafo para un problema que no entendiste es adivinar con diagrama. Ahí un solo agente con buenas herramientas es el instrumento correcto.

Mi regla práctica: un solo agente para descubrir el grafo, el grafo para correr en producción. Confundirlos sale caro en ambas direcciones — un grafo prematuro congela la exploración, un agente suelto en producción ni escala ni audita.

Herramientas, sin reseña de fachada

El ecosistema ya convergió a este vocabulario. LangGraph, de LangChain, es el ejemplo más explícito: nodos, aristas estáticas y condicionales, estado compartido, fan-out y fan-in como primitivas. Si quieres una librería que ya piensa en grafos, empieza ahí.

No voy a fingir que usamos una sola librería para todo: buena parte de lo que corremos es un grafo hecho a mano, con git como capa de estado. El punto no es qué librería eliges. Es que el grafo existe igual: si no lo dibujas, queda implícito dentro de un prompt de dos mil palabras, sin dueño y sin verificación.

El grafo es el mapa. El motor que lo recorre es otro tema, y escribí sobre eso en loops de agentes. Si quieres dejar de apostar a los prompts y empezar a diseñar arquitectura, hablá con nosotros o mirá nuestra consultoría agéntica.

Un árbol no crece en línea recta. Crece en ramas — y cada rama sabe de dónde vino.