Regla rápida: si el siguiente paso puede definirse de antemano, empieza por automatización. Si el sistema necesita interpretar contexto y elegir entre herramientas o rutas, puede justificar un agente. En producción, lo habitual es un híbrido: estructura determinista donde sabemos qué debe ocurrir y autonomía sólo donde compra flexibilidad real.
La arquitectura más simple suele ser más barata, predecible y auditable. Por eso la pregunta no es cuántos agentes podemos añadir, sino en qué punto del workflow las reglas dejan de describir razonablemente el camino.
| Arquitectura | Quién decide el recorrido | Uso típico |
|---|---|---|
| Automatización clásica | Código/reglas | Pasos conocidos y datos estructurados. |
| Automatización con IA | El flujo sigue fijo; el modelo interpreta una etapa. | Clasificar, extraer, resumir dentro de un proceso. |
| Agente | El modelo elige herramientas o pasos dentro de límites. | Tareas donde el contexto cambia la ruta. |
| Híbrida | Workflow controla estados; agente decide sólo una parte. | La mayoría de sistemas empresariales complejos. |
Recibir factura → extraer → validar → registrar es un recorrido conocido. Puede usar IA para leer el documento y seguir siendo una automatización. Investigar una incidencia B2B, en cambio, puede requerir consultar pedido, CRM, documentación, pedir un dato y decidir después qué hacer: ahí aparece una razón real para agencia.
Microsoft describe este continuo de forma similar en Agent Framework: workflows explícitos para control y agentes en las etapas que se benefician de razonamiento dinámico.
Microsoft Agent Framework · Workflows.
Entrada: PDF. El sistema identifica proveedor, importe y fecha; valida esquema, contrasta pedido y registra si todo encaja. Las excepciones salen a revisión. El LLM puede ayudar a interpretar campos, pero no necesita decidir libremente qué herramientas probar.
Hacerlo agéntico añadiría variabilidad donde ya teníamos una secuencia verificable.
“El cliente dice que el pedido no llega y amenaza con cancelar.” Dependiendo del estado, el sistema puede consultar tracking, CRM, stock, condiciones contractuales o abrir una incidencia. No siempre sabemos qué dato faltará ni en qué orden.
Un agente puede aportar flexibilidad, pero cada tool sigue siendo estrecha: consultar pedido, crear borrador, abrir ticket. El modelo no recibe acceso general al backend.
Un flujo fijo puede fallar en una etapa. Un agente además puede elegir la herramienta equivocada, repetir una acción, entrar en bucle, continuar con un estado inconsistente o detenerse demasiado pronto.
Por eso los controles cambian: límites de pasos, timeout, herramientas permitidas, presupuesto, idempotencia, aprobación para acciones sensibles y una salida explícita de “no puedo resolver”.
Leer un CRM, preparar una nota, escribir un campo, enviar un correo y cancelar un pedido tienen consecuencias distintas. Diseñamos autonomía por acción y por contexto. Una tool puede ser automática en lectura y requerir confirmación en escritura.
Ese modelo de permisos permite usar agentes sin convertirlos en superusuarios.
Un workflow fijo suele ejecutar menos pasos y tiene una latencia más estable. Un agente puede explorar rutas y llamar a varias herramientas. Eso puede merecer la pena si evita trabajo humano que antes exigía investigación; es desperdicio si el camino ya era conocido.
Las métricas útiles son coste por tarea resuelta, pasos por tarea, p50/p95 de latencia y tasa de escalado, no precio por llamada al modelo.
En automatización observamos estados, entradas/salidas y reintentos. En agentes añadimos tool choice, argumentos, número de pasos, cambios de estado y motivo de parada.
Si el sistema termina con una respuesta correcta después de intentar dos acciones prohibidas y un retry innecesario, el resultado final no cuenta toda la historia.
Un workflow puede decidir cuándo invocar un agente; el agente puede elegir una tool; la tool ejecuta reglas deterministas; y el flujo recupera control para validar y escribir. También puede ocurrir al revés: un agente coordina subflujos cerrados.
El objetivo no es maximizar autonomía. Es poner variabilidad sólo donde aporta y mantener garantías fuera del modelo siempre que sea posible.
Si las tres primeras apuntan a un camino estable, empieza por automatización. Siempre puedes introducir agencia después con evidencia.
Respuestas directas para convertir la pregunta en una decisión de proyecto.
La automatización sigue un flujo predefinido; un agente puede elegir entre herramientas o siguientes pasos según contexto dentro de límites.
No. Si el orden y las acciones están fijados y el modelo sólo interpreta una etapa, sigue siendo una automatización con IA.
No. Cuando el recorrido es estable, un workflow suele ser más barato, predecible y fácil de auditar.
Sí. Es común que un agente elija una herramienta y que cada herramienta ejecute reglas o subflujos deterministas.
Elección incorrecta de herramientas, bucles, estado inconsistente, más pasos y acciones con efectos reales.
Con herramientas estrechas, permisos por acción, límites de pasos y coste, idempotencia, confirmaciones, aprobación y condiciones de parada.
Mapeamos rutas, excepciones y herramientas y usamos el nivel mínimo de agencia que resuelva el trabajo sin comprar complejidad innecesaria.