Los cuatro paradigmas de orquestación de agentes de IA: cuál usar en cada caso
Durante décadas, la automatización empresarial se ha construido alrededor de una idea bastante sencilla:
si ocurre A, haz B.
Un flujo definido, unas reglas y unas transformaciones concretas. El desarrollador decide qué ocurre en cada momento y el sistema lo ejecuta.
Y funcionaba.
Funcionaba especialmente bien cuando los procesos eran predecibles.
El problema es que los procesos reales rara vez lo son.
Los usuarios no hablan en JSON. Las entradas llegan de formas distintas. Las reglas cambian. Aparecen excepciones que nadie había contemplado y, con el tiempo, aquel flujo que parecía sencillo empieza a llenarse de condiciones.
Ahí es donde entran los diferentes paradigmas de orquestación con IA.
Aunque se suelen presentar como tecnologías distintas, en realidad responden a una pregunta bastante más sencilla:
¿dónde está la inteligencia que decide qué hacer?
| Paradigma | Dónde reside la inteligencia |
|---|---|
| Automated workflow | En el código, definido por el desarrollador |
| AI workflow | En el código, utilizando el LLM para tareas concretas |
| Agentic workflow | En el código y en el LLM, que decide herramientas, orden y finalización dentro de las tareas que se le delegan |
| Agentic AI | En el LLM, que puede actuar con sus propias herramientas o delegar trabajo en otros agentes |
Ninguno es “el mejor”.
Cada uno resuelve un tipo de problema.
De hecho, una organización madura probablemente acabará utilizando los cuatro, dependiendo de lo que necesite hacer.
El error realmente caro no es utilizar un paradigma tradicional.
Es meter agentic AI donde bastaba con un AI workflow, pagando más tokens, más latencia y aceptando más indeterminismo sin obtener nada a cambio.
O hacer lo contrario: intentar resolver con un flujo completamente automatizado un proceso cuya variabilidad hace que mantener el código sea cada vez más difícil.
Cada capa se apoya en la anterior
Hay una idea que creo que merece la pena tener clara desde el principio:
no son cuatro alternativas completamente separadas. Son capas.
Cada paradigma incorpora lo que ya hacía el anterior y añade un nivel más de autonomía.
┌───────────────────────────────────────────────────────────────────┐
│ AGENTIC AI │
│ Un broker LLM decide: actúa con sus tools o delega vía A2A │
│ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ AGENTIC WORKFLOW │ │
│ │ El LLM decide qué tools usar y cuándo terminar │ │
│ │ │ │
│ │ ┌───────────────────────────────────────────────────────┐ │ │
│ │ │ AI WORKFLOW │ │ │
│ │ │ El código decide los pasos; el LLM resuelve │ │ │
│ │ │ tareas concretas dentro de ellos │ │ │
│ │ │ │ │ │
│ │ │ ┌─────────────────────────────────────────────────┐ │ │ │
│ │ │ │ AUTOMATED WORKFLOW │ │ │ │
│ │ │ │ El código decide todo. Sin LLM. │ │ │ │
│ │ │ │ │ │ │ │
│ │ │ │ Puede llamar a APIs, bases de datos, │ │ │ │
│ │ │ │ colas, tools MCP, conectores... │ │ │ │
│ │ │ └─────────────────────────────────────────────────┘ │ │ │
│ │ └───────────────────────────────────────────────────────┘ │ │
│ └─────────────────────────────────────────────────────────────┘ │
└───────────────────────────────────────────────────────────────────┘Esto tiene una consecuencia práctica importante:
lo que ya tienes construido no tienes por qué tirarlo.
Un servidor MCP puede ser precisamente la forma de encapsular esa lógica determinista que ya existe —llamadas a APIs, consultas a bases de datos, integraciones con sistemas externos— y exponerla como herramientas que los paradigmas superiores pueden utilizar.
No sustituyes necesariamente lo anterior.
Lo expones.
1. Automated workflow
Aquí no hay ningún modelo tomando decisiones.
El proceso está completamente definido por código. El desarrollador decide cada paso, cada condición y cada transformación.
Es el enfoque clásico de automatización.
Y sigue siendo el adecuado para muchísimas cosas.
Cuándo utilizarlo
Tiene mucho sentido cuando:
- La entrada está siempre estructurada: JSON, XML, eventos, formularios…
- La lógica de negocio es estable.
- Necesitas una trazabilidad completa, por ejemplo por requisitos de auditoría o compliance.
- Hay muchísimo volumen y utilizar un LLM en cada ejecución sería demasiado caro.
- La misma entrada tiene que producir siempre el mismo resultado.
- Necesitas exponer lógica existente como herramientas que otros sistemas puedan consumir.
¿Y cuándo empieza a quedarse corto?
Cuando la entrada llega en lenguaje natural, cambia constantemente o las excepciones empiezan a ser tantas que mantener todas las posibilidades en código deja de ser razonable.
| A favor | En contra |
|---|---|
| Predecible y reproducible | Necesita entradas estructuradas |
| Sin coste de tokens | No entiende lenguaje natural |
| Trazabilidad completa | Los cambios de negocio requieren modificar código |
| Sin latencia de modelo | Las excepciones no previstas pueden romper el flujo |
| Adecuado para entornos regulados | Hay que conocer previamente los casos posibles |
| Base reutilizable para los demás paradigmas | — |
No hay nada “antiguo” en este paradigma.
Si el problema es determinista, probablemente sea la mejor solución.
2. AI workflow
Aquí aparece el LLM, pero sigue sin ser quien controla el proceso.
El código continúa decidiendo qué pasos se ejecutan, en qué orden y cómo se conectan.
El modelo simplemente se utiliza allí donde aporta algo.
Puede estar al principio, en medio o al final.
| Posición | Uso habitual |
|---|---|
| Al inicio | Convertir lenguaje natural en datos estructurados |
| En medio | Clasificar, evaluar o detectar intención |
| Al final | Redactar, resumir o traducir |
| Como condición | Analizar un texto y decidir por qué rama continúa el flujo |
Por ejemplo:
[1] Recibir entrada
│
│ puede ser lenguaje natural
▼
[2] LLM — procesa la entrada
│
│ → parámetros estructurados
▼
[3] Código — transforma y valida
│
[4] Llamar al sistema 1
│
[5] Llamar al sistema 2
│
▼
[6] LLM — recibe los resultados
│
│ → genera una respuesta legible
▼
FINEl flujo sigue estando definido de antemano.
Lo único que cambia es que algunas tareas concretas las resuelve el modelo.
Este suele ser, en muchos casos empresariales, el punto de equilibrio más interesante.
Puedes utilizar IA donde realmente aporta valor sin renunciar a que el proceso sea predecible.
Cuándo utilizarlo
Es una buena opción cuando conoces el flujo de negocio y sabes qué pasos tienen que ocurrir, pero:
- La entrada puede llegar en lenguaje natural.
- Necesitas interpretar información no estructurada.
- La salida tiene que estar redactada de forma contextual.
- Necesitas clasificar o evaluar información durante el proceso.
Empieza a quedarse corto cuando el propio orden de los pasos depende de los resultados intermedios y necesitas que el sistema decida qué herramienta utilizar en cada momento.
| A favor | En contra |
|---|---|
| Acepta lenguaje natural | Cada llamada añade coste y latencia |
| Puedes utilizar el LLM donde quieras | Cada tarea con LLM introduce cierta variabilidad |
| La secuencia general es predecible | Requiere diseñar bien las instrucciones |
| El código puede acceder a cualquier sistema | Los cambios de proceso siguen requiriendo código |
3. Agentic workflow
Aquí damos un paso más.
El desarrollador sigue definiendo la estructura general del flujo: qué tareas existen y cómo se relacionan.
Pero algunas de esas tareas se delegan al modelo.
Dentro de ellas, el LLM puede decidir qué herramientas utilizar, en qué orden y cuándo considera que ha terminado.
Hay una regla importante que no conviene perder de vista:
cuando el modelo decide ejecutar una acción, esa acción pasa siempre por una herramienta que el desarrollador ha definido previamente.
El modelo no debería poder conectarse directamente a cualquier sistema externo.
La frontera de acción la seguimos poniendo nosotros.
El reparto queda más o menos así:
| El desarrollador define | El modelo decide |
|---|---|
| Qué herramientas existen | Qué herramienta utilizar |
| Qué puede hacer cada herramienta | En qué orden utilizarlas |
| La estructura general del proceso | Si necesita otra iteración |
| Cómo se ejecuta cada camino | Cómo interpretar resultados intermedios |
| Cómo se mantiene el estado | Cuándo considera terminada la tarea |
| El límite máximo de iteraciones | Cómo construir la respuesta final |
Ese último punto merece atención.
Si tienes un bucle en el que el modelo decide cuándo ha terminado, necesitas un límite duro de iteraciones.
No puedes dejar que el propio modelo sea el único responsable de decidir cuándo parar.
Tres patrones bastante habituales
Routing
El modelo decide qué camino parece adecuado. El código comprueba esa decisión y ejecuta una rama que ya estaba definida.
Orchestrator-worker
El modelo determina un plan y el flujo activa diferentes workers para ejecutarlo. Después, otro componente reúne los resultados.
Evaluator-optimizer
Un modelo genera un resultado, otro lo evalúa contra un criterio y el proceso puede repetirse hasta conseguir un resultado aceptable.
Siempre con un límite.
Cuándo tiene sentido
Este paradigma encaja bien cuando:
- El orden de algunos pasos depende del contexto.
- No puedes definir de antemano una secuencia exacta.
- Sí puedes definir las herramientas disponibles.
- El proceso cambia con cierta frecuencia y prefieres ajustar instrucciones antes que modificar continuamente el código.
No es tan buena idea cuando la secuencia debe ser idéntica por requisitos regulatorios o cuando el volumen hace que varias llamadas al modelo por ejecución sean demasiado caras.
| A favor | En contra |
|---|---|
| Se adapta al contexto | Más llamadas al modelo |
| El desarrollador controla el espacio de acción | Mayor coste y latencia |
| Cambiar instrucciones puede ser suficiente para adaptar el proceso | El resultado puede variar |
| Un único agente simplifica frente a una arquitectura multiagente | Necesita salvaguardas |
| Permite resolver procesos menos previsibles | Más difícil de depurar |
4. Agentic AI
Aquí el cambio es más grande.
Tenemos un broker LLM que recibe una petición y decide qué hacer en cada iteración.
Puede actuar directamente utilizando sus herramientas.
Puede delegar una tarea a otro agente especializado mediante A2A.
O puede combinar las dos cosas.
La idea importante es que el broker sigue teniendo una frontera clara: las acciones directas pasan por herramientas predefinidas y las delegaciones se hacen mediante A2A.
El modelo no obtiene acceso directo e ilimitado a los sistemas de la empresa.
[1] Recibir entrada
│
▼
┌─────────────────────────────────────────────────────────────┐
│ BUCLE DEL BROKER │
│ │
│ El broker razona: │
│ ¿Qué necesito ahora? │
│ ¿Tengo suficiente información? │
│ ¿Tengo que reintentar algo? │
│ ¿Cómo combino los resultados? │
│ │
│ ├── Acción directa ──→ tool MCP │
│ ├── Delegación ──────→ A2A → agente especializado A │
│ └── Delegación ──────→ A2A → agente especializado B │
│ │
│ ↓ │
│ Observa resultados │
│ ↓ │
│ Vuelve a razonar │
└─────────────────────────────────────────────────────────────┘
│
▼
[2] Generar respuesta consolidadaLos roles se pueden entender así:
| Rol | Qué es | Responsabilidad |
|---|---|---|
| Broker | Agente coordinador | Razona, actúa con sus herramientas o delega mediante A2A |
| Leaf agent | Agente especializado | Resuelve un dominio concreto |
| Servidor MCP | Automated workflow | Expone las herramientas que utilizan el broker y los agentes |
Y aquí aparece otra vez la idea de las capas.
Un leaf agent no es una cosa completamente distinta.
Por dentro puede ser un AI workflow o un agentic workflow.
Cuándo tiene sentido
Agentic AI empieza a tener sentido cuando la tarea realmente abarca varios dominios y tiene valor disponer de agentes especializados que puedan evolucionar y desplegarse de manera independiente.
También cuando quieres poder añadir nuevos agentes sin tener que rehacer el coordinador.
Pero si un solo agente puede resolver el problema, montar una arquitectura multiagente probablemente sea complicarlo innecesariamente.
| A favor | En contra |
|---|---|
| Entrada única para tareas multidominio | Mayor complejidad operativa |
| Cada agente puede evolucionar por separado | Latencia adicional por los saltos A2A |
| Puedes escalar añadiendo agentes | La observabilidad se vuelve más importante |
| Los modelos pueden mejorar sin cambiar necesariamente el código | Mayor coste de tokens |
| Los agentes pueden reutilizarse en otros contextos | No aporta mucho si un único agente basta |
La comparativa, de un vistazo
| Criterio | Automated | AI workflow | Agentic workflow | Agentic AI |
|---|---|---|---|---|
| Quién orquesta | Código | Código | Código + LLM | Broker LLM |
| Papel del LLM | Ninguno | Tarea concreta | Decide tools, orden y fin dentro de lo delegado | Razona, actúa o delega |
| Qué puede invocar | — | — | Tools predefinidas | Tools + A2A |
| Secuencia | Fija | Fija | Parcialmente dinámica | Dinámica |
| Predecibilidad | Máxima | Alta | Media | Baja-media |
| Trazabilidad | Máxima | Alta | Media | Necesita observabilidad específica |
| Coste de tokens | Ninguno | Bajo | Medio-alto | Alto |
| Latencia | Mínima | Baja | Media-alta | Alta |
| Cambiar el proceso | Modificar código | Modificar código | Ajustar instrucciones | Ajustar instrucciones o añadir agentes |
El árbol de decisión
Una forma bastante sencilla de elegir es empezar por el problema más simple y bajar solo cuando realmente lo necesites.
¿La entrada es siempre estructurada
y la lógica apenas cambia?
│
├── SÍ ───────────────→ AUTOMATED WORKFLOW
│
└── NO
│
▼
¿Sabes exactamente qué pasos ejecutar
y en qué orden?
│
├── SÍ ───────────────→ AI WORKFLOW
│
└── NO
│
▼
¿La complejidad supera lo que puedes modelar
en un flujo y aceptas más coste e indeterminismo?
│
├── NO ───────────────→ AGENTIC WORKFLOW
│
└── SÍ ───────────────→ AGENTIC AIHay una regla que me parece especialmente útil:
quédate con el primer paradigma que resuelva tu problema.
No necesitas bajar un nivel más solo porque puedas hacerlo.
Más autonomía también significa más coste, más latencia, más complejidad y más cosas que observar.
Lo que realmente importa
De todo esto me quedaría con tres ideas.
La primera: no elijas el paradigma porque uno suene más moderno que otro.
Elige según el problema.
Si tienes una entrada estructurada y una lógica estable, probablemente no necesitas un LLM. Añadirlo solo porque estamos hablando de IA no mejora necesariamente nada.
La segunda: cuando un modelo empieza a decidir, la frontera de lo que puede tocar la decides tú.
Las herramientas predefinidas no son una limitación de la arquitectura.
Son precisamente lo que permite gobernarla.
Si el modelo puede decidir qué hacer, pero solo puede hacerlo utilizando un conjunto de herramientas que tú has definido, todavía puedes controlar y auditar su espacio de acción.
La tercera: todo esto sigue dependiendo de una capa que ya conocemos: la integración.
Los agentes llegan hasta donde llegan tus sistemas.
Si los datos no están accesibles, las capacidades no están claras y las integraciones son frágiles, el agente puede conversar todo lo que quieras, pero tendrá poco que hacer.
Cuando esa parte está resuelta, empieza a operar.
De eso hablaba en por qué la unidad de integración deja de ser el flujo y pasa a ser la tool.
Si quieres tener el vocabulario básico a mano, las definiciones de estos cuatro paradigmas —junto con MCP, A2A, RAG o tool use— están en el glosario.
Al final, la pregunta no es si deberías utilizar agentes.
Es cuánto necesitas que decida el sistema por sí mismo.
Y cuanto más sencilla sea la respuesta, mejor.
Escrito por José Miguel Azcona Padín · Málaga · más artículos
Las opiniones expresadas en este artículo son personales del autor y no representan la posición de ningún empleador, actual o anterior. El contenido es de elaboración propia y no incluye información confidencial de empresas ni de clientes.