No construyas un agente cuando un workflow es suficiente
Tabla de contenido
Te piden automatizar la gestión de devoluciones. La primera propuesta suele sonar muy bien en una demo: «Dale un agente acceso al correo, al sistema de pedidos y a la API de reembolsos. Que lea la solicitud y resuelva el caso».
También puede salir bien. Hasta que el agente interpreta mal una política, encuentra dos pedidos parecidos y devuelve el dinero del equivocado. La pregunta importante no es si podemos construir ese agente. Es si necesitamos darle tanta libertad para resolver el problema.
En el artículo anterior hablaba de diseñar el sistema que rodea al modelo. Aquí quiero bajar un nivel: ¿cuándo basta con un workflow y cuándo tiene sentido un agente?
Un workflow también puede usar IA #
Un workflow describe pasos y decisiones que podemos definir de antemano: validar una entrada, consultar un sistema, aplicar una regla y ejecutar una acción. Puede incluir una llamada a un modelo; «workflow» no significa «prohibido usar IA».
La documentación de Microsoft Agent Framework describe los workflows como rutas de ejecución explícitas e inspeccionables que coordinan código, estado, agentes y participación humana. Un modelo puede clasificar un texto dentro de ese flujo, mientras el código normal valida el resultado y decide qué hacer después.
Un agente, en cambio, resulta útil cuando la tarea no tiene una secuencia completamente conocida. Puede interpretar el objetivo, elegir herramientas y decidir qué paso intentar a continuación. La documentación de Microsoft Agent Framework y la guía de agentes de OpenAI describen precisamente agentes que combinan modelos, herramientas y contexto para completar tareas de varios pasos.
La diferencia no es «IA frente a código». Es quién decide el siguiente paso y cuánto puede variar el camino.
El ejemplo de las devoluciones #
Si el proceso tiene reglas claras, empezaría con un workflow:
Solicitud
-> validar número de pedido
-> comprobar fecha de compra
-> aplicar política de devolución
-> pedir aprobación si supera el límite
-> emitir etiqueta o reembolso
-> registrar el resultado
¿Dónde encaja el modelo? Puede extraer el número de pedido de un correo o clasificar el motivo de la devolución. Pero no le pediría que «interprete la política» y ejecute un reembolso por su cuenta si la política se puede expresar con reglas verificables.
Ahora cambia el caso: «Investiga por qué este cliente ha recibido tres cargos, revisa su historial y dime qué deberíamos hacer». Quizá haya que buscar en varios sistemas, comparar fechas, localizar una incidencia y pedir más información. No sabemos de antemano qué consulta será la siguiente. Ahí un agente puede aportar valor: explorar un conjunto acotado de herramientas y reunir evidencia para proponer una respuesta.
Incluso entonces separaría investigar de actuar. El agente puede preparar una propuesta de reembolso; una regla y, según el importe, una persona autorizada deciden si se ejecuta. Darle acceso a una API no obliga a convertir cada sugerencia del modelo en una operación real.
Una regla práctica para elegir #
Yo empezaría con un workflow cuando:
- los pasos y las reglas de negocio son conocidos;
- las mismas entradas deberían producir decisiones consistentes;
- hay efectos externos que deben quedar controlados y auditables;
- podemos expresar las excepciones con condiciones explícitas.
Me plantearía un agente cuando:
- el objetivo está claro, pero no la secuencia para alcanzarlo;
- la tarea necesita elegir dinámicamente entre varias herramientas;
- puede ser necesario preguntar, investigar o iterar según lo que encuentre;
- el valor de esa flexibilidad compensa el coste de probar y supervisar más caminos.
No son categorías incompatibles. Microsoft documenta cómo integrar agentes dentro de workflows: puedes mantener el proceso principal explícito y reservar la autonomía para una parte concreta. También puedes pausar un workflow para solicitar aprobación o información humana.
Por ejemplo:
Workflow:
validar pedido
-> aplicar reglas de elegibilidad
-> agente: investigar una excepción ambigua
-> comprobar propuesta contra la política
-> aprobación humana si corresponde
-> ejecutar y registrar
Así evitamos que toda la operación dependa de un bucle abierto cuando solo una etapa necesita interpretación.
La autonomía también tiene factura #
Un agente que prueba varias herramientas y vuelve a razonar puede resolver casos que un flujo rígido no cubre. Pero cada paso adicional puede aumentar latencia y coste, y abre más combinaciones que probar. Si además puede escribir en sistemas externos, hay que limitar permisos, controlar las acciones y decidir qué requiere confirmación.
Por eso no mediría solo «¿ha contestado bien?». Mediría el resultado del proceso: casos resueltos correctamente, errores que requieren revisión, acciones no autorizadas, tiempo total y coste por caso resuelto. Si el agente queda por detrás en calidad o coste, no se arregla poniéndole un nombre más moderno.
La observabilidad de workflows de Agent Framework, por ejemplo, permite inspeccionar la ejecución y sus pasos. Esa trazabilidad importa también cuando uses otro framework: si no puedes reconstruir qué herramienta se llamó, con qué resultado y por qué se tomó una decisión, te faltan datos para operar y mejorar el sistema.
Mi lista mínima antes de dar autonomía a un agente sería:
- Limitar las herramientas y los permisos al mínimo necesario.
- Exigir confirmación antes de acciones con impacto económico o difícilmente reversible.
- Probarlo con casos representativos, incluidos errores y entradas ambiguas.
- Registrar los pasos y definir qué hacer cuando el agente no tiene suficiente información.
Si todavía no puedes contestar a «¿qué pasa cuando falla?», aún no estás listo para que actúe sin supervisión.
Construye la mínima autonomía necesaria #
Un workflow no es una versión menos inteligente de un agente. Es una forma de hacer explícitas las decisiones que ya conocemos. Un agente no es automáticamente mejor porque pueda decidir más cosas; esa libertad solo vale la pena cuando resuelve una incertidumbre real.
Mi orden sería: primero identifica qué debe conseguir el proceso; luego fija las reglas, las acciones permitidas y los puntos de control; por último, añade autonomía solo donde el camino no se pueda especificar razonablemente de antemano.
En otras palabras: no construyas un agente porque la tarea lleve la etiqueta «IA». Construye uno cuando necesites que el sistema decida cómo avanzar, y puedas demostrar que esa decisión compensa el coste y el riesgo.