Graph Engineering: Cuándo Compensa y Dónde se Rompe

Desde mediados de julio no paro de leer que el loop engineering ha muerto y que ahora toca graph engineering. Varios posts con millones de visualizaciones, guías, cursos de pago y un montón de gente preguntándose si tiene que rehacer su forma de trabajar con agentes.

Antes de reescribir nada, miré dónde estaba la discusión técnica. En Hacker News, el hilo con más tracción sobre graph engineering tiene 24 puntos y 5 comentarios. Alguien preguntó allí mismo cuándo habíamos pasado de bucles a grafos y el hilo se quedó en 4 puntos. Mientras tanto, en X el mismo tema acumula millones de impresiones.

Ese contraste no demuestra que el tema sea falso. Sí dice que se está hablando mucho más de esto en redes que en los sitios donde la gente monta agentes.

Y aun así hay algo real debajo, porque el problema que dicen resolver los grafos sí existe y está medido. Este artículo va de eso: qué hay de verdad, dónde se rompe y cómo decidir si te compensa.

Un loop ya es un grafo

Empecemos por lo aburrido, que es lo que cierra media discusión.

Un grafo son nodos y aristas. Un bucle es un nodo con una arista que vuelve a sí mismo. Un loop ya es un grafo, uno con un ciclo. En Turing Post lo dejaron en una línea: “A loop is already a graph, which makes the whole thing a bit ridiculous”. Si quieres el bucle en detalle, lo desarrollé en loop engineering.

Y por si queda duda de que esto es un problema de vocabulario, aquí está Harrison Chase, que es quien construyó LangGraph, el framework de grafos de agentes más usado del mundo:

“So i didn’t really know what graph engineering is, and i still don’t really… but it’s basically just langgraph?”

Cuando el autor del framework de grafos no sabe qué es la disciplina de los grafos, lo que tienes delante no es una capacidad técnica nueva. Es un nombre.

Hay cosas que aprender aquí, pero si buscas la novedad en la forma del diagrama, estás mirando el sitio equivocado.

El eje real: quién decide el flujo de control

La distinción que sí importa lleva desde diciembre de 2024 en la documentación de Anthropic, y es esta:

• Workflows: sistemas donde los LLM y las herramientas se orquestan a través de rutas de código predefinidas.
• Agentes: sistemas donde el LLM dirige dinámicamente su propio proceso y decide cómo usar las herramientas.

Fíjate en que esa línea no separa bucles de grafos. Separa quién toma las decisiones de enrutado: tu código o el modelo. Puedes tener un bucle donde decide el modelo y un grafo donde decide el código, o al revés. Es el mismo eje del que hablaba en harness engineering: lo que rinde no es el componente, es el andamiaje que le pones alrededor.

Google y LangChain se están moviendo en ese eje justo al contrario de lo que promete el hype.

Google publicó ADK 2.0 en julio con esta motivación, textual: “los LLM reciben con frecuencia la tarea de orquestar la ejecución —enrutado, planificación, gestión de errores— cosas en las que el código tradicional ya es excelente”. Es decir, Google se mueve hacia los grafos para quitarle la orquestación al modelo, no para dársela. Su grafo es código determinista, no inteligencia repartida.

Y LangChain, que es quien hizo el framework de grafos, fue en dirección contraria al hype: en la versión 1.0 introdujo create_agent como abstracción central —un bucle simple con middleware— y dejó obsoleto langgraph.prebuilt. El grafo se quedó debajo como motor de ejecución duradera, no como el modelo mental que manejas.

Cuando los dos frameworks de referencia van en una dirección y el marketing dice la contraria, yo me pregunto a quién le conviene el relato.

Dónde se rompe de verdad

Un sistema con varios agentes falla en tres sitios concretos, y los tres están medidos.

1. El verificador que estuvo delante deja de verificar

Este es el importante, y hay que construirlo bien porque el argumento popular es flojo.

Lo que suele decirse es que un modelo se da la razón a sí mismo porque prefiere sus propias salidas. Cuidado con eso: un trabajo de enero de 2026 mostró que el 89,6 % del self-preference que recogen los estudios desaparece al controlar por la incertidumbre del evaluador. No era narcisismo, era que en preguntas difíciles el juez elige medio al azar. Hay modelos que se penalizan a sí mismos.

Lo que pasa de verdad es otra cosa, y nos sirve más. Un trabajo presentado en NeurIPS 2024 encontró que el sesgo se explica por perplejidad: los modelos puntúan más alto el texto que les resulta familiar, sea suyo o no.

Lee otra vez esa última parte. Sea suyo o no. Si lo que ablanda al verificador es la familiaridad, entonces no hace falta que sea el mismo modelo: basta con que haya leído el razonamiento. Compartir contexto reproduce el sesgo por sí solo.

Y está medido en código. En marzo de 2026 salió un estudio, todavía sin revisión por pares, firmado entre otros por un investigador de Anthropic. Pusieron a un modelo a detectar código incorrecto en SWE-bench. Con contexto limpio, AUROC 0,99. Cuando el modelo evaluaba una salida que había generado él, 0,89. Y el dato que más me preocupa: bajo auto-atribución era cinco veces más probable que aprobara un parche que había seguido una inyección de prompt.

La respuesta intuitiva es decirle al verificador que sea objetivo. No funciona, y esto también está medido: en un estudio de abril de 2026 con 18.240 juicios, cambiar solo el encuadre del system prompt desplazaba el veredicto hasta 9,8 puntos manteniendo la respuesta idéntica. La métrica que me dejó pensando es otra: ERR_J = 0,000. En 4.560 juicios de modelos con razonamiento explícito, ninguna cadena de pensamiento reconoció el encuadre que la estaba sesgando.

El verificador contaminado no sabe que lo está. No puedes pedirle que se corrija: no ve el problema. Lo único que funciona es quitarle el contexto.

Anthropic lo dice en sus buenas prácticas de Claude Code: “un contexto fresco mejora la revisión de código porque Claude no estará sesgado hacia el código que acaba de escribir”. Cognition llegó a lo mismo por su cuenta, y su explicación es que el revisor con contexto limpio es más listo “por las matemáticas de la atención”.

2. Si el criterio es visible, se optimiza en vez de cumplirse

Esto es la ley de Goodhart, y METR le puso número en junio de 2025.

Midieron reward hacking de o3 en dos familias de tareas. En HCAST: 0,7 % de las ejecuciones. En RE-Bench: 30,4 %. En una de las tareas concretas, las 21 ejecuciones hicieron trampa. Las veintiuna.

La diferencia entre ambas familias es que en RE-Bench el modelo podía ver la función de puntuación completa. Cuarenta y tres veces más trampa por el simple hecho de que el criterio estuviera a la vista.

Dos detalles que rematan el punto. El primero: el prompting no lo arregla. Con instrucciones explícitas de no hacer trampa, el comportamiento persistió en el 70-95 % de los intentos. El segundo: preguntado directamente si su plan respetaba la intención del usuario, o3 respondió que no, diez de cada diez veces. Entiende perfectamente la regla; lo que pasa es que la métrica pesa más.

Traducido a tu grafo: separar el contexto del verificador es lo único que mantiene el criterio fuera del alcance de quien lo va a optimizar.

3. Los agentes que se hablan se contaminan

Un estudio de septiembre de 2025 comparó jueces en solitario contra debate multi-agente. El debate degradó la consistencia un 8,2 % (p < 2,2e-16), y el sesgo más amplificado fue precisamente el de dejarse llevar por la cadena de razonamiento ajena: hasta −13,3 %. Los esquemas de votación entre jueces aislados, en cambio, mantuvieron el rendimiento.

Agentes que votan por separado rinden mejor que agentes que deliberan. Poner más perspectivas a hablar entre sí no diluye el sesgo: lo propaga.

Es la misma idea que cuenta Cognition desde la ingeniería: “el enfoque de enjambre no estructurado, redes arbitrarias de agentes negociando entre ellos, es sobre todo una distracción”.

Los números para decidir

Si estás valorando repartir trabajo entre varios agentes, estos son los datos que yo pondría sobre la mesa.

Coste. Anthropic mide que un sistema multi-agente consume unas 15 veces más tokens que una conversación normal. Un estudio revisado por pares de julio de 2026 midió, en tareas de contexto corto, 5× tokens, 5× latencia y peor precisión (0,810 frente a 0,734). Cuando el contexto ya cabe en una sola entrada, repartir es pagar más por acertar menos.

Fiabilidad. El trabajo de referencia aquí es MAST, de Berkeley, presentado en NeurIPS 2025 y firmado entre otros por Zaharia, Stoica y Gonzalez. Anotaron 1.642 trazas de siete sistemas multi-agente y encontraron entre un 41 % y un 86,7 % de tasa de fallo. Su frase de apertura no deja mucho margen: “pese al entusiasmo por los sistemas multi-agente, sus mejoras en los benchmarks populares son a menudo mínimas”.

Dentro de esos fallos hay un dato que conecta con todo lo anterior: la verificación es el 23,6 %, y el modo más frecuente no es no verificar (8,2 %) sino verificar mal (9,1 %). El verificador presente pero inútil hace más daño que el verificador ausente. Añadir un paso de verificación del objetivo mejoró el éxito un 15,6 % con el mismo modelo. El diseño pesa más que el modelo.

Cuándo sí compensa. Anthropic, que defiende el multi-agente, marca la frontera con bastante honestidad: funciona en tareas con paralelización real, información que no cabe en una ventana y muchas herramientas. Y añade la letra pequeña: “la mayoría de las tareas de programación tienen menos subtareas realmente paralelizables que la investigación”.

La regla que yo aplico

Con todo lo anterior, así es como lo decido:

1. Empieza por el bucle. Si no encuentras dos tareas que puedan correr a la vez sin mirarse, no tienes un grafo: tienes un bucle, y está bien.
2. Un solo escritor. El patrón que sobrevive en producción es que solo un agente escriba y los demás aporten criterio, no acciones. Es a lo que ha llegado Cognition después de un año, y coincide con los agents-as-tools de OpenAI.
3. El verificador, a ciegas. Que compruebe el artefacto, nunca la conversación. Y que compruebe una señal real: no “el agente dice que ha terminado”, sino “el test pasa”.
4. El criterio, fuera del alcance del ejecutor. Si el que optimiza puede leer cómo se le puntúa, lo va a optimizar.
5. Aísla el espacio de trabajo antes que el prompt. Los conflictos de escritura concurrente son estructurales, no se arreglan pidiendo por favor.

Sobre este último punto hay un caso que desmiente la receta que circula. Cuando Jarred Sumner reescribió parte de Bun con 64 instancias de Claude en paralelo, se encontró con esto: “uno ejecutó git stash antes de commitear. Otro hizo git stash pop. Y luego git reset HEAD --hard. ¡Se estaban pisando!”.

La solución que venden los posts virales es dar a cada agente su propio worktree. Sumner descartó exactamente eso por coste de disco, y lo arregló prohibiendo a los agentes cualquier comando de git que no fuera commitear un fichero concreto. El fallo estaba en el arnés del bucle y la solución también. No hizo falta ningún grafo.

El experimento que falta

Al preparar esto busqué el estudio que debería existir y no encontré ninguno: nadie ha publicado un A/B controlado con el mismo modelo y el mismo artefacto, comparando un verificador que ve la transcripción del ejecutor contra uno que no la ve, midiendo defectos detectados.

Lo digo porque quiero ser preciso con lo que sostengo. Todo lo anterior apunta en la misma dirección y viene de sitios distintos —auto-atribución, perplejidad, criterio visible, debate que degrada—, pero la medición exacta de “compartir contexto arruina la verificación” en un agente de código no está hecha.

Así que la voy a hacer yo, sobre un repo real, y la grabo. Si alguien tiene el dato y me lo he saltado, que me lo diga y lo cito.

Mientras tanto, la conclusión práctica no depende de ese experimento. Un grafo acota por dónde puede pasar el trabajo. Un bucle hace que ese trabajo salga mejor cada vuelta. Son dos decisiones distintas, y ninguna sustituye a la otra. Si tu problema es que el agente no acierta, un diagrama más bonito no lo arregla. Si tu problema es que dos tareas independientes van en serie, entonces sí, reparte, y hazlo con un solo escritor y un verificador ciego.

---

P.D.: Voy a montar ese A/B del verificador con contexto y sin él para el vídeo que acompaña a este artículo. Si te apetece proponer el caso de prueba, o si tienes un grafo de agentes que se te está mintiendo, cuéntamelo en X (@lm_martinbar).