La primera decisión de cualquier proyecto de agentes es también la más cara de equivocar.
Elige un framework, construye durante tres meses, descubre que no puede expresar tu máquina de estados — y no estás cambiando una librería, estás reescribiendo el agente. Por eso los debates sobre la selección de frameworks de agentes nunca mueren en internet, y por eso existe esta guía: una comparación de la misma tarea y las mismas herramientas entre los cuatro frameworks que importan en 2026, más una respuesta honesta a la pregunta que ninguna documentación te va a dar — cuándo saltarse los frameworks por completo.
Mantendremos una cosa fija en todas las secciones: el framework es la capa de orquestación, no la capa de modelos. Los cuatro aceptan cualquier endpoint compatible con OpenAI, lo que significa que elegir modelo y elegir framework son decisiones separables. Esa separación es la columna vertebral de esta comparación.
Antes de elegir: selección vs construcción vs protocolo
En resumen: la selección de framework es una de tres decisiones distintas — y la mayoría de las guías de comparación las confunden.
- Construcción se trata de cómo funcionan los agentes internamente: loops de tool calling, memoria, patrones de orquestación. Tenemos una guía de arquitectura completa para esa capa, y sostiene — correctamente, creemos — que deberías entender el loop antes de adoptar un framework.
- Protocolo es cómo se comunican los agentes y las herramientas: function calling, MCP, A2A. Es una decisión completamente separada, cubierta en nuestra comparación de protocolos.
- Selección — este artículo — es qué framework, si acaso alguno, envuelve tu capa de construcción.
Un filtro más antes de que leas una sola sección de opciones: cuándo no necesitas un framework. Un solo loop de tool calling, un modelo, sin persistencia — eso son tal vez 50 líneas de Python con el SDK directamente, y nuestro quickstart muestra la llamada base. Todos los frameworks de abajo son una solución a problemas que aparecen después de que ese prototipo de 50 líneas deja de ser suficiente.
Opción 1: LangGraph — orquestación por grafos y ecosistema de producción
En resumen: LangGraph es la opción por defecto en producción para agentes complejos con estado — al costo de la curva de aprendizaje más pronunciada.
LangGraph modela los agentes como grafos: los nodos son pasos, las aristas son transiciones, y el grafo tiene estado real que persiste entre ejecuciones. Ese diseño compra tres cosas con las que los otros frameworks batallan: checkpointing (un agente que se cayó retoma donde se detuvo), interrupciones human-in-the-loop como primitiva de primera clase, y estado duradero para workflows de larga duración.
El rewrite de la 1.0 (finales de 2025) limpió la API de forma sustancial — las quejas de «LangChain está inflado» que dominaron 2023-2024 se refieren sobre todo a la pila de abstracciones anterior, no al núcleo de grafos. El ecosistema que lo rodea (tracing, deployment, utilidades de testing) es el más maduro de los cuatro; la documentación general de LangGraph es la referencia de autoridad de la superficie de API actual.
El lado del costo. La curva de aprendizaje es real: grafos, reducers, checkpointers, y la carga mental de «dónde vive mi estado» es un concepto que no tenías antes. Los equipos que adoptan LangGraph sin una necesidad concreta de gestión de estado pagan ese impuesto sin recibir nada a cambio.
La prueba de realidad multi-proveedor. LangGraph habla con cualquier endpoint compatible con OpenAI a través de la capa de modelos. Apúntalo a tu endpoint unificado de API y el grafo corre sobre el routing de modelos que configures — el routing personalizado puede enviar modelos baratos a nodos baratos y modelos de frontera a los críticos. El framework bloquea tu orquestación, no tus modelos.
Para quién es: equipos con workflows complejos, con estado y de larga duración; cualquiera que necesite checkpoint/resume; organizaciones que superarán las abstracciones más simples en menos de un año.
Opción 2: CrewAI — colaboración basada en roles, el arranque más rápido
En resumen: CrewAI es la forma más rápida de lanzar un prototipo multi-agente — y la forma más rápida de chocar con un techo en estado complejo.
La apuesta de CrewAI es que los sistemas de agentes son equipos: defines Agents con roles y objetivos, Tasks con descripciones, y un Crew que los orquesta. La abstracción es legible para los no expertos — un product manager puede revisar un archivo de definición de CrewAI y entenderlo. Es una ventaja real para equipos donde el diseño del agente no es puramente un artefacto de ingeniería.
El techo. El modelo de procesos de CrewAI (ejecución secuencial y jerárquica) cubre bien los workflows lineales y con ramificaciones ligeras. En el momento en que tu agente necesita loops condicionales, re-planificación dinámica o recuperación de estado detallada, estás peleando contra la abstracción en lugar de usarla. La guía honesta: prototipa en CrewAI y presupuesta una migración a LangGraph o hecha a mano si el workflow se vuelve realmente stateful.
El costo de configuración es correspondientemente bajo. Una definición de CrewAI se lee como un spec: agents con role, goal y backstory; tasks con salidas esperadas; un crew que las ejecuta secuencial o jerárquicamente. Puedes tener un sistema de tres agentes funcionando antes del almuerzo — que es exactamente por qué es la recomendación por defecto para equipos de producto validando una idea.
Para quién es: equipos que lanzan su primer sistema multi-agente, automatización estilo proceso de negocio, y cualquiera que optimice por el tiempo hasta tener el primer agente funcionando por encima del margen arquitectónico.
Opción 3: AutoGen — modo mantenimiento y qué hacer al respecto
En resumen: AutoGen está ahora en modo mantenimiento — inicia los proyectos nuevos del ecosistema Microsoft en Microsoft Agent Framework.
El rewrite v0.4 de AutoGen introdujo una arquitectura basada en actores con mensajes tipados y fue genuinamente influyente — los patrones de conversación multi-agente, la orquestación de group chat y el linaje de investigación que trajo están por todo el ecosistema actual de agentes. Si tienes un sistema AutoGen funcionando, sigue funcionando; el modelo de actores v0.4 no se echa a perder de la noche a la mañana.
Pero el estatus de 2026 es inequívoco: Microsoft consolidó su apuesta de agentes, AutoGen pasó a mantenimiento, y el sucesor es Microsoft Agent Framework (Python y .NET). El modo mantenimiento significa corrección de bugs y actualizaciones de seguridad, no capacidades nuevas.
La regla práctica: no inicies un proyecto nuevo en un framework cuyo vendor se ha movido públicamente a otra cosa. Si estás en la pila Microsoft, evalúa Agent Framework directamente; si no, el patrón de conversación multi-agente que inspiró está bien servido por las otras tres opciones de aquí.
Lo que AutoGen le enseñó al ecosistema. Antes de descartar el linaje por completo, vale la pena estudiar su legado. El modelo de conversación-como-cómputo — agentes intercambiando mensajes estructurados, el group chat como primitiva de orquestación — ahora es ubicuo en la industria. Si tu diseño requiere conversación multi-agente libre con control a nivel de mensaje, estás implementando una idea de AutoGen; Microsoft Agent Framework y LangGraph ambos llevan el concepto hacia adelante en sus propios idiomas, pero el modelo de actores v0.4 original sigue siendo un modelo mental limpio para sistemas de paso de mensajes.
Para quién es: equipos con inversiones existentes en AutoGen (quédate, planifica una ventana de migración), y nadie más que empiece desde cero.
Opción 4: OpenAI Agents SDK — primitivas ligeras oficiales
En resumen: el Agents SDK es el framework menos framework — tres primitivas, sin DSL — y es el mejor default para equipos del ecosistema OpenAI.
Agents, Handoffs, Guardrails. Esa es toda la superficie. Un Agent envuelve un modelo más herramientas; los Handoffs permiten que un agente delegue en otro; los Guardrails ejecutan validación de entrada y salida fuera del loop del modelo. No hay DSL de grafos, no hay archivo de definición de crew — son objetos de Python y funciones async, lo que significa que el código se lee como tu codebase, no como el de un framework.
El SDK se apoya en la Responses API (a su vez sucesora de Chat Completions para trabajo agentic), y 2026 ha sido un año ajetreado en el lado de la plataforma: mejoras nativas de modelo en el harness e integración más estrecha con las herramientas de agentes de OpenAI — consulta la documentación del OpenAI Agents SDK para el set de features actual. Para equipos ya comprometidos con los modelos de OpenAI, es el camino de producción de menor fricción disponible: mantenimiento oficial, defaults sensatos y ninguna dependencia de terceros en el núcleo de tu agente.
El tradeoff: las primitivas son deliberadamente pequeñas. Las máquinas de estado complejas todavía quieren un grafo; el diseño pesado de roles multi-agente todavía quiere algo con más estructura. Y la afinidad por defecto del SDK con los modelos de OpenAI es una funcionalidad hasta que deja de serlo — que es exactamente por qué importa la separación de la capa de modelos: los mismos objetos Agent pueden apuntar a un endpoint unificado compatible con OpenAI con el modelo que decida tu routing.
Para quién es: equipos del ecosistema OpenAI, desarrolladores orientados a producción que desconfían de los DSL, y cualquiera que quiera la menor superficie de framework posible.
La misma tarea, cuatro frameworks: un agente de producción
En resumen: los frameworks se diferencian menos en lo que pueden hacer que en lo que te facilitan — mídeles en dimensiones de producción, no en videos de demo.
Toma una sola tarea: un agente de soporte con acceso a herramientas (consulta de tickets, elegibilidad de reembolsos), memoria de la conversación, y un paso de aprobación humana para reembolsos por encima de un umbral. Aproximadamente 150-250 líneas por framework. Las diferencias estructurales:
| Dimensión | LangGraph | CrewAI | AutoGen | Agents SDK |
|---|---|---|---|---|
| Estado y persistencia | de primera clase (checkpointers) | ámbito de sesión | mensajes basados en actores | ámbito de sesión |
| Human-in-the-loop | primitivas de interrupción | nivel de tarea | nivel de conversación | solo guardrails |
| Debugging y tracing | ecosistema maduro | básico | básico | oficial + terceros |
| Recuperación de errores | resume desde checkpoint | reiniciar tarea | reproducir mensajes | retry wrapper |
| Portabilidad de modelos | endpoint compatible con OpenAI | igual | igual | igual (default a OpenAI) |
| Curva de aprendizaje | pronunciada | suave | moderada | suave |
La columna que decide tu proyecto: estado y recuperación. Si un job nocturno que se cayó debe retomar a mitad del grafo, LangGraph es el único framework donde eso es una funcionalidad diseñada. Si tu agente es request-response sin estado con herramientas, el Agents SDK hace el trabajo con una fracción de la maquinaria.
Dos cosas que la tabla no puede mostrar, y ambas importan más que las filas: la experiencia de debugging y la familiaridad del equipo. Todos los frameworks de aquí son debugeables; ninguno es fácil de debugear una vez que el agente hace trabajo real. Rastrea un run multi-paso fallido en LangGraph y recorres el grafo; en el Agents SDK lees un trace de primitivas. Ambos son utilizables. El eje de familiaridad del equipo es el que realmente decide: un framework que tu equipo ya conoce a medias le gana a uno técnicamente superior que nadie puede revisar. Esa es una decisión de contratación y entrenamiento disfrazada de decisión tecnológica.
Lock-in, con honestidad. Cada framework de aquí es un lock-in en la capa de orquestación — eso es lo que significa adoptar un framework. La mitigación no es «elige el que menos te ate», es mantener separada la capa de modelos: los cuatro apuntan a endpoints compatibles con OpenAI, así que cambiar de modelo — o de provider, cuando cambian los precios — es un cambio de configuración, no un rewrite. Ese es el patrón que nuestra guía de optimización en producción llama «modelos como configuración», y es el único lock-in que de verdad puedes evitar.
Matriz de decisión: tamaño del equipo × complejidad
En resumen: usa por defecto el framework más pequeño que exprese tu estado — y en caso de duda, ningún framework.
| Workflows simples | Workflows complejos con estado | |
|---|---|---|
| Solo / equipo pequeño | Agents SDK (o SDK puro) | LangGraph, solo si el estado es real |
| Equipo de producto | CrewAI (lo más rápido de lanzar) | LangGraph |
| Pila Microsoft | Microsoft Agent Framework | Microsoft Agent Framework |
Tres defaults, dicho sin rodeos:
- ¿Todavía sin framework? Empieza con el SDK puro y el patrón de cliente unificado — la mayoría de los prototipos no necesitan un framework, y los prototipos que no lo necesitan te enseñan lo que realmente necesitas.
- ¿Necesitas estado o resume? LangGraph. Nada más en esta comparación trata la persistencia como una funcionalidad central.
- ¿Comprometido con OpenAI y quieres producción con ceremonia mínima? Agents SDK. Es oficial, es pequeño y se aparta de tu camino.
Una advertencia para cerrar: la documentación de cada framework la escribe el vendor del framework, y la documentación de cada vendor asume que ya lo elegiste. La capa de protocolo y la capa de construcción que enlazamos arriba siguen siendo útiles sin importar en qué framework — o no-framework — aterrices.
Una prueba de evaluación de 30 minutos. Toma una tarea real de tu backlog y constrúyela dos veces: una con el SDK puro, otra con tu framework candidato principal. Compara cuatro cosas — líneas de código, cómo se comporta un run que se cae, cómo agregarías un paso de aprobación humana, y cómo cambiarías el modelo. Cuatro preguntas, una tarde. Si el framework no gana en al menos dos de ellas, no lo necesitas.
FAQ
¿Qué framework debería aprender en 2026?
Aprende primero el loop de tool calling puro — es de ~50 líneas y es el mismo loop dentro de cada framework. Después aprende LangGraph si tu trabajo involucra estado, o el OpenAI Agents SDK si estás en la pila de OpenAI. El orden de aprendizaje importa más que la elección del framework.
¿Un framework me va a generar lock-in?
Sí, en la capa de orquestación — y eso está bien. Lo que debes evitar es el lock-in de modelos: los cuatro frameworks aceptan endpoints compatibles con OpenAI, así que mantén la capa de modelos detrás de un endpoint unificado y los cambios de provider quedan a nivel de configuración, no de rewrite.
¿CrewAI puede manejar workloads de producción?
Sí, para workflows lineales y con ramificaciones ligeras — miles de equipos ejecutan orquestación estilo CrewAI en producción. En el momento en que necesites loops condicionales, re-planificación dinámica o recuperación con checkpoints, migra a LangGraph o a un grafo hecho a mano antes de que el workflow pelee contra ti.
¿Cuál es la diferencia entre un framework y MCP?
Responden preguntas distintas. MCP estandariza cómo los agentes hablan con herramientas y servidores; los frameworks estandarizan cómo orquestas agentes. Puedes usar servidores MCP desde cualquier framework — nuestra comparación de protocolos cubre dónde se superponen y dónde no.
¿AgentKit es lo mismo que el OpenAI Agents SDK?
No. El Agents SDK es la librería de Python y TypeScript para construir agentes con primitivas. AgentKit es el builder de agentes de nivel más alto de OpenAI, dirigido a equipos de producto que ensamblan agentes desde una UI. Si escribes código, empieza con el Agents SDK; si ensamblas desde un dashboard, AgentKit es el camino. Ambos comparten la Responses API por debajo, así que la capa de modelos sigue siendo compatible de cualquier manera.
¿Cómo evalúo un framework en una tarde?
Haz la prueba de las cuatro preguntas: construye una tarea del backlog con el SDK puro y luego con el framework candidato, y compara líneas de código, comportamiento ante caídas, cómo agregarías un paso de aprobación humana y cómo cambiarías de modelo. Un framework que gana en menos de dos de esas no está ganándose su abstracción — y la solución más barata es no adoptarlo.
¿Usar un framework hace más lento a mi agente?
El overhead de la abstracción es pequeño — un porcentaje de un dígito en la mayoría de los workloads — y normalmente queda eclipsado por la latencia del modelo de todos modos. Los frameworks no hacen lento a un agente; el routing de modelos mal hecho sí. Enruta modelos baratos a nodos baratos y el impuesto del framework se convierte en ruido.
¿Puedo usar dos frameworks en un mismo proyecto?
No los mezcles dentro de un mismo agente — heredas ambas abstracciones y la historia de debugging de ninguna. Usar frameworks distintos en proyectos distintos (o servicios distintos) está bien; un endpoint de modelos compartido mantiene los costos comparables entre ambos.
Resumen
Cuando se trata de frameworks de agentes de IA, LangGraph es dueño del estado complejo, CrewAI del lanzamiento rápido, el Agents SDK de la ceremonia mínima, y AutoGen es un legado en modo mantenimiento con el que no deberías empezar. Los frameworks se diferencian menos en capacidad que en lo que facilitan — así que elige el más pequeño que exprese tu estado, y mantén la capa de modelos detrás de un endpoint unificado para que la decisión de framework siga siendo una decisión de framework y nada más.
Elige un framework después de medir, no antes. Obtén tu TokSpan API key — tus primeros $5 en créditos son gratis — y ejecuta el mismo workload contra varios modelos; los números resuelven el debate que internet no puede.