ARQUITECTURA IA · WORKFLOWS · AGENTES · AUTOMATIZACIÓN
Workflow o agente de IA
Un proceso puede tener veinte pasos y no necesitar un agente. Otro puede tener cuatro y sí necesitar que la IA interprete el contexto, elija una herramienta y decida cómo continuar. La diferencia no está en la cantidad de nodos: está en quién decide el siguiente paso.
La pregunta no es cuánta IA puedes introducir. Es cuánto criterio necesita el sistema para decidir qué hacer a continuación.
Un workflow puede tener reglas, ramas, APIs e incluso pasos con IA. Sigue siendo un workflow si la arquitectura define de antemano qué ocurre después de cada resultado.
Un agente aparece cuando el modelo dispone de herramientas y puede elegir, dentro de límites, qué acción realizar, qué información consultar o cómo continuar según lo que va encontrando.
La mejor arquitectura no es la que concede más autonomía, sino la que concede la autonomía necesaria y no más.
El proceso tiene 23 pasos. Eso no significa que necesite un agente
Es una confusión fácil de entender. Cuando vemos un flujo con muchas ramas, excepciones y sistemas conectados, parece lógico concluir que hemos superado la automatización convencional y necesitamos un agente de IA.
Pero la complejidad visual del diagrama no es la variable decisiva.
Un proceso de compras puede contener veinte validaciones y seguir funcionando mejor con reglas explícitas. Una solicitud comercial de cuatro pasos puede necesitar mucha más interpretación si el sistema debe leer correos ambiguos, consultar varias fuentes y decidir qué falta antes de poder continuar.
La pregunta útil es otra:
¿Podemos definir de antemano cómo se decide el siguiente paso o necesitamos que la IA lo determine según el contexto que va encontrando?
Esta distinción es más útil que preguntar si queremos «automatización tradicional» o «agentes». También evita diseñar una arquitectura alrededor de una etiqueta comercial.
La guía general sobre agentes de IA explica qué capacidades necesita un agente para actuar sobre herramientas y procesos. Aquí la cuestión es más concreta: cuándo tiene sentido entregar parte de la decisión al modelo y cuándo es preferible mantenerla en reglas explícitas.
No hay dos opciones: hay al menos cuatro arquitecturas útiles
Reducir la decisión a «workflow o agente» deja fuera una parte muy importante de los sistemas que funcionan bien en producción.
1. Workflow determinista
Las reglas y rutas se conocen de antemano.
Ejemplo: si el importe supera un umbral, solicitar aprobación; si no, continuar.
2. Workflow con IA
La ruta sigue estando controlada, pero un modelo resuelve una tarea concreta que requiere interpretar contenido.
Ejemplo: clasificar un email y devolver una categoría conocida.
3. Agente
El modelo dispone de herramientas y puede elegir cómo avanzar dentro de los límites definidos.
Ejemplo: decidir si consulta CRM, documentación o historial antes de proponer la siguiente acción.
4. Arquitectura híbrida
El workflow mantiene el control general y entrega a un agente solo las partes que requieren más criterio.
Ejemplo: investigar una incidencia con varias herramientas y devolver una propuesta estructurada antes de una acción controlada.
En la práctica, muchas soluciones empresariales no necesitan saltar desde reglas puras a un agente que gestione todo el proceso. El segundo y el cuarto modelo permiten introducir flexibilidad sin renunciar al control donde más importa.
Qué es realmente un workflow
Workflow significa flujo de trabajo. En automatización describe una secuencia de pasos y decisiones cuya lógica está definida por anticipado.
Eso no significa que tenga que ser lineal.
Puede contener condiciones, rutas alternativas, bucles controlados, esperas, reintentos, aprobaciones, llamadas a APIs, cálculos, escritura en distintos sistemas y decenas de excepciones.
Evento: llega una factura.
Regla: comprobar si existe proveedor.
Regla: verificar campos obligatorios.
Condición: si falta información, generar tarea.
Condición: si el importe supera el umbral, solicitar aprobación.
Acción: crear borrador en ERP.
Hay bastante lógica. Sin embargo, ninguna de esas decisiones necesita que un modelo decida libremente qué hacer. La empresa ya conoce las condiciones relevantes y puede expresarlas como reglas.
Por eso muchas ramas no convierten un workflow en agente. Un diagrama puede ser grande y seguir siendo completamente predecible.
Un workflow puede utilizar IA y seguir siendo un workflow
Esta es una de las distinciones más importantes del artículo.
Introducir un modelo de lenguaje en un paso del proceso no significa entregar al modelo el control del proceso completo.
En todos estos casos, el modelo resuelve una ambigüedad local. La arquitectura sigue determinando las consecuencias.
La automatización documental con IA es un buen ejemplo: leer un documento con IA puede ser una capacidad dentro de una cadena mucho más controlada de validación, reglas y escritura.
Qué cambia cuando entra un agente
Un agente utiliza un modelo para gestionar parte de la ejecución del trabajo. No solo produce texto: puede analizar el estado del problema, utilizar herramientas, observar resultados y decidir qué hacer después.
Anthropic distingue precisamente entre workflows con rutas de código predefinidas y agentes donde el modelo dirige su proceso y uso de herramientas. OpenAI utiliza una idea similar: un agente usa un modelo para gestionar la ejecución del workflow y puede seleccionar herramientas según el estado de la tarea.
Eso no significa que el agente tenga libertad ilimitada.
Puede tener tres herramientas y no treinta. Puede consultar datos, pero no modificarlos. Puede preparar una propuesta, pero no aprobarla. Puede detenerse después de un número máximo de pasos.
“Agentic” o “agéntico” describe un sistema donde el modelo tiene cierto grado de capacidad para actuar, elegir herramientas o determinar cómo continuar. No significa necesariamente autonomía total ni ausencia de reglas.
En este artículo utilizaremos «agentic» únicamente cuando ayude a describir ese grado de autonomía. En español, siempre que sea posible, hablaremos de decisión contextual, elección de herramientas o autonomía limitada, que resulta mucho más claro.
Tool calling: que la IA pueda usar una herramienta no significa que tengamos un agente
Tool calling puede traducirse como llamada o uso de herramientas.
Consiste en dar al modelo acceso a funciones que realizan operaciones fuera del propio modelo: consultar un CRM, buscar un documento, leer una base de datos, crear una tarea, enviar un email o llamar a una API.
La diferencia clave está en quién decide cuándo se utiliza la herramienta y qué ocurre después.
Workflow con herramienta
El flujo establece: «Después de clasificar este documento, consulta el ERP con este identificador».
El uso de la herramienta estaba previsto por la arquitectura.
Agente con herramientas
El modelo recibe un objetivo y puede decidir si necesita consultar ERP, CRM, documentación o pedir más información.
La selección y el orden dependen de lo que encuentra.
Por tanto, un chatbot que ejecuta una función para reservar una cita no es automáticamente un agente. Puede ser un workflow muy bien diseñado donde una intención concreta activa una operación concreta.
Esta distinción evita llamar «agente» a cualquier aplicación que combine un LLM con una API.
Mínima autonomía suficiente: dar libertad solo donde aporta valor
En Yarvia utilizamos mínima autonomía suficiente como criterio de diseño, no como término estándar del sector.
Significa algo sencillo:
Usar el menor grado de autonomía que permita resolver correctamente el problema.
No porque la autonomía sea mala, sino porque cada grado adicional introduce más posibilidades de comportamiento, más necesidad de observación y más superficie que probar.
Si una regla clara resuelve una operación de forma fiable, no hay ventaja en pedir a un modelo que vuelva a decidirla cada vez.
Si una tarea exige leer información poco estructurada, descubrir qué falta, elegir entre varias fuentes y adaptar la secuencia según lo que encuentra, una capa de mayor autonomía puede reducir un conjunto enorme de reglas.
La decisión no consiste en moverse siempre hacia la derecha. Consiste en detenerse en el nivel que resuelve el problema con suficiente calidad.
Esta lógica complementa el marco de SaaS, integración o automatización a medida: primero decidimos qué capa tecnológica hace falta; después, dentro de esa capa, cuánto control debe permanecer explícito y cuánto criterio merece delegarse al modelo.
La arquitectura híbrida no es una solución de compromiso: muchas veces es la opción más lógica
No hay ninguna obligación de diseñar todo el proceso como workflow o todo como agente.
Podemos mantener bajo reglas las partes que necesitan exactitud y dejar al agente únicamente el tramo donde existe verdadera ambigüedad.
1. Trigger. Llega una solicitud.
2. Validaciones deterministas. Identidad, permisos, datos obligatorios y estado.
3. Subtarea con agente. Interpretar el caso, consultar fuentes autorizadas y preparar una propuesta.
4. Verificación. Comprobar formato, datos, límites y evidencia.
5. Acción controlada. Ejecutar únicamente aquello que esté permitido.
6. Registro. Guardar resultado, herramientas utilizadas y excepciones.
Esto permite, por ejemplo, que un agente investigue una incidencia compleja y proponga una solución mientras un workflow sigue controlando cualquier reembolso, cambio contractual o escritura sensible.
O que un agente decida qué documentación consultar para preparar un pedido ambiguo, pero la creación definitiva en ERP se produzca solo después de validaciones explícitas.
Guardrails, trazas y human-in-the-loop: tres conceptos distintos
Guardrails: controles que limitan o validan
Guardrail significa literalmente barandilla o barrera de protección. En sistemas de IA se utiliza para describir controles que comprueban entradas, salidas o acciones y pueden bloquear comportamientos no permitidos.
Un guardrail puede verificar que un dato tenga el formato correcto, que una petición esté dentro de alcance, que no se utilice una herramienta prohibida o que una acción sensible requiera aprobación.
No es una protección mágica. OpenAI recomienda combinar distintos controles y medidas tradicionales de autenticación, autorización y seguridad.
Trazas: reconstruir qué ocurrió
Tracing o trazabilidad de ejecución consiste en registrar lo que ha ocurrido durante una ejecución: llamadas al modelo, herramientas utilizadas, resultados devueltos, transferencias, guardrails y otros eventos.
Una traza permite reconstruir el recorrido completo de una ejecución para depurar, evaluar y monitorizar.
Esto es especialmente importante cuando dos solicitudes similares pueden recorrer caminos distintos.
Human-in-the-loop: una persona interviene en puntos definidos
Human-in-the-loop significa que una persona forma parte deliberada del circuito de decisión o control.
Puede ser para aprobar una acción, revisar un resultado, resolver una excepción o recuperar el control cuando el sistema no puede continuar.
No significa que alguien tenga que mirar todas las ejecuciones todo el tiempo.
La arquitectura detallada de intervención humana merece una pieza propia y será el centro de la entrada 29. Aquí basta con entender que un sistema puede tener autonomía en unos pasos y necesitar intervención humana en otros.
Prompt injection: cuando el contenido que lee el agente intenta darle órdenes
Los agentes suelen leer información que no controlamos completamente: páginas web, emails, documentos, tickets o mensajes.
Una prompt injection o inyección de instrucciones ocurre cuando ese contenido incorpora instrucciones diseñadas para influir en el comportamiento del modelo.
Imaginemos un agente que debe revisar emails y preparar respuestas. Un mensaje recibido podría contener texto que intenta convencer al agente de ignorar sus instrucciones y realizar otra acción.
El problema es especialmente relevante cuando el sistema no solo lee, sino que también tiene herramientas para enviar, modificar, comprar o borrar.
Regla de diseño: que el modelo pueda leer una instrucción no significa que deba tratarla como una orden válida. El origen y nivel de confianza de la información importan.
Esto no convierte el artículo en una guía de ciberseguridad. Sí refuerza una idea: cuanto mayor sea la capacidad de actuación del agente, más importante es limitar herramientas, permisos y operaciones.
Más flexibilidad también cambia coste, latencia y forma de probar
Un workflow suele tener un número de pasos relativamente previsible para cada ruta.
Un agente puede entrar en un ciclo:
Modelo: analiza la situación.
Herramienta: consulta una fuente.
Modelo: evalúa el resultado.
Herramienta: consulta otra fuente.
Modelo: decide si necesita seguir o ya puede cerrar.
Ese patrón puede ser exactamente lo que necesita un problema abierto. También puede añadir llamadas al modelo, uso de herramientas y tiempo de ejecución.
No existe una cifra universal de cuánto más caro o lento será. Depende del modelo, número de iteraciones, contexto, herramientas, caché, volumen y límites de cada caso.
Por eso conviene medir distribución, no solo promedio: cuánto tarda una ejecución normal, cuánto una difícil y qué porcentaje entra en bucles o reintentos.
La verificabilidad cambia cuánto riesgo podemos asumir
Si el resultado puede comprobarse automáticamente, la arquitectura dispone de una red adicional.
Podemos verificar si existe un pedido, si un importe coincide, si una API devolvió un estado válido o si una acción quedó registrada.
Cuando el resultado es subjetivo o el error puede permanecer oculto, dar más libertad exige controles adicionales.
Leer
Normalmente más reversible. Consultar CRM, documentación o estados.
Proponer
Generar una recomendación, borrador o siguiente acción sin ejecutarla.
Escribir / ejecutar
Modificar registros, enviar comunicaciones, realizar pagos o ejecutar acciones con efectos reales.
Una arquitectura puede conceder bastante libertad en lectura y propuesta y mantener la escritura bajo reglas o aprobación.
Cuatro ejemplos donde la frontera se ve mejor
1. Clasificar y enrutar correo
Si existen categorías estables, un modelo puede leer el mensaje y devolver «factura», «incidencia», «documentación» o «comercial». El workflow decide qué ruta corresponde.
No hace falta un agente para eso.
Empieza a tener sentido cuando una solicitud exige consultar varias fuentes, averiguar qué falta y decidir sucesivamente qué hacer antes de poder clasificar el caso como resuelto.
2. Procesar un pedido
Un pedido extraído de un documento puede seguir una secuencia controlada: validar cliente, resolver productos, comprobar reglas y crear borrador en ERP.
La IA puede ayudar a leer el documento sin gobernar la operación.
Si el pedido llega dentro de una conversación ambigua, contiene referencias poco claras y obliga a consultar pedidos anteriores o documentación antes de saber qué preguntar, una subtarea agentic puede aportar más.
3. Investigar y preparar una decisión
«Revisa estos proveedores, consulta condiciones, compara requisitos, detecta huecos y prepara una recomendación» no tiene necesariamente una secuencia fija.
El sistema puede necesitar decidir qué fuente consultar, qué evidencia falta y cuándo dispone de información suficiente.
Ese problema se parece más a un agente. La contratación o la orden de compra pueden seguir fuera de su autonomía.
4. Atención al cliente
Preguntas frecuentes y operaciones simples pueden funcionar con routing y workflows conocidos.
Una incidencia que mezcla facturación, estado de pedido y condiciones contractuales puede requerir consultar varias herramientas en un orden que depende de cada respuesta.
La diferencia vuelve a ser la misma: si podemos diseñar la ruta antes de recibir el caso, probablemente seguimos en workflow; si debemos descubrirla mientras trabajamos, aumenta el valor de un agente.
Ejemplo práctico recurrente: email, CRM y ERP
Imaginemos una empresa B2B ficticia con una bandeja compartida, CRM y ERP.
Entran solicitudes por email. Una IA clasifica intención y extrae cliente, referencia y datos básicos. El workflow decide la ruta inicial.
Los casos normales siguen reglas conocidas.
Una solicitud ambigua no encaja: hay que consultar el CRM, revisar un contrato y localizar documentación previa para saber si falta información.
En ese punto, el workflow entrega la subtarea a un agente con herramientas únicamente de lectura. El agente consulta las fuentes autorizadas, reúne evidencia y devuelve una propuesta estructurada.
El workflow recupera el control, valida formato y permisos. Si la acción posterior implica una escritura sensible en ERP, aplica el control correspondiente antes de ejecutarla.
La solución utiliza IA en varios puntos, pero no convierte todo el proceso en un agente.
Matriz de decisión: qué arquitectura encaja mejor
No existe una puntuación universal. Las variables sirven para discutir la arquitectura con el proceso real delante.
| Variable | Workflow determinista | Workflow + IA | Agente | Híbrido |
|---|---|---|---|---|
| Ruta | Predefinida. | Predefinida. | Puede cambiar según contexto. | Control general fijo, tramo variable. |
| Entrada ambigua | Baja tolerancia. | Buena si la ambigüedad es local. | Alta cuando exige investigación. | Alta en el tramo delegado. |
| Herramientas | Invocadas por reglas. | Invocadas por reglas o resultados acotados. | El modelo puede elegir entre herramientas permitidas. | El workflow define cuándo puede elegir. |
| Orden de pasos | Conocido. | Conocido. | Puede variar. | Variable solo donde aporta. |
| Facilidad de prueba | Alta en rutas conocidas. | Alta, añadiendo evaluación de pasos IA. | Requiere evaluar recorridos y herramientas. | Permite aislar el tramo más variable. |
| Latencia | Más previsible. | Algo más variable. | Puede crecer por iteraciones. | Variable en la subtarea agentic. |
| Coste | Más fácil de estimar. | Añade llamadas concretas a modelo. | Puede variar por número de turnos/herramientas. | Acota el coste agentic a una parte. |
| Riesgo | Fácil de limitar por reglas. | Controlado si la IA no ejecuta consecuencias críticas. | Necesita permisos, límites y verificación fuertes. | Permite separar exploración de acción sensible. |
| Buen encaje | Procesos estables y explícitos. | Ambigüedad localizada. | Problemas abiertos y rutas difíciles de predecir. | Procesos con zonas estables y zonas ambiguas. |
Cuándo no usar un agente
- Cuando las reglas son claras y estables.
- Cuando el error puede tener impacto alto y no existe una verificación fiable.
- Cuando el volumen hace que cada iteración adicional tenga un coste significativo y no aporta valor.
- Cuando la operación debe ser exacta y repetible.
- Cuando el proceso todavía no está definido.
- Cuando el problema real es una mala integración o una mala calidad de datos.
- Cuando unas pocas excepciones pueden resolverse mejor con una cola humana sencilla.
Tampoco conviene utilizar un agente porque el término resulte comercialmente atractivo.
Y cuándo un workflow demasiado rígido empieza a ser el problema
El extremo contrario también existe.
Un workflow puede degradarse cuando acumula cientos de reglas para interpretar situaciones que dependen del contexto, cuando las ramas crecen cada semana o cuando la mayoría de los casos terminan igualmente en revisión manual.
En ese punto puede tener sentido sustituir reglas de interpretación por IA acotada o introducir una subtarea agentic.
La arquitectura correcta no se obtiene defendiendo una tecnología. Se obtiene comparando mantenibilidad, riesgo, flexibilidad y capacidad de verificar el resultado.
Antes de producción: probar el recorrido, no solo la respuesta final
Una demo suele enseñar un caso limpio. Producción contiene entradas incompletas, contradicciones, herramientas caídas, datos inexistentes y usuarios que hacen preguntas inesperadas.
La evaluación debe reflejarlo.
- Preparar casos representativos. Normales, ambiguos, incompletos, contradictorios y casos límite.
- Probar rutas de workflow. Condiciones, ramas, reintentos y errores.
- Evaluar pasos con IA. Clasificación, extracción o generación con salidas esperadas.
- Evaluar agentes por recorrido. Herramientas elegidas, argumentos, orden de acciones y capacidad de detenerse.
- Registrar trazas. Sin observabilidad, un fallo variable es difícil de reproducir.
- Medir latencia y coste. Especialmente distribución y casos extremos.
- Medir escalados e intervenciones. Cuándo necesita ayuda y por qué.
- Comprobar acciones sensibles. Qué puede leer, proponer y escribir.
- Revisar permisos y credenciales y prompt injection. Especialmente cuando consume contenido externo.
- Comparar contra una arquitectura más simple. Si el agente no aporta suficiente mejora, no hay razón para mantener la complejidad.
Una buena arquitectura no maximiza autonomía: coloca la decisión donde mejor puede controlarse
Los agentes permiten resolver problemas que serían difíciles de representar con reglas rígidas. Esa capacidad es útil precisamente porque introduce flexibilidad.
Pero la flexibilidad no es un objetivo por sí misma.
Hay procesos donde una condición explícita es mejor que una inferencia. Hay tareas donde un modelo aporta muchísimo interpretando información sin necesidad de controlar el flujo. Y hay problemas donde la ruta solo puede descubrirse mientras el sistema consulta herramientas y observa resultados.
Por eso la decisión rara vez debería ser «workflow o agente» en abstracto.
La arquitectura se diseña paso a paso:
Qué podemos expresar como regla. Qué ambigüedad puede resolver la IA de forma acotada. Qué parte realmente necesita elegir cómo continuar. Qué acciones deben seguir bajo controles estrictos. Y qué necesita una persona.
Más autonomía no significa mejor automatización. La mejor solución es la que utiliza el grado de autonomía que el proceso puede justificar, controlar y medir.
¿Tu proceso necesita reglas, IA dentro del workflow, un agente o una combinación?
Podemos mapear decisiones, excepciones, herramientas, riesgo, verificabilidad, volumen y coste para definir qué nivel de autonomía aporta valor y dónde conviene mantener control explícito.
Revisar la arquitectura del procesoFuentes
- Anthropic — Building effective agents.
Referencia primaria para distinguir workflows con rutas predefinidas de agentes donde el modelo dirige su proceso y uso de herramientas, así como para el principio de empezar por soluciones simples y aumentar complejidad solo cuando aporta valor.
Consultar fuente - Anthropic — Trustworthy agents in practice.
Referencia sobre autonomía, supervisión, riesgos y gobernanza de agentes en entornos reales.
Consultar fuente - Anthropic — Mitigating the risk of prompt injections in browser use.
Referencia primaria sobre prompt injection como riesgo derivado de instrucciones maliciosas insertadas en contenido que un agente procesa.
Consultar fuente - OpenAI — A practical guide to building agents.
Referencia primaria sobre qué caracteriza a un agente, cuándo tiene sentido construirlo, herramientas, instrucciones, guardrails y necesidad de intervención humana en acciones sensibles.
Consultar fuente - OpenAI Agents SDK — Agents.
Documentación técnica sobre agentes configurados con instrucciones, herramientas, guardrails y comportamiento de ejecución.
Consultar fuente - OpenAI Agents SDK — Guardrails.
Documentación técnica sobre validaciones de entrada, salida y uso de herramientas, así como puntos de bloqueo y control.
Consultar fuente - OpenAI Agents SDK — Tracing.
Documentación técnica sobre trazas de ejecuciones, generaciones, llamadas a herramientas, handoffs, guardrails y otros eventos de un flujo agentic.
Consultar fuente
La frontera entre workflow, workflow con IA, agente y arquitectura híbrida depende del grado real de control que tenga el modelo sobre la ejecución. Los nombres comerciales de productos o plataformas no garantizan por sí solos una arquitectura determinada.
