Sistemas Multi-Agentes vs. Workflows de IA: Eligiendo la Arquitectura Correcta
Una guía práctica para ingenieros navegando el espectro entre workflows de IA determinísticos y sistemas multi-agentes autónomos.
En el artículo anterior, exploramos cuándo los sistemas multi-agentes tienen sentido y cuándo no. El argumento central fue simple: la complejidad debe estar justificada por el problema. La mayoría de las aplicaciones de LLM no necesitan múltiples agentes autónomos, y buscar esa arquitectura prematuramente crea pesadillas de debugging, modos de fallo multiplicados y latencia innecesaria. Empieza simple. Añade complejidad solo cuando los enfoques más simples alcancen límites concretos.
Pero hay una pregunta que el artículo anterior dejó abierta: incluso cuando has decidido que necesitas más que una única llamada de LLM, aún enfrentas una elección arquitectónica crítica. ¿Estás construyendo un sistema multi-agentes o un workflow de IA? La distinción importa más de lo que la mayoría de los ingenieros creen, y equivocarse lleva a una sobre-ingeniería frágil o a una capacidad frustrantemente insuficiente.
Este artículo profundiza en esa frontera.
Definiendo los Términos Claramente
Antes de navegar la elección, necesitamos definiciones compartidas. Estos términos se usan de forma imprecisa, así que seamos precisos.
Workflow de IA
Un workflow de IA es un pipeline estructurado donde las llamadas de LLM son pasos en una secuencia predefinida. El flujo de control es explícito e ingenierado. Tú, el desarrollador, decides qué sucede después. El LLM proporciona inteligencia en pasos específicos, pero la lógica de orquestación vive en tu código.
Los ejemplos incluyen pipelines de resumen que toman un documento, lo dividen en chunks, resumen cada chunk y combinan los resúmenes. Los pipelines RAG funcionan de manera similar: consulta, recuperar documentos, aumentar el prompt, generar respuesta. Las cadenas de clasificación-luego-acción clasifican la intención, enrutan al handler apropiado y ejecutan.
En los workflows, el LLM es una herramienta poderosa, pero no está tomando decisiones sobre qué hacer después. Tu código lo hace.
Sistema Multi-Agentes
Un sistema multi-agentes es una arquitectura dinámica donde agentes autónomos toman decisiones sobre el flujo de control, delegan tareas a otros agentes y operan con un grado de independencia. La orquestación emerge del comportamiento de los agentes, no de lógica hardcodeada.
Los agentes deciden qué herramientas llamar y cuándo. Pueden crear o delegar a otros agentes. El camino de ejecución no está completamente determinado en tiempo de diseño, y los agentes pueden iterar, reintentar o explorar basándose en resultados intermedios.
El LLM no solo está proporcionando inteligencia. Está controlando el proceso.
Los Factores Distintivos Clave
Tres preguntas separan los workflows de los sistemas multi-agentes:
-
¿Quién controla el flujo? En workflows, el ingeniero define el camino. En sistemas multi-agentes, los agentes deciden dinámicamente.
-
¿Cuál es el grado de autonomía? Los workflows ejecutan pasos predeterminados. Los agentes toman decisiones reales, incluyendo cuándo parar, reintentar o probar algo diferente.
-
¿Cómo maneja entradas inesperadas? Los workflows pueden fallar o producir salidas pobres en casos extremos. Los agentes pueden adaptarse, razonar sobre la situación y cambiar de estrategia.
La investigación de Anthropic lo expresa bien: los workflows son sistemas donde los LLMs siguen caminos de código predefinidos, mientras que los agentes son sistemas donde los LLMs controlan dinámicamente sus propios procesos [1].
El Espectro, No un Binario
Aquí está el cambio mental que ayuda: los workflows y los sistemas multi-agentes no son opuestos. Son dos extremos de un espectro, y la mayoría de los sistemas en producción viven en algún lugar intermedio.
Permíteme guiarte por cuatro puntos en ese espectro.
Nivel 1: Cadena Secuencial Simple
Entrada → Llamada LLM A → Llamada LLM B → Llamada LLM C → Salida
Esto es workflow puro. Cada paso está predeterminado. La salida de una llamada alimenta la siguiente. No hay toma de decisiones, solo un pipeline. Piensa en una cadena de traducción: detectar idioma, traducir al español, resumir.
Nivel de autonomía: Cero. El camino es fijo.
Nivel 2: Workflow con Ramificación y Enrutamiento
Entrada → LLM Clasificador → Enrutar a Handler A, B o C → Salida
Ahora un LLM toma una decisión, pero es una decisión restringida. El clasificador elige de un conjunto fijo de opciones, y cada rama es un workflow predeterminado. Los sistemas de atención al cliente frecuentemente funcionan así: clasificar la intención, luego enrutar al pipeline de respuesta apropiado.
Nivel de autonomía: Mínimo. Las decisiones son categóricas, no abiertas.
Nivel 3: Workflow con Pasos Controlados por Agente
Entrada → Paso del Workflow → Agente decide herramientas/acciones → Paso del Workflow → Salida
Aquí es donde se pone interesante. La estructura general sigue siendo un workflow con puntos de entrada definidos, checkpoints y salidas. Uno o más pasos involucran un agente que puede decidir cómo cumplir su subtarea. Un pipeline de investigación podría tener una estructura fija (recopilar fuentes, analizar, sintetizar), pero el paso de "recopilar fuentes" involucra un agente que decide qué herramientas usar y cuándo tiene suficiente información.
Nivel de autonomía: Moderado. Autonomía limitada dentro de fases definidas.
Nivel 4: Loop Multi-Agentes Completamente Autónomo
Agente Orquestador ↔ Agente Especialista A ↔ Agente Especialista B ↔ ...
En este extremo del espectro, los agentes se comunican dinámicamente, deciden cuándo involucrar a otros agentes y determinan cuándo la tarea está completa. El camino de ejecución es emergente. No puedes predecirlo completamente en tiempo de diseño. Un agente de codificación complejo que puede crear sub-agentes para investigación, testing y revisión de código opera a este nivel.
Nivel de autonomía: Alto. Comportamiento emergente de las interacciones entre agentes.
La mayoría de los sistemas exitosos que he visto operan en el Nivel 2 o 3. Obtienen los beneficios de confiabilidad de los workflows estructurados mientras permiten autonomía dirigida donde añade valor. Los sistemas puros de Nivel 4 son poderosos pero difíciles de debuggear e impredecibles en producción.
Comparación de Tradeoffs
Así es como los dos enfoques se comparan en las dimensiones que importan en producción:
| Dimensión | Workflow de IA | Sistema Multi-Agentes |
|---|---|---|
| Predictibilidad | Alta, la misma entrada produce un camino de ejecución consistente | Menor, los agentes pueden tomar caminos diferentes con entradas idénticas |
| Debuggeabilidad | Simple, recorre el pipeline paso a paso | Compleja, requiere rastrear decisiones de agentes y comunicación entre agentes |
| Latencia | Predecible, suma de los pasos del pipeline | Variable, depende de las decisiones de los agentes y posibles iteraciones |
| Costo | Predecible, número fijo de llamadas de LLM | Variable, los agentes pueden hacer muchas llamadas mientras exploran |
| Flexibilidad | Limitada, maneja casos que anticipaste | Alta, puede adaptarse a situaciones nuevas |
| Complejidad de ingeniería | Moderada, patrones de pipeline estándar | Alta, gestión de estado, paso de mensajes, coordinación |
| Modos de fallo | Contenidos, las fallas ocurren en pasos específicos | Pueden cascadear, los errores de agentes pueden acumularse |
| Mejores problemas | Tareas bien definidas con pasos claros | Tareas abiertas que requieren exploración y juicio |
La tabla revela el tradeoff fundamental: los workflows intercambian flexibilidad por predictibilidad; los sistemas multi-agentes intercambian predictibilidad por flexibilidad.
Ninguno es universalmente mejor. La pregunta es qué tradeoff requiere tu problema.
Cómo Decidir: Una Heurística Práctica
Este es el modelo mental que uso: Empieza con un workflow. Añade agencia solo donde el determinismo falla.
No se trata de evitar complejidad. Se trata de poner complejidad donde vale la pena. La agencia es cara: más difícil de testear, más difícil de debuggear, más difícil de razonar. Úsala quirúrgicamente.
Escenario 1: Pipeline de Procesamiento de Documentos
Necesitas procesar contratos legales: extraer términos clave, identificar obligaciones, señalar riesgos.
Empieza con un workflow. Define el esquema de extracción. Construye un pipeline: analizar documento, extraer cláusulas, clasificar cada cláusula, aplicar reglas de riesgo, generar informe. Cada paso es una llamada de LLM enfocada con un prompt específico.
¿Dónde podrías necesitar agencia? Si la estructura del documento varía mucho, con algunos contratos teniendo anexos anidados y otros con formato inusual, podrías necesitar un agente para decidir cómo dividir y analizar. Pero empieza determinístico, y añade agencia solo cuando encuentres casos que el workflow no puede manejar.
Escenario 2: Asistente de Investigación de Empresas
Un usuario pregunta: "Encuentra información sobre los lanzamientos de productos recientes de esta empresa y resume el posicionamiento competitivo."
Esto probablemente necesita algo de agencia. La tarea es inherentemente abierta. ¿Cuántas fuentes deberías revisar? ¿Cuándo tienes suficiente información? ¿Qué cuenta como "reciente"? Un workflow necesitaría anticipar cada camino, lo cual no es práctico.
Pero limita la agencia. Dale al agente de investigación autonomía para decidir qué fuentes consultar y cuándo parar, pero envuélvelo en un workflow: fase de investigación, fase de síntesis, fase de formateo. El agente opera dentro de la fase de investigación; la estructura general es determinística.
Escenario 3: Tarea de Generación de Código
Genera una nueva funcionalidad basada en una especificación.
Empieza con un workflow. Analizar la spec, generar código, ejecutar tests, reportar resultados. Esto maneja la mayoría de los casos bien.
¿Cuándo necesita agencia? Cuando los tests fallan y el sistema necesita auto-debuggearse. Un workflow puro solo reportaría la falla. Un agente puede analizar el error, hipotetizar correcciones e iterar. Eso es autonomía genuina, pero nota que es un camino de fallback, no el camino feliz.
El patrón: workflows para el camino esperado, agencia para los casos extremos que requieren adaptación.
Errores Comunes que Cometen los Ingenieros
Sobre-Ingeniería: Convertir Todo en Agente
He visto equipos construir sistemas multi-agentes para problemas que son fundamentalmente determinísticos. "Tenemos un agente de resumen, y habla con un agente de formateo, y hay un agente orquestador..." Pero el proceso es siempre el mismo: resumir, luego formatear. Eso no es un sistema multi-agentes. Es un pipeline de dos pasos con complejidad extra.
La señal: Si puedes dibujar un diagrama de flujo de exactamente lo que sucederá, no necesitas agentes. Necesitas un workflow.
Sub-Ingeniería: Forzar Rigidez en Problemas Adaptativos
El error opuesto: construir workflows condicionales elaborados para problemas que genuinamente requieren juicio. He visto sistemas con cientos de ramas if-else tratando de anticipar cada situación, cuando un agente con herramientas apropiadas manejaría la variabilidad naturalmente.
La señal: Si constantemente estás añadiendo casos especiales y tu workflow se está volviendo imposible de mantener, podrías necesitar la adaptabilidad que los agentes proporcionan.
Confundir Llamadas de Herramientas con Agencia Real
Este es sutil. Un LLM que llama herramientas no es necesariamente un agente. Si tu código dice "llama al LLM con estas herramientas disponibles, luego toma la salida de la herramienta y continúa al siguiente paso", eso sigue siendo un workflow. El LLM está decidiendo cómo cumplir un paso, pero la orquestación sigue siendo tuya.
La agencia real significa que el LLM decide qué hacer después, incluyendo si continuar, parar, delegar o probar un enfoque completamente diferente. El trabajo de Harrison Chase en LangGraph hace esta distinción clara: puedes tener workflows que usan herramientas y loops agénticos, y son arquitectónicamente diferentes [2].
La señal: Pregúntate quién decide cuándo la tarea está terminada. Si es tu código verificando una condición, eso es un workflow. Si el agente decide que ha logrado el objetivo, eso es agencia.
Hacia Dónde Va Esta Serie
Ya hemos cubierto cuándo usar sistemas multi-agentes y cómo pensar sobre el espectro entre workflows y agentes. Pero no hemos abordado cómo construir realmente estos sistemas de manera confiable.
El próximo artículo de esta serie abordará patrones de orquestación y comunicación entre agentes, la infraestructura práctica que hace funcionar los sistemas multi-agentes en producción. Veremos cómo los agentes pasan información, cómo implementar checkpoints y aprobación humana en el loop, y cómo construir la observabilidad que necesitas para debuggear estos sistemas cuando (no si) algo sale mal.
Construir sistemas multi-agentes es una cosa. Operarlos es otra.
Referencias
[1] E. Schluntz and B. Zhang, "Building Effective Agents," Anthropic, Dec. 2024. Disponible: https://www.anthropic.com/research/building-effective-agents
[2] H. Chase, "LangGraph: Building Controllable Agents," LangChain Blog, 2024. Disponible: https://blog.langchain.com/langgraph
[3] L. Weng, "LLM Powered Autonomous Agents," Lil'Log, Jun. 2023. Disponible: https://lilianweng.github.io/posts/2023-06-23-agent/
[4] A. Ng, "Agentic Design Patterns," DeepLearning.AI, 2024. Disponible: https://www.deeplearning.ai/the-batch/how-agents-can-improve-llm-performance/
[5] Q. Wu et al., "AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation," Microsoft Research, 2023. Disponible: https://arxiv.org/abs/2308.08155
[6] C. Huyen, "Building LLM Applications for Production," Chip Huyen Blog, 2023. Disponible: https://huyenchip.com/2023/04/11/llm-engineering.html