LangGraph vs Google ADK vs CrewAI, 6 patrones de producción, diseño human-in-the-loop y las decisiones de arquitectura que importan a escala.
TL;DR
La orquestación coordina agentes, herramientas y estado para completar un proceso. La selección técnica debe validarse con pruebas de calidad, recuperación, permisos y costo en el caso concreto.
La orquestación multi-agente es la disciplina de ingeniería de hacer que múltiples agentes de IA trabajen juntos — comunicándose, compartiendo estado, delegando tareas y produciendo un resultado unificado en problemas complejos que ningún agente individual podría manejar solo.
Un solo agente es poderoso. Un equipo bien orquestado de agentes especializados es transformador. Un equipo mal orquestado es una pesadilla de debugging que cuesta más que hacerlo manualmente.
| Criterio | LangGraph | Google ADK | CrewAI |
|---|---|---|---|
| Estado y recuperación | Validar con el flujo y la versión elegidos | Validar con el flujo y la versión elegidos | Validar con el flujo y la versión elegidos |
| Aprobaciones humanas | Validar con el flujo y la versión elegidos | Validar con el flujo y la versión elegidos | Validar con el flujo y la versión elegidos |
| Trazabilidad | Validar con el flujo y la versión elegidos | Validar con el flujo y la versión elegidos | Validar con el flujo y la versión elegidos |
| Compatibilidad con modelos | Validar con el flujo y la versión elegidos | Validar con el flujo y la versión elegidos | Validar con el flujo y la versión elegidos |
| Costo operativo | Validar con el flujo y la versión elegidos | Validar con el flujo y la versión elegidos | Validar con el flujo y la versión elegidos |
| Mantenimiento | Validar con el flujo y la versión elegidos | Validar con el flujo y la versión elegidos | Validar con el flujo y la versión elegidos |
Validar antes de comprometer el alcance
Una demo no prueba por sí sola la confiabilidad operativa. Ensayá interrupciones, reintentos, salidas inválidas y permisos insuficientes antes de acordar la salida a producción.
Un agente supervisor central recibe la tarea, decide qué agente especialista llamar a continuación e integra los resultados. El supervisor continúa hasta que la tarea está completa.
✓ Use when
Usalo cuando tenés roles especializados claramente diferenciados y el supervisor puede decidir el routing basándose en el estado de la conversación.
✗ Avoid when
Evitalo cuando la estructura de la tarea es muy dinámica y el supervisor necesitaría planificar muchos pasos adelante — usá Plan-and-Execute en su lugar.
Un agente planificador crea un plan explícito paso a paso. Un ejecutor lleva a cabo cada paso. Un re-planificador puede revisar si un paso falla o produce resultados inesperados.
✓ Use when
Usalo para tareas que pueden descomponerse en pasos ordenados de antemano: auditorías de compliance, due diligence, reportes de investigación de mercado.
✗ Avoid when
Evitalo cuando cada paso cambia significativamente qué debe ser el siguiente paso — usá ReAct en su lugar.
Puntos de pausa explícitos en el grafo de flujo donde el sistema espera revisión humana antes de tomar acciones irreversibles. LangGraph soporta esto nativamente con interrupt_before.
✓ Use when
Requerido para cualquier agente que toque acciones irreversibles: enviar emails, modificar datos de producción, ejecutar pagos.
✗ Avoid when
Nunca omitir para acciones irreversibles, incluso en sistemas "internos".
Descompone una tarea en sub-tareas independientes, córrelas en paralelo en múltiples instancias de agentes y agrega los resultados. Reduce drásticamente el tiempo total de ejecución.
✓ Use when
Usalo para: analizar múltiples documentos simultáneamente, correr análisis competitivo de 5 empresas en paralelo, verificar compliance en múltiples jurisdicciones.
✗ Avoid when
Evitalo cuando las sub-tareas tienen fuertes dependencias entre sí — usá patrones secuenciales en su lugar.
Trimming y resumen proactivo del historial de mensajes para prevenir el desbordamiento de la ventana de contexto. Implementar antes de enviar a producción.
✓ Use when
Requerido para cualquier flujo de trabajo de agente de larga duración (20+ llamadas LLM). No opcional en producción.
✗ Avoid when
No esperes a que aparezcan errores de límite de contexto en producción antes de implementar esto.
Validar cada output de agente en el límite antes de pasarlo al siguiente agente. Previene las cascadas de alucinaciones — el modo de fallo más peligroso en sistemas multi-agente.
✓ Use when
Requerido en cada límite de handoff de agentes en sistemas multi-agente.
✗ Avoid when
Nunca asumas que los outputs de los agentes están bien formados. Siempre validal.
Los flujos de trabajo de larga duración acumulan mensajes hasta alcanzar el límite de la ventana de contexto. Implementá trimming y resumen explícito antes de enviar.
El Agente A produce un hecho alucinado. El Agente B lo usa como input y construye sobre él. El Agente C sintetiza una conclusión confiada, totalmente ficticia. Agregá agentes de verificación de hechos en los puntos de handoff críticos.
Un agente devuelve un resultado parcial, el supervisor no lo detecta y el flujo continúa con datos malos. Cada nodo debe devolver output estructurado con estado explícito de éxito/fallo.
El supervisor enruta al Agente A. El Agente A enruta de vuelta al supervisor. Repetir. Siempre establecé límites de max_iterations y construí detección de bucles en la lógica del supervisor.
Un flujo complejo dispara 47 llamadas LLM a $0.08 cada una. Una tarea = $3.76. A 1.000 tareas/día = $3.760/día. Implementá tracking de costo por tarea y alertas de presupuesto antes de ir a producción.
La orquestación multi-agente es el diseño y gestión de sistemas donde múltiples agentes de IA colaboran, se comunican y coordinan para completar tareas complejas. Una capa de orquestación enruta el trabajo entre agentes, gestiona el estado y la memoria, maneja errores y hace cumplir los requisitos de human-in-the-loop.
Usá LangGraph para sistemas de producción que requieren flujos de trabajo con estado, checkpoints human-in-the-loop y cualquier backend LLM. Usá Google ADK cuando estés en Google Cloud con Vertex AI. Usá CrewAI solo para prototipado.
Empezá con el mínimo posible. El error más común es la descomposición prematura. La cantidad se decide con pruebas del proceso.
Las partes más difíciles en orden: (1) Evaluación — diseñar casos de prueba que reflejen condiciones reales de producción; (2) Gestión de contexto; (3) Manejo de errores; (4) Integración human-in-the-loop; (5) Observabilidad — debuguear por qué un flujo multi-paso produjo un output incorrecto.
Seleccionamos herramientas según el proceso, sus integraciones y las pruebas de recuperación, trazabilidad y costo. La elección se acuerda durante el diagnóstico técnico.
Describí el proceso y sus integraciones. Revisamos el contexto antes de proponer arquitectura, alcance y cotización.
Empezar diagnóstico inicial →Recursos relacionados