Si vienes siguiendo el espacio de agentes multi-agente, sabes que la discusión de los últimos meses pasó de 'cómo hago que un agente llame a una herramienta' a 'cómo hago que varios agentes colaboren sin pisarse entre ellos y sin perder contexto'. Esta actualización de CrewAI responde justo a esa segunda pregunta.
CrewAI liberó la versión 1.15.26 el 8 de octubre y trajo algo que medio Twitter de IA llevaba meses pidiendo: memoria con backends plegables. Antes, si querías que tus agentes recordaran algo entre tareas, estabas casi obligado a usar el almacenamiento por defecto de CrewAI (SQLite local, sin opción real de cambiarlo). Ahora puedes elegir, y esa elección cambia bastante qué tan lejos puedes llevar un proyecto.
Qué cambió realmente
Desde la versión 1.14.7, CrewAI separó la memoria, el conocimiento (knowledge) y el RAG en sistemas plegables, es decir, intercambiables sin reescribir la lógica de tus agentes. La 1.15 sumó un backend de Qdrant Edge, vectores que corren localmente sin depender de un servidor externo, y soporte para Snowflake Cortex si tus datos de negocio ya viven ahí. Y desde la 1.15.22, los agentes corren de forma nativa sobre Gemini 3.8 Flash, sin el wrapper manual que había que armar antes para conectar ese modelo.
Por qué esto te importa si recién estás empezando
Vas a escuchar que 'la memoria plegable es para producción, no para tu primer proyecto'. Es cierto a medias. Si estás aprendiendo, el backend por defecto te alcanza de sobra, no te compliques el primer día configurando Qdrant ni un data warehouse. Pero entender que esa capa existe, y que puedes cambiarla después sin tirar el proyecto a la basura, es justo la diferencia entre un tutorial que armaste una tarde y un sistema que sigue corriendo en seis meses, cuando el volumen de datos y usuarios ya no es el mismo.
- ▸SQLite (por defecto): perfecto para prototipos y para aprender, cero configuración.
- ▸Qdrant Edge: vectores locales, útil cuando no quieres depender de un servicio externo ni pagar por él.
- ▸pgvector: si tu empresa ya tiene Postgres corriendo, reusas infraestructura que ya pagas en vez de sumar otra pieza.
- ▸Snowflake Cortex: cuando tus datos de negocio ya viven en el data warehouse y no quieres duplicarlos en otro sistema.
Lo que nadie te advierte: cambiar de backend a mitad de proyecto significa reindexar toda la memoria acumulada. No es gratis ni en tiempo ni en cómputo. Elige pensando en dónde va a estar tu proyecto en 6 meses, no en lo que es más fácil de instalar hoy.
Hay un matiz que vale la pena aclarar porque genera confusión: memoria, knowledge y RAG no son lo mismo en CrewAI, aunque en la práctica se mezclen. La memoria guarda lo que pasó en conversaciones anteriores (el historial de interacciones). El knowledge es información estática que le das al agente de entrada, como un manual o una política interna. El RAG es la búsqueda dinámica sobre una base de documentos grande, demasiado grande para meterla entera en el prompt. Antes de la versión 1.14, los tres vivían mezclados en una sola capa difícil de configurar por separado. Ahora cada uno tiene su propio backend intercambiable, lo que en la práctica significa que puedes usar pgvector para el RAG y dejar la memoria conversacional en SQLite, por ejemplo, sin que un cambio obligue al otro.
Cómo armas tu primer agente con CrewAI hoy
El flujo no cambió en lo esencial: instalas con pip install crewai, defines uno o más Agent (con un rol, un objetivo y las herramientas que puede usar), defines las Task que tienen que resolver, y los agrupas en un Crew que coordina el orden en que trabajan. Lo nuevo es que, al configurar la memoria, ahora declaras explícitamente qué backend quieres usar; antes era una decisión invisible que CrewAI tomaba por ti.
Un ejemplo que puedes replicar hoy
Piensa en un crew de soporte al cliente con tres agentes: uno de triage que lee el ticket y decide la urgencia, uno de investigación que busca en tu base de conocimiento usando RAG sobre pgvector (si ya corres Postgres), y uno redactor que arma la respuesta en el tono de tu marca. Antes de enviar algo a un cliente real, agregas un paso de aprobación humana para los casos de mayor riesgo, el mismo patrón que usa DXC en el caso de agentes para operaciones de TI que cubrí hace poco. Con memoria plegable, el agente de investigación recuerda qué ya buscó en tickets anteriores del mismo cliente, en vez de arrancar de cero cada vez.
Cómo sabes si el crew que armaste funciona bien
Esta es la parte que la mayoría de tutoriales se saltan. CrewAI tiene un comando, crewai eval, que ahora puede evaluar corridas con trazas completas a través de AMP (su plataforma de monitoreo), no solo revisar si el resultado final 'se ve bien'. La diferencia importa: un agente puede llegar a la respuesta correcta por el camino equivocado (usando una herramienta que no debía, o ignorando una fuente que sí debía consultar), y si solo miras el resultado final, ese problema queda invisible hasta que falla en un caso distinto. Antes de llevar cualquier crew a producción, vale la pena correr al menos 20 o 30 casos de prueba representativos y revisar no solo si acertó, sino cómo llegó ahí.
CrewAI vs LangGraph: la pregunta que siempre llega
CrewAI te hace pensar en 'quién hace qué': roles y colaboración entre agentes desde el primer día. LangGraph te da control fino de cada rama de decisión, mejor cuando necesitas que el camino sea predecible paso a paso. No son excluyentes: muchos equipos prototipan rápido en CrewAI y migran la lógica crítica a LangGraph cuando el sistema crece y el riesgo de un error sube. Si tu meta es dominar ambos frameworks y el resto del stack de quien diseña sistemas de agentes (RAG, memoria, harness engineering, despliegue), ese es el perfil completo que cubre la ruta de AI Agentic Engineer.
Si quieres practicar esto con otros que están armando lo mismo, cada semana hacemos un taller en vivo en la Comunidad AI Builders, un buen punto intermedio antes de meterte a un bootcamp completo.
Un error común al migrar de prototipo a producción
El error que más veo: alguien arma un crew que funciona perfecto en su laptop con 10 documentos de prueba, y lo lanza directo a producción con 50,000 documentos reales sin cambiar nada de la configuración de memoria. El SQLite por defecto, que andaba perfecto en el prototipo, se vuelve el cuello de botella del sistema completo. No es un error de CrewAI, es un error de no planear la migración de backend como parte del proyecto desde el día uno, aunque no la ejecutes hasta que el volumen lo justifique. Mi recomendación concreta: define desde el inicio qué backend usarás en producción, aunque desarrolles con SQLite, para no descubrir el límite el día que el crew ya está sirviendo a usuarios reales.
Para seguir
Arranca con el curso de Sistemas Multi-Agentes con CrewAI, compara con LangChain si todavía no sabes cuál te conviene, o revisa el resto de cursos de IA.
