El problema con los primeros sistemas multi-agente que construí con CrewAI era siempre el mismo: funcionaban bien en el prototipo, pero cuando querías añadir lógica condicional — "si este agente devuelve un resultado vacío, reintenta con otra fuente" — tenías que hacerlo fuera del framework. Con código suelto que vivía afuera del Crew y que nadie entendía tres semanas después. Flows llegó para resolver exactamente eso.
La versión corta: Flows es una clase Python que orquesta múltiples Crews con estado compartido, control de flujo condicional y event-driven execution. La versión larga está en el resto de este post.
Qué cambió entre el CrewAI antiguo y Flows
En las versiones previas a 0.70, un Crew era una lista de tareas que los agentes ejecutaban en secuencia o en paralelo. Simple y suficiente para casos de uso directos. El límite aparecía cuando necesitabas coordinar múltiples crews entre sí: no había una manera nativa de pasarles estado, ni de decir "si el primer crew no encontró suficientes datos, no corras el segundo".
Flows introduce una clase Flow en Python con decoradores que definen el orden y las condiciones de ejecución. El estado se comparte entre todos los pasos usando un modelo Pydantic, lo que significa que cada crew tiene acceso a los datos del anterior sin que tengas que pasarlos manualmente como strings entre funciones.
El patrón básico se ve así: defines un estado con Pydantic (por ejemplo, ResearchState con campos topic, raw_data y analysis), luego creas una clase ResearchFlow que hereda de Flow[ResearchState]. El primer método lleva el decorador @start() — es el punto de entrada. Los siguientes llevan @listen(nombre_del_metodo_anterior) y solo corren cuando el anterior termina. Si necesitas lógica condicional, @router() devuelve un string que decide qué rama sigue.
Lo que eso habilita: el segundo crew solo corre si el primero encontró suficientes datos. Sin Flows, esa validación vivía fuera del framework y era fácil olvidarla — o peor, saltársela.
Los tres decoradores que más uso en producción
- ▸@start() — marca el punto de entrada del flow. El primer método que corre. Solo puede haber uno.
- ▸@listen(metodo) — ese método corre cuando el método que le pasas termina. Se pueden encadenar varios métodos que escuchan al mismo evento.
- ▸@router() — devuelve un string que decide qué rama del flow sigue. Es el if/else del mundo multi-agente: según el resultado, el flow va por un camino u otro.
También existen @and_() y @or_() para coordinar múltiples eventos — útiles cuando necesitas esperar a que dos crews distintos terminen antes de continuar con el siguiente paso. Los uso menos, pero en pipelines de análisis paralelo son indispensables.
Tres casos de uso donde Flows marca la diferencia real
Reportes automáticos con condiciones: el flow corre cada noche, verifica si hay nuevos datos, los procesa solo si superan un volumen mínimo, y envía el reporte únicamente si el análisis encontró algo relevante. Sin Flows, ese manejo de condiciones era código custom fuera del framework que alguien tenía que mantener.
Pipelines de onboarding de clientes: el primer crew valida los datos, el segundo configura las integraciones, el tercero envía el email de bienvenida. Si el segundo falla, el router manda el flow a un crew de fallback que envía una alerta al equipo en vez de silenciar el error. Eso es un workflow de negocio real, no un prototipo.
Research con validación de fuentes: un crew busca información, otro valida la calidad de las fuentes, otro redacta el contenido. Si la validación falla — fuentes con menos de cierta autoridad — el router reinicia la búsqueda con criterios diferentes en vez de continuar con datos cuestionables. El costo de ese loop es un par de llamadas extra al LLM; el costo de no tenerlo es contenido malo en producción.
Lo que Flows no hace (y necesitas saber antes de empezar)
Flows no es un orquestador de infraestructura. No reemplaza Airflow, Prefect ni Dagster para pipelines de datos que procesan millones de registros. Si tu caso de uso es batch processing a gran escala, CrewAI Flows es el componente de lógica de agentes dentro de un pipeline mayor — no el pipeline en sí.
Tampoco tienes control granular sobre los LLMs que usa cada agente dentro del Flow desde el nivel del Flow. Si necesitas que un crew use GPT-4o y otro use Claude Sonnet por razones de costo, eso se configura a nivel de crew, no de flow. No es un problema — pero la documentación oficial no lo deja claro y genera confusión al principio.
Una cosa que aprendí de forma cara: define el modelo Pydantic de estado desde el día 1 con todos los campos que vas a necesitar. Si empiezas con un state simple y lo vas expandiendo a medida que el proyecto crece, refactorizar el estado a mitad del desarrollo es doloroso. Trátalo como tu contrato de datos entre crews.
Cómo aprenderlo y qué sigue
Si ya tienes experiencia con Python y con APIs de LLMs, CrewAI Flows se aprende en un día de práctica seria. Si estás empezando con agentes, primero entiende cómo funciona un Crew básico — roles, tareas, herramientas — y luego sube a Flows. Intentar aprender los dos al mismo tiempo es la forma más rápida de frustrarse.
En el curso de Sistemas Multi-Agentes con CrewAI vas desde un crew simple hasta sistemas con Flows conectados a herramientas reales. No es un tutorial de documentación — construyes proyectos que podrían vivir en producción. Y si quieres el panorama completo — LangGraph, MCP, orquestación avanzada — la ruta AI Agentic Engineer cubre los dos frameworks y te enseña cuándo elegir cada uno.
CrewAI Flows también se integra bien con LangGraph si necesitas grafos de estado más complejos. No tienes que elegir entre uno y otro — en la ruta AI Agentic Engineer trabajas los dos y aprendes en qué escenarios conviene cada enfoque.
Si prefieres ver esto en acción antes de comprometerte con un curso, la Comunidad AI Builders hace talleres en vivo cada semana donde construimos sistemas reales con CrewAI, LangGraph y otras herramientas del ecosistema. Desde 19 USD/mes — es el escalón intermedio entre leer la documentación y meterte a un bootcamp.
Flows no es la característica más publicitada de CrewAI, pero es la que separa los sistemas que van a producción de los que se quedan en demo. Si ya tienes un Crew funcionando y quieres llevar eso al siguiente nivel, este es el salto.
