IA 360
Fundamentos IA

Ingeniería de grafos: la señal, el gasto y lo que no sabemos

Los grafos de agentes responden a un problema real de contexto, pero sus porcentajes no comparten denominador. Una guía para separar arquitectura, gasto y evidencia.

Admin IA360 8 min de lectura Generado con IA Read in English
Ingeniería de grafos: la señal, el gasto y lo que no sabemos

El 13 de junio de 2025, Anthropic publicó una escena que parece resolver por sí sola el debate sobre los grafos de agentes. Ante una búsqueda amplia —identificar a los consejeros de las empresas tecnológicas del S&P 500—, un agente principal repartió caminos de investigación entre subagentes y después reunió sus hallazgos. En una evaluación interna de investigación, ese sistema multiagente superó en un 90,2% a un agente único Claude Opus 4.

El porcentaje es real. También es estrecho: pertenece a una evaluación interna, a una arquitectura concreta y a tareas de investigación con rutas independientes. No demuestra que cualquier proceso mejore al dibujar un router, varias cajas y una puerta de revisión. La pregunta útil no es si el grafo impresiona, sino qué compró cada flecha, frente a qué alternativa y con qué presupuesto.

Qué es un grafo, sin humo

En buena parte de este discurso, “grafo” nombra un flujo de trabajo: una salida alimenta otra etapa, una condición elige camino y algunas ramas pueden ejecutarse a la vez. El código puede ser perfectamente válido. La confusión empieza cuando esa topología se presenta como prueba de inteligencia colectiva.

La documentación de Anthropic sobre sistemas de agentes separa dos categorías. Un workflow orquesta modelos y herramientas mediante rutas de código predefinidas; un agente decide dinámicamente su proceso y el uso de herramientas. Una cadena, un enrutador o una bifurcación paralela no se convierten en un equipo autónomo porque el diagrama tenga más nodos. Son mecanismos útiles, pero responden a otra pregunta: cómo controlar el recorrido.

Esta distinción no rebaja la ingeniería. La mejora. Permite medir cada decisión por lo que hace: una ruta fija aporta previsibilidad; una delegación dinámica aporta flexibilidad; una segunda llamada puede aportar una comprobación distinta. Si dos cajas ejecutan el mismo criterio, comparten el mismo contexto y consumen la misma fuente defectuosa, el plural no crea independencia.

La señal: el contexto sí se degrada

La premisa más sólida del género es que un único contexto no crece gratis. En una guía publicada el 29 de septiembre de 2025, Anthropic describe el context rot: al aumentar los tokens de la ventana, disminuye la capacidad de recuperar con precisión información contenida en ella. La pendiente cambia entre modelos, pero la compañía dice observar el fenómeno en todos.

La explicación que ofrece es arquitectónica. Para n tokens, la atención del transformador establece relaciones pareadas, mientras el modelo dispone de un presupuesto de atención finito. Esto no significa que un token tardío vuelva inútil al sistema; la propia guía habla de un gradiente, no de un precipicio. Significa que “cabe en la ventana” no equivale a “recibirá la misma atención”.

Los subagentes con contexto limpio son una mitigación documentada. Cada uno puede explorar mucho y devolver al coordinador un resumen corto, sin trasladarle toda su traza. Pero la misma fuente enumera antes la compactación y las notas estructuradas. El multiagente es una herramienta para tareas donde la exploración paralela compensa; no es el remedio automático para cualquier conversación larga.

El 90,2% no viaja solo

La evaluación interna de Anthropic sí enfrenta un sistema multiagente —Opus 4 como coordinador y subagentes Sonnet 4— con un agente único Opus 4. El resultado comunicado es ese 90,2% de ventaja en investigación. La página no publica allí el número de casos, el presupuesto de tokens de cada contendiente ni el coste por respuesta correcta. Por eso el dato permite decir “funcionó mejor en esta evaluación”, no “los grafos mejoran un 90,2%”.

La misma página contiene otras dos mediciones, pero sus denominadores son distintos. En datos generales de uso, un agente consume típicamente unas cuatro veces los tokens de una interacción de chat y un sistema multiagente unas quince veces los de un chat. Ese 15× no compara el ganador del 90,2% con el agente único de la prueba. En otro análisis, esta vez sobre BrowseComp, el gasto de tokens por sí solo explica el 80% de la varianza de rendimiento; llamadas a herramientas y modelo elegido completan los tres factores que explican el 95%.

CifraCompara conEn qué evaluaciónTexto de la fuente
+90,2 %el agente único Opus 4interna de investigación«a multi-agent system with Claude Opus 4 as the lead agent and Claude Sonnet 4 subagents outperformed single-agent Claude Opus 4 by 90.2% on our internal research eval»
×4 y ×15 en tokensel chat, no el agente úniconinguna: «in our data»«agents typically use about 4× more tokens than chat interactions, and multi-agent systems use about 15× more tokens than chats»
80 % de la varianza— (factor explicativo)BrowseComp«three factors explained 95% of the performance variance in the BrowseComp evaluation … token usage by itself explains 80% of the variance»
coste del +90,2 %el agente únicoNo publicado. El múltiplo conocido compara con el chat, no con la alternativa que se propone sustituir.
Las tres mediciones que circulan juntas sobre sistemas multiagente no comparan contra lo mismo. Extraídas literalmente de la documentación de ingeniería de Anthropic (multi-agent research system) el 04/08/2026. La última fila es la cifra que nadie ha publicado.

Juntar las tres cifras produciría una historia limpia y falsa. La conclusión honesta es más incómoda: gastar más cómputo suele comprar más intentos y más cobertura, pero la documentación pública no separa cuánto de aquella mejora interna vino del presupuesto y cuánto de la arquitectura.

Un grafo es exactamente tan impresionante como la línea base y el presupuesto con los que se compara. Sin igualdad de recursos o una curva coste-rendimiento, el diagrama describe una forma de gastar, no demuestra una forma superior de pensar.

Paralelizar no es repartir

La topología ayuda cuando las ramas pueden avanzar sin esperarse. Buscar documentos en varias direcciones es un caso claro: cada subagente explora con su propia ventana y el coordinador comprime resultados. El beneficio se reduce cuando todos necesitan el mismo estado o cuando cada paso depende del anterior.

Anthropic advierte en su informe sobre el sistema multiagente que las tareas con contexto compartido o muchas dependencias no encajan bien hoy. Añade que la mayoría de tareas de programación contienen menos trabajo verdaderamente paralelizable que la investigación y que los modelos aún coordinan y delegan con dificultad en tiempo real.

Pensemos en un cambio que modifica una base de datos, su API y una migración. Tres agentes pueden escribir en paralelo, pero las decisiones no son independientes: comparten esquema, orden de despliegue y criterio de compatibilidad. Si cada rama parte de una versión distinta de ese estado, el fan-out no elimina el problema de contexto; lo replica. La pregunta previa al grafo es qué fracción del trabajo puede separarse sin compartir supuestos ni esperar resultados.

Más nodos, más lugares donde buscar el fallo

Una promesa frecuente es que el grafo facilita observar y depurar. Dividir una traza puede ayudar a inspeccionarla, pero localizar la causa sigue lejos de estar resuelto. El paper Who&When, revisado el 2 de junio de 2025, reunió registros de fallos de 127 sistemas multiagente con anotaciones sobre el agente responsable y el paso decisivo. El mejor método acertó el agente en el 53,5% de los casos y el paso en el 14,2%; algunos métodos quedaron por debajo del azar.

Esos resultados no prueban que todo grafo sea más difícil de depurar que todo bucle. Sí impiden vender la atribución de fallos como una propiedad ya resuelta del diseño. Registrar cada mensaje permite reconstruir una trayectoria; no garantiza saber qué decisión causó el resultado ni dónde habría que intervenir.

Separar constructor y revisor también tiene fundamento, pero no crea un oráculo. Un estudio sobre 20 modelos, revisado el 2 de junio de 2026, define el sesgo de autopreferencia como una desviación por la que los modelos favorecen o desfavorecen sistemáticamente sus propias salidas al evaluarlas. Un revisor separado puede reducir esa contaminación; si comparte rúbrica, datos o punto ciego, seguirá necesitando calibración contra resultados externos y revisión humana responsable.

La primera alternativa es un sistema más sencillo

La guía de Anthropic de diciembre de 2024 empieza por una recomendación que los diagramas suelen relegar: buscar la solución más simple y aumentar la complejidad sólo cuando haga falta. Puede significar no construir un sistema agente. Para tareas definidas, una sola llamada con recuperación, ejemplos y una prueba determinista puede ser suficiente.

Eso cambia el orden de la decisión. Primero se mide una línea base sencilla. Después se añade una etapa y se comprueba si compra precisión, cobertura o velocidad suficientes para pagar latencia, tokens, coordinación y mantenimiento. La sofisticación deja de ser una identidad profesional y se convierte en una hipótesis que puede fallar.

Lo que no sabemos

Las fuentes abiertas no ofrecen una tasa general de éxito de grafos frente a bucles. Tampoco sostienen que “nueve de cada diez” equipos no repartan el trabajo: es una cifra sin medición declarada, no una mentira demostrada. Las supuestas cuatro eras —prompt, contexto, bucle y grafo— son una narración útil para ordenar una historia, no una periodización técnica validada.

Tampoco sabemos cuántos tokens costó el 90,2% frente al agente único ni el coste por resultado de aquella evaluación. El múltiplo público compara agentes y multiagentes con chat, no el grafo con la alternativa que pretende sustituir. Y el 80% procede de BrowseComp, otra evaluación. Tres cifras con tres bases no forman una ecuación.

Faltan además mediciones que importan en producción: latencia de extremo a extremo, tasa de tareas que necesitan intervención humana, coste de mantener las rutas, frecuencia de conflictos entre ramas y capacidad real de atribuir un fallo. Sin ellas, “funcionó” puede significar desde más respuestas encontradas hasta más gasto sin valor neto.

El oficio que nace

Cuando dibujar agentes se abarata, el trabajo valioso pasa a demostrar por qué deben estar ahí. La capacidad transferible no es memorizar una colección de patrones, sino auditar la comparación: ¿cuál es la línea base?, ¿usan el mismo modelo y presupuesto?, ¿qué porcentaje de la tarea es independiente?, ¿qué coste tiene cada resultado correcto?, ¿cómo se localiza el agente y el paso responsables cuando falla?, ¿qué alternativa más simple se probó primero?

Una arquitectura merece crecer cuando responde esas preguntas con mediciones, no con flechas. La ingeniería de grafos no consiste en poblar un diagrama. Consiste en justificar cada frontera de contexto, cada gasto adicional y cada punto de responsabilidad. Si una flecha no compra una mejora comprobable, no es arquitectura: es FOMO dibujado.

Este artículo se ha elaborado con inteligencia artificial bajo supervisión editorial humana.

Compartir este artículo

Este sitio web utiliza cookies para mejorar la experiencia de navegación. Política de cookies.

↑↓ navegar ↵ abrir esc cerrar