El README de CrewAI dice "5,76x más rápido que LangGraph". Un benchmark independiente de AIMultiple pone a CrewAI en último lugar en la misma comparación, tres veces más lento que LangChain. Los dos números son reales. Miden cosas distintas, y la brecha entre lo que se mide y lo que los lectores infieren está haciendo casi todo el trabajo. Esto va de leer benchmarks de frameworks con escepticismo, usando el caso CrewAI como ejemplo trabajado.
Si aterrizaste en la página de GitHub de CrewAI en los últimos dieciocho meses, hay una afirmación que salta a la vista: "CrewAI demuestra ventajas significativas de rendimiento frente a LangGraph, ejecutándose 5,76x más rápido en ciertos casos como este ejemplo de tarea QA".
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.
No son la misma dimensión. Un framework puede dominar en una y perder en otra. La mayoría de gente lee "5,76x más rápido" y lo parsea intuitivamente como velocidad de ejecución, porque es lo que se querría decir en casi cualquier otro contexto. En frameworks, normalmente no lo es.
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.
CrewAI quedó último. No por poco. Su resumen: "CrewAI dibuja el perfil global más pesado". En una tarea de single-tool-call — el trabajo más simple posible — CrewAI usó aproximadamente el triple de tokens que LangChain y tardó el triple. LangGraph fue 2,2x más rápido que CrewAI en su benchmark de orquestación.
Misma familia de frameworks. Conclusión opuesta. ¿Qué pasó?
La reconciliación
Si sigues ambas afirmaciones con cuidado, encajan.
El 5,76x de CrewAI es real — para velocidad de desarrollo. Su framework es famoso por ser rápido para prototipar: agents basados en roles que describes en lenguaje natural, mínimo state-management, veinte líneas de Python para tener un crew corriendo. Varios reviewers independientes confirman el patrón: los prototipos de CrewAI salen con aproximadamente un 40 por ciento menos de código que sus equivalentes en LangGraph. Ir de la idea al prototipo funcional es genuinamente rápido.
El benchmark de AIMultiple también es real — para velocidad de ejecución. En cuanto ambos frameworks están corriendo, entra en escena el "overhead managerial" de CrewAI. La propia documentación reconoce un hueco de cinco segundos entre agent y tool, descrito como "tiempo de deliberación". Cada agent de CrewAI literalmente piensa antes de actuar, y ese pensar cuesta tanto tokens como segundos wall-clock. Para tareas simples es overhead puro. Para tareas complejas puede ayudar, porque la deliberación pilla errores que un framework más simple se comería. Pero en la línea base de single-tool-call, CrewAI pierde.
El 5,76x del README y el 2,2x de AIMultiple miden cosas distintas. Ninguno es falso. La confusión está íntegramente en cómo se presenta el primero.
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.
Se vuelve caro en la segunda fase. Un patrón que he visto confirmado en varios write-ups de practicantes: los equipos empiezan en CrewAI por la velocidad de prototipado, chocan con las restricciones de diseño opinadas de CrewAI alrededor del sexto mes, y reescriben partes significativas a LangGraph para producción. Las estimaciones del coste de reescritura van del 50 al 80 por ciento. Anecdótico, pero el patrón vuelve a salir.
No es una razón para evitar CrewAI. Es una razón para ser honesto sobre qué fase estás optimizando. Si tu proyecto va a vivir en fase prototipo un rato — o si estás enseñando conceptos multi-agente a engineers que necesitan ver resultados rápido — CrewAI es buena elección. Si sabes que vas hacia producción en escala, arrancar en LangGraph cuesta más al principio y ahorra la reescritura.
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.
Tras esas restricciones, su sistema multi-agente (Claude Opus 4 como orquestador, Claude Sonnet 4 como subagents) superó al Claude Opus 4 single-agent en un 90,2 por ciento en evaluaciones internas de research. Noventa por ciento. Eso es una ganancia mayor que la que te va a dar casi cualquier cambio de framework.
La lección que Anthropic sacó merece interiorizarse: qué framework eliges importa menos que si defines los guardrails. Un sistema CrewAI bien restringido gana a un sistema LangGraph sin restricciones. Un sistema LangGraph bien restringido escala más bajo carga de producción. El framework es un factor; la disciplina que le pones alrededor es otro. Los benchmarks miden el primero y callan sobre el segundo.
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.
El 5,76x de CrewAI es un artefacto útil porque falla las tres preguntas. No nombra la dimensión. No muestra el trade-off. No describe un failure mode. Es el arquetipo de claim de benchmark que te dice casi nada sonando definitivo.
Una vez has visto uno de estos claramente, los ves en todas partes. Esa es la habilidad que merece la pena construir.
