Agente o flujo de trabajo: cuándo usar cada uno (y por qué confundirlos sale caro)

Cuando alguien en tu empresa dice «vamos a poner IA aquí», la primera pregunta que hay que hacerse es si lo que necesitas es un agente o un flujo de trabajo de IA. La diferencia entre un agente y un flujo de trabajo de IA no es un detalle técnico: es la decisión que determina coste, control y si el proyecto acaba funcionando o muerto en seis meses.

La confusión entre agente o flujo de trabajo es el origen de la mayoría de fracasos que he visto al implantar IA en empresas.

Imagina que le explicas a un empleado cómo hacer una transferencia bancaria. Le das los pasos: entra al portal, introduce el IBAN, pon el importe, confirma. Siempre igual. No hay que pensar. Eso es un flujo de trabajo.

Ahora imagina que le dices: «Gestiona las reclamaciones de clientes esta semana.» Ahí ya no hay pasos fijos. Hay que leer cada caso, entender qué pide el cliente, decidir si escalar o resolver, redactar la respuesta adecuada. Eso requiere juicio. Eso es un agente.

Qué es un flujo de trabajo de IA y qué es un agente: definición canónica

Anthropic, en su guía técnica Building Effective Agents (Construyendo agentes eficaces), establece la distinción de forma precisa: un workflow sigue pasos predefinidos donde el flujo de control está fijado de antemano, mientras que un agente decide dinámicamente su propio camino en función de lo que encuentra. Dos conceptos distintos, dos herramientas distintas.

Flujo de trabajo de IA (workflow)

Un flujo de trabajo es una secuencia de pasos predefinida. Siempre los mismos, siempre en el mismo orden. La IA puede participar en alguno de esos pasos —resumir un documento, extraer datos de una factura, clasificar un correo— pero el camino está fijado de antemano.

Piénsalo como una receta de cocina. Tienes ingredientes, tienes pasos, tienes resultado esperado. Si sigues la receta, sale igual todas las veces.

Ejemplos que funcionan bien como flujo:

• Recibir una factura PDF → extraer proveedor, importe, fecha → volcarlos en el ERP
• Recibir un correo con una consulta de tipo conocido → clasificarlo → enviarlo al departamento correcto
• Generar un informe semanal de ventas con los mismos KPIs, cada lunes a las 8:00

El flujo de trabajo no improvisa. No toma decisiones. Solo ejecuta. Y eso, lejos de ser un defecto, es su mayor virtud: es barato, predecible y fácil de auditar.

Agente de IA

Un agente decide sobre la marcha. No tiene el camino prefijado: tiene un objetivo y herramientas, y va eligiendo qué hacer en función de lo que encuentra.

Si el flujo de trabajo es una receta, el agente es el cocinero que improvisa con lo que hay en la nevera. Tiene criterio. Puede cambiar de plan si algo no sale como esperaba. Puede usar distintas herramientas según lo que necesite en cada momento.

Ejemplos donde hace falta un agente:

• Analizar el pipeline de ventas y detectar qué oportunidades están en riesgo, razonando sobre el contexto de cada una
• Revisar contratos y marcar las cláusulas que se desvían de tu estándar, teniendo en cuenta el tipo de contrato y el cliente
• Responder preguntas de clientes que mezclan información de varias fuentes y requieren criterio para combinarlas bien

El agente no sigue pasos fijos porque el problema no tiene pasos fijos. Cada caso es distinto. Y eso requiere que algo —o alguien— decida.

Agente o flujo de trabajo: la regla práctica para elegir

Antes de montar nada, hazte una sola pregunta:

¿El camino para resolver esto es siempre el mismo, independientemente del caso concreto?

Si la respuesta es sí: flujo de trabajo.

Si la respuesta es no, o «depende»: agente.

Hay una variante más precisa de la misma pregunta: ¿podría escribir los pasos exactos en un documento y que cualquier persona los siguiera sin necesidad de pensar? Si sí, es un flujo. Si necesitas añadir «y aquí hay que valorar el contexto» o «y aquí habría que ver qué dice el cliente exactamente», ya estás en territorio de agente.

En mi experiencia, el 60-70% de los procesos que los equipos describen como «complejos» son en realidad flujos perfectamente predecibles. Lo que los hace parecer complejos es que están mal documentados o que nunca nadie los ha sistematizado. Eso no los convierte en casos para agentes.

Por qué confundirlos sale caro

El error más habitual: poner un agente donde basta un flujo

He visto empresas que montan un agente para procesar facturas. El agente «decide» qué hacer con cada factura. Resultado: las facturas se procesan de formas ligeramente distintas cada vez, a veces bien, a veces con errores pequeños que nadie detecta hasta que el auditor los encuentra. Coste por factura procesada: cuatro veces más que con un flujo simple.

Un flujo bien montado para ese proceso habría sido más rápido, más barato y cien veces más auditable.

Poner un agente donde basta un flujo tiene tres consecuencias directas:

• Más coste: los agentes consumen más tokens, más llamadas a la API, más tiempo de cómputo
• Menos control: si el agente «decide», tú no sabes exactamente por qué tomó cada decisión
• Resultados impredecibles: el mismo input puede producir outputs distintos según el día

El error contrario: poner un flujo donde hace falta criterio

El flujo falla en cuanto cambia algo que no estaba previsto. Si el proceso tiene excepciones frecuentes, casos especiales, o datos que varían de formas que no puedes anticipar, el flujo se rompe.

He visto flujos de atención al cliente que funcionaban bien para las consultas estándar y fallaban estrepitosamente cada vez que un cliente preguntaba algo ligeramente fuera de guión. El sistema no sabía qué hacer. O peor: hacía algo, pero algo incorrecto.

Un agente en ese contexto habría manejado la variabilidad. El flujo no puede.

Cómo combinarlos bien

En los sistemas que funcionan en producción, flujos y agentes conviven. El flujo hace lo predecible. El agente gestiona lo que requiere criterio.

Un ejemplo típico: el flujo recibe el correo, lo clasifica por tipo, extrae los datos básicos y lo encola. Si es una consulta estándar, el flujo la resuelve directamente. Si es una reclamación compleja o un caso fuera de categoría, lo pasa al agente, que analiza, razona y decide cómo responder.

No es todo flujo ni todo agente. Es cada cosa donde corresponde.

Señales de que necesitas un agente, no un flujo

• El proceso tiene excepciones frecuentes que no puedes listar de antemano
• La respuesta correcta depende de matices del contexto, no solo de los datos presentes
• Alguien de tu equipo dice «hay que verlo caso a caso»
• El proceso actual depende de la experiencia de una persona concreta que «sabe cómo se hace»

Señales de que un flujo es suficiente

• Puedes escribir los pasos en un documento y no hay ambigüedad
• El resultado esperado es siempre del mismo tipo
• Las excepciones son raras y conocidas (y se pueden manejar con una rama más en el flujo)
• El proceso lleva meses o años haciéndose igual

El coste real de la confusión

No es solo dinero. Es también el efecto sobre el equipo.

Cuando montas un agente para algo predecible y el resultado varía sin razón aparente, la gente pierde confianza en el sistema. «A veces funciona, a veces no.» Eso mata la adopción. El equipo deja de usarlo, vuelve a hacerlo a mano y el proyecto de IA muere sin pena ni gloria.

Cuando montas un flujo para algo que requiere criterio y el sistema falla en los casos difíciles —justo los casos donde más lo necesitas— el daño es peor. Porque el flujo da una respuesta aunque sea incorrecta, y eso puede llegar al cliente o al proveedor antes de que nadie lo detecte.

La elección entre flujo y agente no es un detalle técnico que le puedes delegar al informático. Es una decisión de negocio que afecta a coste, calidad y confianza del equipo. Necesitas entenderla tú.

Leer también: Qué es un agente de IA y El agente orquestador.

—

Preguntas frecuentes

¿Puedo empezar con un flujo y convertirlo en agente más adelante? Sí, y es muchas veces la estrategia correcta. Empieza con un flujo bien documentado para el proceso predecible. Cuando identifiques dónde el flujo se rompe —dónde aparecen excepciones que no puedes sistematizar— ahí incorporas un agente para esa parte concreta. No hace falta decidirlo todo al principio.

¿Los flujos de trabajo son menos «inteligentes» que los agentes? No es una cuestión de inteligencia. Es una cuestión de qué problema tienes. Un flujo bien diseñado para el proceso correcto es más fiable y más barato que un agente mal aplicado. La IA no es mejor solo porque sea más autónoma. Es mejor cuando resuelve el problema real con el mínimo de complejidad necesaria.

¿Cómo sé si mi proceso tiene suficiente variabilidad para necesitar un agente? Cuenta las excepciones del último mes. Si en un proceso de 200 casos tienes 3 excepciones, probablemente un flujo con una rama de escalado manual es suficiente. Si tienes 40 excepciones de tipos distintos que nadie sabe prever, ahí sí tienes un caso para un agente. El volumen y la variabilidad de las excepciones es el indicador más fiable.