Agentes de IA vs. workflows: cuándo usar cada arquitectura
Un marco práctico para decidir entre workflows deterministas y agentes autónomos según estructura de tarea, confiabilidad, costo, latencia y control.
La mayoría de los equipos no necesita empezar construyendo un agente.
Necesita un sistema confiable que pueda usar un modelo, llamar algunas herramientas y completar una tarea acotada sin introducir incertidumbre innecesaria.
Esa distinción importa porque la palabra agente se usa cada vez más para casi cualquier aplicación que combina un LLM con herramientas. Pero desde el punto de vista de arquitectura hay una diferencia importante entre un workflow y un agente.
Un workflow sigue una ruta que el código define en gran medida de antemano. El modelo puede clasificar, generar, extraer información o elegir entre opciones limitadas, pero la aplicación conserva el control de la secuencia.
Un agente recibe más autoridad sobre esa secuencia. Puede observar el estado actual, decidir qué hacer después, seleccionar herramientas, repetir pasos, recuperarse de errores y detenerse cuando considera que el objetivo está completo.
Anthropic plantea una distinción similar: los workflows siguen rutas de orquestación predefinidas, mientras que los agentes dirigen dinámicamente sus procesos y el uso de herramientas. La documentación de agentes de OpenAI también gira alrededor de un loop iterativo de decisiones del modelo, ejecución de herramientas, estado y condiciones de terminación.
La pregunta práctica no es cuál arquitectura suena más avanzada. Es cuánta autoridad de decisión necesita realmente el modelo.
La escalera de arquitectura
Conviene pensar estos sistemas como una escalera de autonomía creciente.
- Una sola llamada al modelo — una entrada, una salida.
- Workflow determinista — pasos fijos con llamadas al modelo dentro de ellos.
- Workflow dinámico — parte del routing o la descomposición depende del modelo, pero el código sigue imponiendo la estructura.
- Agente — el modelo decide repetidamente la siguiente acción hasta alcanzar un objetivo, encontrar un bloqueo o activar una condición de parada.
Cada nivel puede aumentar la flexibilidad. También puede aumentar latencia, costo, requisitos de observabilidad y cantidad de modos de falla.
Por eso la estrategia por defecto debería ser sencilla: empieza en el nivel más bajo que resuelva la tarea de forma confiable.
Cuándo conviene usar un workflow
Usa un workflow cuando la tarea se conoce en gran medida antes de empezar la ejecución.
Un ejemplo claro es el procesamiento de documentos:
- clasificar el documento;
- extraer campos requeridos;
- validar el resultado;
- enviar excepciones a revisión;
- guardar el resultado.
El modelo puede ser útil en varias etapas, pero la aplicación ya conoce cuáles son esas etapas.
Los workflows son especialmente adecuados cuando necesitas:
- rutas de ejecución predecibles;
- latencia relativamente consistente;
- costo acotado;
- validaciones explícitas entre pasos;
- trazabilidad fuerte;
- reintentos fáciles de razonar;
- estados de error bien definidos.
Varios patrones útiles pertenecen a esta categoría.
Prompt chaining
Una llamada al modelo produce un resultado intermedio que se usa como entrada del siguiente paso. Funciona bien cuando una tarea compleja puede descomponerse con claridad y cada etapa se puede validar por separado.
Routing
Un clasificador elige entre caminos conocidos. En soporte al cliente, por ejemplo, facturación, acceso a cuenta, errores técnicos y reportes de abuso pueden enviarse a flujos distintos.
Paralelización
Varias subtareas independientes se ejecutan al mismo tiempo y después se combinan. Es útil cuando cada parte puede resolverse sin depender de los resultados intermedios de las demás.
Evaluator-optimizer
Un modelo genera una respuesta y otro la evalúa contra criterios explícitos. El loop puede continuar hasta alcanzar un umbral de calidad o un máximo de intentos.
Estos patrones pueden ser sofisticados, pero siguen siendo workflows porque la aplicación conserva la estructura de operación.
Cuándo sí se justifica un agente
Un agente empieza a tener sentido cuando los pasos importantes no pueden especificarse completamente antes de ejecutar la tarea.
Piensa en una tarea de programación como esta:
Encuentra la causa raíz de esta regresión en producción, aplica el cambio seguro más pequeño, ejecuta las pruebas relevantes y explica qué cambió.
El sistema puede necesitar:
- inspeccionar archivos distintos según lo que encuentre;
- buscar logs;
- decidir qué pruebas ejecutar;
- revisar su hipótesis después de que una prueba falle;
- editar uno o varios archivos;
- detenerse y pedir aprobación antes de una acción sensible.
La ruta exacta no se conoce al inicio. Un workflow fijo puede intentar programar todas las ramas posibles, pero llega un punto donde ese workflow se convierte en una imitación manual del proceso de decisión que el propio modelo podría ejecutar.
Los agentes tienen mejor encaje cuando la tarea presenta cuatro características:
- El objetivo está claro, pero la ruta no.
- El entorno puede devolver feedback después de cada acción.
- El modelo dispone de herramientas útiles para inspeccionar o modificar ese entorno.
- La aplicación puede imponer límites duros sobre lo que el agente tiene permitido hacer.
Ese último punto es crítico. Autonomía sin límites no es una ventaja arquitectónica; es un riesgo operacional.
Tabla práctica de decisión
| Pregunta | Prefiere workflow | Prefiere agente |
|---|---|---|
| ¿Los pasos se conocen de antemano? | Normalmente sí | Normalmente no |
| ¿El modelo debe elegir repetidamente la siguiente acción? | Pocas veces | Sí |
| ¿Importa mucho una latencia predecible? | Buen encaje | Más difícil |
| ¿El costo por ejecución debe estar fuertemente limitado? | Más fácil | Más difícil |
| ¿El entorno puede devolver feedback útil tras cada acción? | Ayuda | Esencial |
| ¿Necesitas alta reproducibilidad? | Buen encaje | Requiere más controles |
| ¿Puedes contener fallos con permisos y stop conditions? | Sigue siendo importante | Obligatorio |
| ¿La tarea cambia mucho entre casos? | Puede volverse frágil | Mejor encaje |
El costo oculto de usar agentes cuando no hacen falta
El error más común no es elegir un workflow cuando un agente habría sido mejor. Es construir un agente cuando un workflow ya resolvía el problema.
Los agentes agregan necesidades de ingeniería adicionales:
- permisos de herramientas;
- manejo de estado;
- terminación del loop;
- política de reintentos;
- checkpoints de aprobación;
- tracing;
- evaluación de trayectorias de varios pasos;
- recuperación cuando algunas acciones intermedias sí tuvieron efecto y otras no.
Una sola llamada al modelo puede evaluarse comparando entrada y salida. Un agente de múltiples pasos debe evaluarse muchas veces como una trayectoria completa: qué observó, qué decidió, qué herramientas llamó, qué cambió en el entorno y si el estado final realmente es correcto.
Por eso la confiabilidad de agentes no es únicamente un problema de calidad del modelo. Es un problema de sistemas.
La arquitectura híbrida suele ser la correcta
La decisión no es binaria.
Un sistema de producción sólido suele usar un workflow determinista alrededor de un agente acotado.
Por ejemplo:
- validar la solicitud;
- clasificar el riesgo;
- crear un sandbox;
- dejar que un agente resuelva la tarea dentro de ese sandbox;
- ejecutar validaciones deterministas;
- exigir aprobación para acciones sensibles;
- persistir el resultado y el audit trail.
El workflow controla los límites del sistema. El agente se ocupa de la parte donde la ruta es realmente dinámica.
Así se conserva la autonomía donde produce valor sin entregar al modelo autoridad innecesaria sobre todo lo que lo rodea.
Cinco preguntas antes de añadir un agent loop
Antes de implementar un agente, responde estas preguntas:
1. ¿Qué decisión no puedes programar de forma confiable con lógica normal de aplicación?
Si no puedes identificar esa decisión, probablemente no necesitas un agente.
2. ¿Qué ground truth puede observar el sistema después de cada acción?
Los agentes necesitan feedback. Pruebas, respuestas de APIs, estado de archivos, resultados de base de datos, estado del navegador y aprobaciones humanas pueden aportar evidencia real de progreso.
3. ¿Cuál es la autoridad máxima que necesita el agente?
No expongas diez herramientas si la tarea necesita tres. No concedas escritura cuando lectura es suficiente. No permitas acciones irreversibles sin un checkpoint.
4. ¿Cómo termina la ejecución?
Define condiciones de éxito, límites de iteraciones, límites de presupuesto, timeouts y rutas de escalamiento antes de producción.
5. ¿Cómo vas a evaluar la trayectoria?
No midas sólo la respuesta final. Registra selección de herramientas, pasos innecesarios, reintentos, latencia, tokens, costo, intervenciones humanas y cumplimiento real de la tarea.
La regla de diseño
Los workflows optimizan control.
Los agentes optimizan adaptabilidad.
La mayoría de los sistemas de producción necesita ambos, pero no en la misma proporción.
Si la tarea tiene una ruta estable, codifica esa ruta. Si la tarea requiere descubrir el camino durante la ejecución, deja que el modelo tome las decisiones que realmente no pueden predeterminarse. Después rodea esa autonomía con validaciones deterministas, permisos, observabilidad y condiciones de parada.
El objetivo no es construir el sistema más agentic.
El objetivo es construir el sistema menos autónomo que pueda resolver de forma confiable el problema real.