Los cuatro paradigmas de orquestación de agentes de IA: cuál usar en cada caso

Durante décadas, la automatización empresarial se construyó sobre un principio simple: si ocurre A, haz B. Flujos predefinidos, reglas codificadas, transformaciones explícitas. Funcionaba bien cuando el mundo era predecible.

El problema es que el mundo real no lo es. Los usuarios no hablan en JSON. Los procesos cambian. Las excepciones son la norma.

De ahí salen cuatro paradigmas que responden a una única pregunta: ¿dónde reside la inteligencia?

Paradigma	Dónde reside la inteligencia
Automated workflow	En el código, escrito por el desarrollador
AI workflow	En el código + el LLM como herramienta puntual: parsear una entrada, clasificar un texto, redactar una respuesta
Agentic workflow	En el código (la estructura del flujo) + el LLM, que decide tools, orden y finalización dentro de las tareas que el desarrollador le delega
Agentic AI	En el LLM, que orquesta: actúa con sus propias tools o delega subtareas a agentes especializados

Ninguno es mejor que los demás. Cada uno es la respuesta correcta a un conjunto distinto de requisitos, y una organización madura los usa los cuatro a la vez, cada uno donde aporta.

El error caro no es elegir el paradigma «antiguo». Es usar agentic AI donde bastaba un AI workflow —y pagar coste, latencia e indeterminismo a cambio de nada—, o insistir en un automated workflow donde la variabilidad de la entrada vuelve el mantenimiento inviable.

Cada capa hereda la anterior

Esto es lo que casi nadie explica: no son alternativas excluyentes, son capas que se apilan. Cada una contiene todo lo de la anterior y añade algo.

┌─────────────────────────────────────────────────────────────────┐
│  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 parar              │  │
│  │                                                           │  │
│  │  ┌─────────────────────────────────────────────────────┐  │  │
│  │  │  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 lo que sea:                   │  │  │  │
│  │  │  │  · APIs REST / SOAP                           │  │  │  │
│  │  │  │  · Bases de datos                             │  │  │  │
│  │  │  │  · Colas y eventos                            │  │  │  │
│  │  │  │  · Tools MCP                                  │  │  │  │
│  │  │  │  · Conectores (ERP, CRM, almacenamiento…)     │  │  │  │
│  │  │  └───────────────────────────────────────────────┘  │  │  │
│  │  └─────────────────────────────────────────────────────┘  │  │
│  └───────────────────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────────────────┘

Una consecuencia práctica que conviene interiorizar: un servidor MCP es la implementación natural de un automated workflow. Encapsula lógica determinista —llamadas a API, consultas a base de datos, integración con sistemas externos— y la expone como herramientas estándar. Los paradigmas superiores lo consumen con distintos niveles de inteligencia encima.

Es decir: lo que ya tienes construido no se tira. Se expone.

1. Automated workflow

Proceso orquestado íntegramente por código. Sin ningún modelo de por medio. El desarrollador define cada paso, cada condición y cada transformación.

Cuándo es la respuesta correcta:

La entrada llega siempre estructurada: JSON, XML, un evento, un formulario
La lógica de negocio es estable
Hay auditoría o compliance estricto: cada paso debe ser trazable y reproducible
Hay volumen alto — miles o millones de ejecuciones donde el coste de LLM sería inasumible
Tolerancia cero a la variabilidad: la misma entrada debe producir siempre la misma salida
Necesitas exponer lógica existente como herramientas consumibles

Cuándo no: la entrada viene en lenguaje natural y varía de forma; la lógica cambia a menudo; las excepciones son tantas que el código se vuelve inmantenible.

A favor	En contra
Predecible y reproducible al 100 %	La entrada debe ser estructurada
Coste cero en tokens	No maneja lenguaje natural
Trazabilidad perfecta	Cada cambio de negocio implica tocar código
Sin latencia de modelo	Las excepciones no previstas revientan
Válido bajo cualquier regulación	Hay que conocer todos los casos posibles
Base reutilizable para los demás paradigmas

2. AI workflow

El LLM participa como una tarea más dentro del flujo. El código sigue controlando qué pasos se ejecutan, en qué orden y cómo se encadenan. El modelo aparece donde su capacidad aporta.

Dónde colocarlo es una decisión de diseño, no una restricción:

Posición	Uso típico
Al inicio	Parsear: lenguaje natural → datos estructurados
En medio	Clasificar, evaluar, detectar intención
Al final	Redactar, resumir, traducir
Como condición	Evaluar un texto para bifurcar el flujo

[1] Recibir entrada (puede ser lenguaje natural)
      │
[2] LLM — Tarea A: procesa la entrada → parámetros estructurados
      │
[3] Código: transformar, validar
[4] Llamar al sistema 1 (tool MCP, API, base de datos, conector…)
[5] Llamar al sistema 2…
      │
[6] LLM — Tarea B: recibe los resultados → genera salida legible
      │
     FIN

Los pasos, el orden y las condiciones: predefinidos en código.

Cuándo es la respuesta correcta: el flujo de negocio es conocido y fijo, pero la entrada puede venir en lenguaje natural, o la salida debe ser legible y contextualizada.

Cuándo no: el orden de los pasos varía según los resultados intermedios, o necesitas que el sistema decida qué herramientas usar en tiempo de ejecución.

A favor	En contra
Acepta entrada en lenguaje natural	Cada llamada añade latencia y coste
El modelo puede ir en cualquier paso	Cada tarea del modelo es un punto de indeterminismo
Muy auditable: la secuencia es predecible aunque la salida del modelo no lo sea	Exige diseño cuidadoso de los prompts
El código puede llamar a cualquier sistema	Si el proceso cambia, hay que tocar código

Este es, para la mayoría de casos de empresa, el punto óptimo: aprovechas la IA donde de verdad aporta y mantienes el proceso predecible.

3. Agentic workflow

El desarrollador define la estructura del flujo: qué tareas existen y en qué orden se encadenan. Unas las implementa en código; otras las delega al modelo, que dentro de esa tarea decide qué herramientas usar, en qué orden y cuándo ha terminado.

Hay una regla que sostiene todo el paradigma:

Cuando el modelo decide qué acción ejecutar, esa acción se ejecuta siempre a través de una herramienta predefinida por el desarrollador. El modelo nunca invoca sistemas externos directamente.

El reparto de responsabilidades queda así:

El desarrollador define	El modelo decide
Qué herramientas existen y están disponibles	A cuál acudir en este momento
Cómo se ejecuta cada camino	Si la tarea está completa o necesita otra vuelta
Cómo se acumula el estado entre iteraciones	Cómo interpretar los resultados intermedios
El freno de seguridad: máximo de iteraciones	Cómo redactar la respuesta final

Ese freno de seguridad no es opcional. Un bucle donde el modelo decide cuándo parar necesita un límite duro que no dependa de él.

Tres patrones habituales:

Routing — el modelo decide a qué camino enrutar; el código evalúa esa decisión y ejecuta la rama correspondiente, todas predefinidas
Orchestrator-worker — el modelo determina el plan; el flujo activa los workers según ese plan; un consolidador une los resultados
Evaluator-optimizer — un modelo genera, otro evalúa contra un criterio, y se repite hasta aprobar. Con límite de iteraciones

Cuándo es la respuesta correcta: el orden de los pasos varía según el contexto; no puedes predefinir la secuencia exacta, pero sí el conjunto de herramientas; el proceso evoluciona a menudo y prefieres ajustar instrucciones antes que reescribir código.

Cuándo no: el proceso está regulado y la secuencia debe ser idéntica siempre; el volumen es tan alto que el coste de varias llamadas por ejecución no sale.

A favor	En contra
Adaptable: el camino varía con el contexto	Varias llamadas al modelo: más coste y latencia
El desarrollador controla el espacio de acción	Más complejo que un AI workflow
Cambiar el proceso es cambiar instrucciones, no código	El resultado puede variar entre ejecuciones parecidas
Un solo agente: menos sobrecarga que agentic AI	Necesita salvaguardas en entornos regulados

4. Agentic AI

Un broker LLM recibe la petición, razona y decide en cada iteración:

Actuar directamente, con sus propias herramientas predefinidas
Delegar una subtarea a un agente especializado (leaf agent) mediante A2A
Combinar ambas cosas

Igual que antes, el broker no invoca sistemas externos directamente: toda acción directa pasa por una herramienta predefinida, y toda delegación va por A2A.

[1] Recibir entrada
      │
  ┌── BUCLE: hasta que el broker considera la tarea completa ──┐
  │                                                            │
  │   BROKER LLM razona:                                       │
  │     ¿Qué necesito ahora?                                   │
  │     ¿Tengo información suficiente para responder?          │
  │     ¿Debo reintentar algo que falló?                       │
  │     ¿Cómo combino resultados parciales?                    │
  │        │                                                   │
  │        ├── Acción directa ──→ tool MCP                     │
  │        ├── Delegación ──────→ A2A → leaf agent A           │
  │        └── Delegación ──────→ A2A → leaf agent B           │
  │        │                                                   │
  │   Observa resultados ──→ vuelve a razonar                  │
  └────────────────────────────────────────────────────────────┘
      │
[2] Genera respuesta consolidada → FIN

Los roles quedan repartidos así:

Rol	Qué es	Responsabilidad
Broker	Agente coordinador	Razona, actúa con sus tools o delega vía A2A
Leaf agent	Agente especializado	Resuelve un dominio concreto — por dentro es un AI workflow o un agentic workflow
Servidor MCP	Automated workflow	Expone las tools que broker y agentes invocan

Fíjate en el detalle: un leaf agent, por dentro, es uno de los paradigmas anteriores. Ahí se cierra el círculo de las capas.

Cuándo es la respuesta correcta: la tarea abarca varios dominios que justifican agentes especializados independientes; esos agentes necesitan evolucionar y desplegarse por separado; el sistema debe crecer añadiendo agentes sin tocar el broker.

Cuándo no: si un solo agente resuelve la tarea, un agentic workflow es suficiente y bastante más simple.

A favor	En contra
Punto único de entrada para tareas multidominio	Mayor complejidad operativa
Cada agente evoluciona y se despliega por separado	Latencia acumulada en cada salto A2A
Escala añadiendo agentes sin tocar el broker	Depurar es difícil sin observabilidad dedicada
Mejora con los modelos sin cambiar código	Coste mayor: tokens del broker más los de cada agente
Los agentes se reutilizan en otras redes	Injustificado 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 define la estructura; el LLM dirige las tareas delegadas	Broker LLM
Papel del LLM	Ninguno	Tarea en un paso fijo	Decide tools, orden y fin dentro de lo delegado	Razona, actúa o delega
Qué puede invocar el LLM	—	—	Solo tools predefinidas	Tools predefinidas + A2A
Secuencia	Fija	Fija	Estructura fija, dinámica dentro de cada tarea	Dinámica
Predecibilidad	Máxima	Alta	Media	Baja-media
Trazabilidad	Máxima	Alta	Media	Exige observabilidad dedicada
Coste de tokens	Ninguno	Bajo	Medio-alto	Alto
Latencia	Mínima	Baja	Media-alta	Alta
Evolucionar el proceso	Tocar código	Tocar código	Ajustar instrucciones	Ajustar instrucciones o añadir agentes

El árbol de decisión

¿La entrada es siempre estructurada y la lógica no 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, el coste de tokens es asumible y toleras
              más indeterminismo?
                │
                ├── NO ─────────────────────→  AGENTIC WORKFLOW
                │
                └── SÍ ─────────────────────→  AGENTIC AI

Léelo de arriba abajo y quédate en el primer paradigma que resuelva tu problema. Bajar más no te da nada: te cuesta.

Lo que de verdad importa

Tres ideas que me llevaría de todo esto.

La primera: el paradigma no se elige por lo moderno que suene, sino por la naturaleza del problema. Entrada estructurada y lógica estable no necesitan un modelo — meterlo solo añade coste y variabilidad.

La segunda: en cuanto un modelo decide, la frontera de lo que puede tocar es tuya. Las herramientas predefinidas no son una limitación técnica: son la diferencia entre un sistema gobernable y uno que no puedes auditar.

La tercera: todo esto se apoya en una capa que ya conoces. Los agentes llegan hasta donde llega tu integración. Sin datos accesibles y contratos claros, el agente conversa; con ellos resueltos, opera. De eso hablé en por qué la unidad de integración deja de ser el flujo y pasa a ser la tool.

Si quieres el vocabulario en corto, las definiciones de estos cuatro paradigmas —y de MCP, A2A, RAG o tool use— están en el glosario.

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.