Un README anterior de CrewAI anunciaba “5,76x más rápido que LangGraph” para un ejemplo concreto de QA. AIMultiple, en cambio, encontró aproximadamente el triple de tiempo y tokens que LangChain en una tarea de una sola herramienta. Ambos comparan ejecución, pero con tareas y frameworks de referencia distintos. Sin esa base de medida, un resultado local parece una victoria universal.
La afirmación histórica decía que CrewAI se ejecutaba 5,76 veces más rápido que LangGraph en ciertos casos, como el ejemplo enlazado de QA. Se refería a ejecutar ese ejemplo, no al tiempo que necesita una persona para programarlo. En el README actual, esa cifra no es una garantía general de rendimiento.
Cinco veces y tres cuartos más rápido. Dicho así, suena como una razón para cambiar de framework mañana.
Solo que no es verdad. No del modo que crees.
El número es real. El test que lo produjo existe. Pero lo que "más rápido" significa en esa frase no es lo que la mayoría de lectores asume. Y la brecha entre lo medido y lo inferido está haciendo bastante trabajo — probablemente más del que ningún equipo de marketing debería dejar a un único número.
Este post va de leer benchmarks de frameworks con escepticismo, con el caso CrewAI-vs-LangGraph como ejemplo trabajado. Si eliges un framework de orquestación multi-agente en 2026, esto importa. Si enseñas AI engineering, importa aún más, porque la capacidad de olfatear un benchmark engañoso es una habilidad de carrera.
Lo que realmente dice la página de CrewAI#
El README está formulado con cuidado. Dice "5,76x más rápido en ciertos casos como este ejemplo de tarea QA (ver comparación)". El enlace apunta a un repositorio donde ambos frameworks resuelven el mismo problema de question-answering. CrewAI termina antes en ese escenario concreto. Coge los números en bruto, divide — 5,76x.
Hasta ahí, razonable. Nadie inventa datos. El cronómetro no miente.
El problema es qué está midiendo realmente "este ejemplo de tarea QA". Porque un framework multi-agente puede ser "más rápido" de al menos cuatro maneras distintas, y no son intercambiables.
Los cuatro sabores de "más rápido"#
El framework A puede ser más rápido que el framework B en:
Velocidad de desarrollo — cuánto tarda un humano en escribir la primera versión funcional. Se mide en líneas de código, tiempo de setup, horas hasta el primer test en verde.
Velocidad de ejecución — cuánto tarda el framework en completar una tarea en tiempo de ejecución, una vez escrita. Se mide en segundos wall-clock por run.
Eficiencia de tokens — cuántos tokens se consumen por unidad de trabajo. Relevante porque los tokens cuestan dinero y plazas de ventana de contexto.
Comportamiento al escalar — cómo crecen la latencia y el coste a medida que añades más agents, tools o iteraciones. Un framework que va rápido con tres agents puede caer en picado con diez.
Son dimensiones distintas. Un framework puede dominar en una y perder en otra. En esta afirmación concreta de CrewAI, “5,76x más rápido” sí significaba velocidad de ejecución. El error sería deducir de ahí un desarrollo más rápido o una ventaja en cualquier tarea.
Lo que encontró el benchmark independiente#
El test independiente más limpio que he visto es el benchmark de AIMultiple de principios de este año. Hicieron correr cuatro frameworks — LangChain, LangGraph, AutoGen, CrewAI — sobre cinco tareas, dos mil runs en total. Mismos problemas, mismos modelos, cronómetro en marcha, metodología publicada.
En la tarea de una sola herramienta del test de AIMultiple, CrewAI consumió aproximadamente el triple de tokens que LangChain y tardó aproximadamente el triple. Es un resultado para esa tarea y configuración. No compara el ejemplo histórico de QA ni establece una clasificación para cualquier agente en producción.
Misma familia de frameworks. Conclusión opuesta. ¿Qué pasó?
La reconciliación#
Si sigues ambas afirmaciones con cuidado, encajan.
La cifra histórica de 5,76x mide tiempo de ejecución en un ejemplo de QA. No mide velocidad de desarrollo ni demuestra una ventaja fija en cantidad de código o tiempo de prototipado. Los agentes por roles pueden facilitar la comprensión del diseño, pero la rapidez con la que construyes un prototipo fiable debe medirse en tu propia tarea.
AIMultiple también mide tiempo de ejecución y consumo de tokens. Las llamadas al modelo, el número de agentes, las herramientas y los pasos de revisión pueden cambiar el resultado. De ello no se deduce una pausa fija de cinco segundos por llamada a herramienta. Los pasos adicionales pueden ser sobrecoste en tareas sencillas y útiles en otras difíciles; hay que evaluar calidad y esfuerzo juntos.
Los resultados aparentemente opuestos se refieren, por tanto, a la misma dimensión con configuraciones experimentales diferentes. Necesitas la misma tarea, modelos comparables, números de agentes y llamadas a herramientas comparables, y un objetivo común de calidad antes de decidir.
Por qué esto importa al elegir framework#
Si estás eligiendo un framework multi-agente, esta distinción es práctica.
La velocidad de desarrollo importa más al prototipar, cuando eres pequeño, cuando aún no sabes si el problema merece ser resuelto. La velocidad de ejecución y la eficiencia de tokens importan más en escala, cuando los tokens cuestan dinero real, cuando la latencia es visible para el usuario.
CrewAI es genuinamente bueno en la primera fase. Hay equipos que sacan prototipos multi-agente funcionales en un fin de semana. Eso tiene valor, sobre todo aprendiendo.
La segunda fase puede encarecerse si el prototipo no cumple requisitos de estado, recuperación, pruebas o coste. Cambiar de framework puede exigir modificaciones. No se puede establecer un plazo general de seis meses ni un porcentaje de reescritura del 50 al 80 sin proyectos y cálculos identificados. Prueba esos requisitos en tu propio flujo antes de elegir.
CrewAI puede encajar en un prototipo y LangGraph en flujos con estado explícito. Los requisitos y pruebas determinan si hace falta migrar después, no el nombre del framework por sí solo.
El patrón detrás del caso concreto#
Aléjate de CrewAI. Es una plantilla aplicada en todo el mundo de los frameworks.
"El framework X es diez veces más rápido que el framework Y" es una frase que casi siempre se derrumba si preguntas. ¿Más rápido en qué? ¿Medido cómo? ¿En qué hardware? ¿Con qué modelos? ¿Bajo qué carga? ¿Para los developers que escriben el código, o para la máquina que lo ejecuta?
Los benchmarks en los que merece la pena confiar comparten unas propiedades. Especifican la dimensión que miden. Corren varias tareas, no un único escenario cherry-picked. Publican su metodología. Reconocen trade-offs. El estudio de AIMultiple hace todo eso. El README de CrewAI hace una cosa — especifica la tarea — y para ahí.
Un hábito útil al leer cualquier comparación de frameworks: pausa en el número y pregunta "velocidad de qué". Si el artículo no lo aclara, el número no cuenta. Esto aplica a comparaciones de bases de datos, shootouts de frameworks web, claims de velocidad de compiladores, benchmarks de inferencia, cualquier sabor de marketing de engineering.
Para frameworks de IA en concreto, hay otra dimensión que rara vez se mide pero importa enormemente: el comportamiento ante fallos parciales. Los sistemas multi-agente fallan de formas raras. Un agent devuelve una respuesta malformada, un tool-call se va a timeout, un agent posterior se confunde con el ruido. ¿Cómo lo maneja el framework? LangGraph tiene primitivas de retry y state-checkpointing integradas. CrewAI también, pero menos granulares. AutoGen lo maneja a través de patrones de conversación más difíciles de razonar. Ningún benchmark que haya visto lo mide bien, pero es probablemente lo que separa una demo de un sistema de producción más que cualquier número crudo de velocidad.
Lo que añade la experiencia propia de Anthropic#
Anthropic publicó en junio del año pasado un post de engineering detallado sobre la construcción de su sistema multi-agente de Research. Las iteraciones tempranas tenían fallos que ningún benchmark pillaría: agents spawneando cincuenta subagents por una sola consulta simple, buscando sin parar fuentes que no existían, ahogándose mutuamente en status-updates. El arreglo no fue un framework más rápido. Fueron restricciones más duras — límites de rondas, reglas explícitas de contribución, criterios de convergencia.
Anthropic informó que su sistema completo con Claude Opus 4 como orquestador y Claude Sonnet 4 como subagents superó al único Claude Opus 4 en un 90,2 por ciento en evaluaciones internas de investigación. El contraste no aísla las restricciones: combinación de modelos, herramientas, paralelismo y presupuesto de tokens forman parte del sistema.
Las reglas y orquestación importan junto al framework. Esto no demuestra un ganador universal entre CrewAI y LangGraph. Compara tareas reales con presupuestos consistentes, tratamiento de errores y calidad medida.
Tres preguntas para cualquier claim de framework#
Si estás delante de una comparación de frameworks — eligiendo uno, escribiendo sobre uno, o enseñando uno — tres preguntas separan la señal honesta del ruido de marketing.
Primera: ¿qué dimensión? Si un post dice "X es más rápido" sin especificar velocidad de desarrollo, velocidad de ejecución, coste en tokens o comportamiento al escalar, la afirmación no es útil. Pregunta cuál.
Segunda: ¿cuál es el contra-caso? Todo framework que gana en una dimensión pierde en otra. Si el artículo no menciona un trade-off, te está vendiendo algo. El trade-off no está escondido; el autor simplemente decidió no incluirlo.
Tercera: ¿cómo se ve el failure mode del framework? ¿Bajo qué condiciones se rompe? Si la documentación no nombra failure modes, el framework o bien no ha sido usado en escala, o bien el equipo te está vendiendo la demo.
La afirmación histórica de 5,76x identifica una dimensión de ejecución y un ejemplo concreto. No ofrece una victoria universal ni una visión completa de costes, calidad y fallos. La pregunta útil es si la configuración enlazada corresponde a tu propia tarea.
Una vez has visto uno de estos claramente, los ves en todas partes. Esa es la habilidad que merece la pena construir.
