«¿Dónde está mi pedido?» y «Me prometisteis la entrega ayer; el transportista dice otra cosa y necesito cambiar la dirección» pueden llegar al mismo buzón con apenas un minuto de diferencia. Para un equipo de soporte son trabajos distintos. La primera consulta quizá se resuelva leyendo un registro; la segunda obliga a reconstruir lo ocurrido antes de decidir qué contestar.
Esa diferencia, tan cotidiana, debería pesar más en la arquitectura que las ganas de incorporar un agente de IA. Si estás valorando una automatización, merece la pena llevar ambas solicitudes a la reunión de diseño. ¿Qué parte del trabajo conoces de antemano y en qué momento hace falta investigar? Ahí empieza una elección útil entre workflows, agentes y una combinación de los dos.
La diferencia está en quién decide el siguiente paso
Un workflow determinista sigue una secuencia y unas condiciones definidas por sus diseñadores. Recibe datos, comprueba requisitos, consulta sistemas y ejecuta acciones conforme a reglas explícitas. Determinista describe aquí el control del recorrido: una llamada externa o un componente de IA dentro del flujo puede seguir produciendo resultados variables.
Un agente utiliza un modelo para decidir parte del recorrido: qué información necesita, qué herramienta consultar o cuándo dejar de investigar. Esa flexibilidad resulta útil cuando las entradas y los pasos no pueden anticiparse completamente. La distinción de Anthropic entre workflows y agentes ayuda a separar rutas predefinidas de decisiones dinámicas. Ninguna categoría implica mayor madurez por sí misma. La arquitectura adecuada es la que cumple el objetivo con un nivel aceptable de coste, tiempo y riesgo.
Conviene distinguir tres incertidumbres. La primera afecta a la entrada: un formulario estructurado frente a un correo ambiguo. La segunda afecta al recorrido: pasos conocidos frente a una investigación que depende de resultados intermedios. La tercera afecta al criterio de éxito: una igualdad contable verificable frente a una respuesta cuya calidad exige valoración.
Un correo libre no obliga a construir un agente. Un modelo puede extraer sus campos y devolver una propuesta estructurada; después, reglas convencionales validan los valores y deciden el destino. El proceso mantiene así un recorrido previsible aunque incorpore interpretación. La autonomía empieza a tener sentido cuando el sistema debe elegir entre varias consultas y revisar su plan según lo que encuentra. Incluso entonces, conviene acotar el espacio de decisiones.
Un pedido, dos recorridos posibles
Volvamos al buzón de una distribuidora imaginaria. El cliente pide cambiar la dirección porque su entrega se ha retrasado. Antes de interpretar su enfado, el sistema necesita saber de qué pedido habla y si esa persona está autorizada a consultarlo. Un workflow puede resolver esas comprobaciones con reglas explícitas; después, un componente de IA interpreta la petición y propone cómo continuar.
Si el pedido todavía está en preparación, quizá baste con consultar la política de cambios. Si los registros del almacén y del transportista se contradicen, un agente limitado puede buscar comunicaciones anteriores o pedir el dato que falta. La autonomía aparece en esa investigación, donde aporta algo concreto, y no se extiende por defecto a todo el proceso.
La frontera importante llega al actuar. Consultar un pedido, recuperar mensajes y proponer una resolución son herramientas distintas de modificar la dirección o conceder una compensación. Estas últimas necesitan sus propias validaciones y aprobaciones. Un mensaje convincente del cliente no cambia esa política, del mismo modo que una respuesta convincente del agente tampoco demuestra que tenga autorización para ejecutarla.
Hasta dónde puede llegar una herramienta
Cada herramienta debería expresar una operación de negocio reconocible, con parámetros, validaciones y resultados definidos. «Actualizar cliente» es demasiado amplio si admite cambios en cualquier campo. «Proponer corrección del teléfono de contacto» tiene un alcance más comprensible. La autorización debe comprobarse en el sistema que ejecuta la acción. Un prompt que dice «no modifiques datos sensibles» no sustituye un permiso técnico. También conviene separar las herramientas de lectura de las de escritura, registrar quién solicita la operación y conservar un identificador del caso.
Establece límites de iteraciones, tiempo y gasto. Cuando se alcanzan, el proceso debe entregar un estado útil a una persona, incluyendo lo consultado y lo pendiente. Seguir buscando indefinidamente no equivale a resolver mejor.
La respuesta bonita también puede estar equivocada
Antes de aumentar la autonomía, prepara una colección de casos representativos. Incluye entradas completas, solicitudes ambiguas, información contradictoria y servicios que no responden. Define por adelantado qué significa resolver cada caso. Evalúa el workflow convencional, la alternativa híbrida y el agente con ese mismo conjunto. Mide resolución correcta, errores que llegan al cliente, intervención humana, latencia y coste por caso terminado. Repite las pruebas del componente probabilístico para observar variabilidad.
No te quedes con el porcentaje de respuestas plausibles. Un sistema puede escribir correctamente y consultar el pedido equivocado. La validación debe comprobar el resultado de negocio y las acciones realizadas, no solo la calidad del texto.
Lo que cuesta mantener esa flexibilidad
El coste del modelo es una parte del total. También cuentan llamadas a herramientas, almacenamiento, supervisión, reintentos, revisión humana y mantenimiento. Una solución con menos tokens puede salir más cara si obliga a corregir numerosos casos.
En procesos frecuentes y estables, unas reglas sencillas suelen ofrecer una base fácil de operar. En investigaciones variables, esa misma rigidez puede generar una larga cola de excepciones. El análisis debe comparar el coste completo de ambas alternativas con la frecuencia real de cada escenario. Documenta qué mejora justifica la complejidad adicional. Por ejemplo, una mayor proporción de incidencias correctamente resueltas sin aumentar acciones indebidas. Esa condición es más útil que el objetivo genérico de «usar agentes».
El diseño seguirá cambiando después del lanzamiento: aparecerá una política comercial nueva, se sustituirá una integración o el equipo descubrirá una excepción que no había previsto. Por eso hacen falta un responsable funcional, que pueda decidir qué es aceptable, y otro técnico, que controle permisos, pruebas y despliegues. Dejar esas decisiones sin dueño acaba convirtiendo cada incidencia en una negociación.
La próxima vez que alguien proponga «poner un agente» en ese buzón, pide comparar cómo resolvería las dos solicitudes del principio. Si un workflow resuelve bien la primera, no necesita más autonomía. Si la segunda mejora con una investigación limitada y verificable, ya existe una razón para incorporarla. Puedes trabajar esa comparación con DigitalCube, llevando casos concretos, las excepciones que hoy llegan al equipo y los resultados que no puedes permitirte perder.