Flujos de trabajo agénticos: qué son, patrones y ejemplos

Un flujo de trabajo agéntico es un flujo de trabajo con IA cuyo recorrido general está fijado de antemano, pero en el que algunos pasos dejan decidir al modelo: a qué rama va un caso, en cuántas subtareas se divide una petición, qué herramienta se llama o si un borrador es lo bastante bueno para seguir adelante. Queda entre el flujo con IA convencional, en el que el modelo solo ejecuta pasos definidos, y el agente autónomo, que elige por sí mismo todo su planteamiento. Para la mayoría de los procesos de empresa es el punto medio sensato: flexibilidad suficiente para absorber casos variados y estructura suficiente para probar, prever el coste y mantener el control.

Flujo con IA, flujo agéntico y agente: dónde está la frontera

El vocabulario es impreciso, también entre proveedores. La propia Comisión Europea señala en sus preguntas frecuentes sobre agentes de IA que estos términos se usan a menudo de forma poco coherente. La prueba útil es sencilla: ¿quién decide el siguiente paso?

	Flujo con IA	Flujo agéntico	Agente autónomo
Recorrido	Fijado de principio a fin	Fijado en sus líneas generales	Elegido por el modelo
Decisiones del modelo	Ninguna sobre el recorrido	Concretas: derivar, dividir, evaluar	Todas
Número de llamadas al modelo	Conocido	Acotado	Variable
Pruebas	Paso a paso	Paso a paso, más los puntos de decisión	Escenarios completos
Encaja con	Procesos estables y repetitivos	Procesos estables con casos variados	Problemas abiertos

Anthropic, en su guía Building effective agents, usa «sistemas agénticos» como término general y distingue los flujos de trabajo, en los que modelos y herramientas se orquestan mediante rutas de código predefinidas, de los agentes, en los que el modelo dirige su propio proceso. Los patrones siguientes llevan los nombres de esa guía.

Los cinco patrones que conviene conocer

1. Encadenamiento de prompts

La tarea se divide en pasos sucesivos; cada llamada al modelo trabaja con el resultado de la anterior, con comprobaciones opcionales entre medias. Ejemplo: extraer las cláusulas de un contrato, compararlas con tus condiciones y redactar el resumen. Es el patrón menos agéntico y a menudo el más rentable; lo explicamos en el artículo sobre encadenamiento de prompts.

2. Enrutamiento

El modelo clasifica la petición entrante y la envía al tratamiento adecuado. Ejemplo: un correo de un cliente va a la rama «estado del pedido», «devolución» o «reclamación», cada una con su propio prompt y sus reglas. El enrutamiento también permite enviar las peticiones sencillas a un modelo más barato.

3. Paralelización

Varias llamadas se ejecutan a la vez y sus resultados se combinan. Dos variantes: dividir una tarea en partes independientes (analizar por separado cada capítulo de un informe) o resolver la misma pregunta varias veces para comparar las respuestas, por ejemplo en una comprobación de cumplimiento en la que cualquier duda debe activar una revisión humana.

4. Orquestador y trabajadores

Un modelo central analiza la petición, decide qué subtareas hacen falta, las reparte entre otras llamadas y compone el resultado. La diferencia con la paralelización: las subtareas no están previstas de antemano, dependen de la petición. Ejemplo: para responder a una licitación, el orquestador identifica los apartados exigidos y lanza una búsqueda por apartado en tu base documental.

5. Evaluador-optimizador

Una llamada genera un resultado, una segunda lo evalúa con criterios explícitos y devuelve observaciones, y el bucle se repite hasta que el resultado se acepta o se alcanza un límite. Ejemplo: una respuesta a un cliente se contrasta con la guía de tono y la política comercial antes de que la vea un empleado. Este patrón solo tiene sentido si los criterios están claros.

Patrón	Decisión que toma el modelo	Riesgo principal
Encadenamiento	Ninguna o casi ninguna	Un error que pasa de un paso al siguiente
Enrutamiento	La elección de la rama	Derivación equivocada
Paralelización	Ninguna, salvo en la votación	Coste multiplicado
Orquestador	La división en subtareas	Subtareas innecesarias u olvidadas
Evaluador-optimizador	Aceptar o rehacer	Bucle sin fin, coste imprevisible

Ejemplo: gestionar solicitudes de presupuesto

Una empresa de servicios de treinta personas recibe cada semana solicitudes de presupuesto por correo, de calidad muy desigual. Así queda el proceso como flujo agéntico:

1. Disparador. Llega un correo a la dirección habilitada.
2. Enrutamiento (decisión del modelo). El modelo clasifica: solicitud completa, solicitud incompleta u otro tema. «Otro tema» pasa a una persona y el flujo termina.
3. Extracción. En una solicitud de presupuesto, el modelo extrae la necesidad, los volúmenes, los plazos y el posible presupuesto en un formato fijo.
4. Comprobación por código. Si falta un campo obligatorio, la solicitud pasa a «incompleta»: el modelo redacta una petición de aclaración que una persona aprueba.
5. Orquestación (decisión del modelo). El modelo determina qué servicios del catálogo están implicados y lanza, para cada uno, una búsqueda de precios y condiciones en los documentos internos. Límite: cinco servicios como máximo, solo lectura.
6. Redacción. El modelo redacta el presupuesto únicamente con los datos extraídos y encontrados.
7. Evaluación (decisión del modelo). Una segunda llamada revisa el presupuesto con una checklist: ¿cada precio sale del catálogo?, ¿se citan las condiciones?, ¿cuadra el total? Dos rondas como máximo.
8. Aprobación humana. Un comercial revisa, corrige y envía. Nada sale sin esa revisión.

El recorrido es fijo: siempre sabes en qué paso está cada caso. El modelo decide solo en tres puntos, y cada uno está acotado por un límite o seguido de una comprobación. Eso es lo que hace que el proceso se pueda probar: puedes verificar el enrutamiento con cincuenta correos reales sin ejecutar el resto.

Cuándo elegir un flujo agéntico

Encaja cuando:

• el proceso es estable, pero las peticiones varían demasiado para cubrirlo todo con reglas;
• el número de ramas sería inmanejable en un flujo convencional;
• la calidad mejora claramente con una revisión basada en criterios explícitos;
• necesitas poder explicar qué ocurrió en cada caso.

Quédate con un flujo sencillo si una secuencia fija ya da resultados fiables. Pasa a un agente solo si de verdad no se pueden conocer los pasos de antemano, como en una investigación abierta o un diagnóstico. La guía de Anthropic da el mismo consejo: buscar la solución más sencilla posible y añadir complejidad solo cuando mejore los resultados. La comparación detallada está en agentes de IA vs. automatización de flujos, y la lista de tareas que conviene automatizar con IA te ayuda a elegir por dónde empezar.

Cuánto cuesta

Cada decisión que delegas en el modelo es una llamada más, y los bucles multiplican las llamadas. En el ejemplo, un presupuesto requiere entre seis y una docena de llamadas según el número de servicios y de rondas de evaluación, frente a tres o cuatro en un flujo sin orquestación ni evaluación. Dos reglas contienen la factura:

• Acota todo lo que pueda repetirse: número de subtareas, número de rondas, presupuesto por caso.
• Ajusta el modelo al paso: uno pequeño para enrutar y extraer, uno más capaz para orquestar y redactar.

Estima las dos variantes con la calculadora de coste de API de LLM antes de construir: multiplica los tokens por llamada por el número de llamadas en el caso medio y en el peor caso.

Controles

• Un formato fijo entre pasos. JSON o tabla, nunca texto libre.
• Decisiones cerradas. El enrutamiento elige de una lista y no inventa categorías. Prevé siempre una salida «no lo sé» hacia una persona.
• Límites allí donde haya un bucle.
• Permisos mínimos. Solo lectura mientras escribir no sea imprescindible.
• Aprobación humana antes de cualquier acción irreversible: envíos a clientes, pagos, cambios en datos. Consulta IA con human-in-the-loop.
• Un registro por caso: la decisión tomada en cada punto, con su entrada y su salida.
• Un conjunto de pruebas por punto de decisión, que se repite con cada cambio de prompt o de modelo.

Si el flujo afecta a decisiones sobre personas, como candidaturas o créditos, revisa antes la parte normativa; lo explicamos en regulación de agentes de IA.

Errores habituales

• Poner pasos agénticos en todas partes. Cada decisión delegada es una fuente de variación. Tres puntos de decisión bien elegidos valen más que diez.
• Olvidar la rama de salida. Sin «otro» o «incompleto», el enrutamiento mete los casos atípicos en una rama que no les corresponde.
• Dejar al evaluador sin criterios. «Comprueba que está bien» no aporta nada útil; una checklist, sí.
• Probar solo el resultado final. Pierdes la principal ventaja: saber qué decisión fue la equivocada.
• Confundir una demo con producción. Un flujo que funciona con cinco ejemplos todavía no ha visto tus casos difíciles.

Checklist antes de construir

• El proceso está dibujado paso a paso, sin IA, tal como funciona hoy.
• Los puntos en los que una decisión del modelo aporta valor están identificados y reducidos a lo necesario.
• Cada decisión tiene una lista cerrada de opciones y una salida hacia una persona.
• Cada bucle tiene un límite de rondas y de presupuesto.
• Las acciones irreversibles pasan por una aprobación humana.
• Hay un conjunto de casos reales para cada punto de decisión.
• El coste está estimado para el caso medio y el peor caso.
• Un responsable revisa los registros durante las primeras semanas.

Fuentes

• Anthropic: Building effective agents (definiciones de flujos de trabajo y agentes, cinco patrones de flujo)
• Comisión Europea, AI Act Service Desk: ¿Cómo se abordan los agentes de IA en el marco de la Ley de IA?