GraphBit: orquestación de agentes con DAG y sin alucinaciones de rutas

El 15 de mayo, un equipo de investigación publicó en arXiv el paper GraphBit: A Graph-based Agentic Framework for Non-Linear Agent Orchestration. El resultado más llamativo: en el benchmark GAIA —que mide capacidades de agentes con cero herramientas, documentos y acceso web— GraphBit alcanza un 67,6 % de precisión y registra cero alucinaciones inducidas por el framework. Es el mejor resultado entre los seis frameworks comparados en ese conjunto de pruebas.

El dato merece atención porque GAIA no es un benchmark trivial. Combina tareas que requieren razonamiento encadenado, recuperación de información y uso de herramientas externas, precisamente el tipo de flujos donde los sistemas basados en orquestación por prompts suelen fallar de formas difíciles de depurar.

El problema que intenta resolver

La mayoría de los frameworks de agentes actuales —incluyendo varios populares en el ecosistema MCP— delegan al propio modelo la decisión de qué herramienta invocar a continuación, qué rama del flujo tomar y cuándo detenerse. Esto funciona bien en tareas cortas, pero en pipelines largos aparecen tres patrones de fallo bien documentados: el modelo alucina la transición hacia un agente que no debe activarse, entra en bucles entre dos pasos o produce ejecuciones no reproducibles porque la misma cadena de prompts puede resolverse de manera diferente en cada llamada.

GraphBit propone separar quién razona de quién gobierna el flujo. Los agentes se definen como funciones tipadas —entrada estructurada, salida estructurada— y toda la lógica de enrutamiento, transiciones de estado e invocación de herramientas recae sobre un motor escrito en Rust. El grafo que describe el workflow es un DAG (grafo acíclico dirigido) definido explícitamente antes de la ejecución, no inferido en tiempo real por el modelo.

Cómo funciona la arquitectura

Tres elementos distinguen a GraphBit de alternativas como LangGraph o frameworks similares:

Motor de ejecución determinista. El motor Rust evalúa predicados sobre el estado estructurado para decidir qué rama activar. No le pregunta al modelo «¿qué hago ahora?»; consulta condiciones definidas en el grafo. El resultado es que dos ejecuciones con el mismo input producen el mismo recorrido, lo que facilita la auditoría.

Ejecución paralela de ramas. El motor puede activar varias ramas del DAG simultáneamente cuando no existe dependencia entre ellas, lo que reduce la latencia en pipelines con pasos independientes.

Arquitectura de memoria en tres niveles. El paper distingue entre espacio efímero (scratch space por tarea), estado estructurado persistente durante la sesión y conectores externos. Esta separación evita que el contexto de etapas anteriores contamine las siguientes, un problema que los autores llaman «context bloat en cascada» y que degrada el razonamiento en pipelines largos.

Para quién es relevante esto

Para equipos que construyen agentes en producción con Claude Code —usando subagentes, MCP servers o hooks de ciclo de vida— el paper ofrece un argumento empírico a favor de definir los flujos de forma explícita en lugar de depender de la capacidad del modelo para autodirigirse. No es que los LLMs no puedan tomar decisiones de enrutamiento; es que cuando lo hacen, la reproducibilidad y la auditoría se complican considerablemente.

El enfoque DAG no es nuevo en ingeniería de software —es la base de herramientas como Apache Airflow o Prefect para orquestación de datos— pero aplicarlo de forma rigurosa a pipelines de agentes LLM, con un motor separado del modelo, es una apuesta arquitectónica con implicaciones prácticas claras: los fallos de flujo dejan de ser «el modelo se confundió» y pasan a ser errores auditables en la definición del grafo.

El código del framework no está disponible públicamente en el momento de escribir este post, pero el paper detalla la especificación con suficiente detalle para evaluar si el enfoque encaja con casos de uso concretos.

---

Desde EP, vemos con interés que la investigación en orquestación de agentes esté recuperando principios de ingeniería de workflows clásicos. Que el benchmark diga 67,6 % con cero alucinaciones de framework es un número concreto que vale la pena seguir de cerca cuando el código sea público y reproducible.