Workflows vs Agents
La pregunta es quién decide la continuación
En sistemas AI, un workflow coordina pasos de procesamiento mediante una estructura de control definida sustancialmente por software, configuración u orquestación explícita. Puede organizar una secuencia, ramas, concurrencia o repetición. Es una definición de trabajo del Atlas; no limita workflow a un grafo acíclico ni exige que todos sus pasos produzcan resultados deterministas.
agents conserva la definición general de agente: un sistema que selecciona acciones e incorpora observaciones hacia un objetivo acotado. Aquí interesa la distribución del control. Un workflow fija más decisiones de continuación externamente; una ejecución agentic delega más selección significativa de próximos pasos al modelo y al runtime. La frontera admite combinaciones y depende del nivel observado.
El contraste aparece en Building effective agents, donde Anthropic distingue caminos predefinidos de dirección dinámica por LLMs. El Atlas utiliza esa intuición sin convertirla en clasificación universal. Un objeto llamado Agent por un SDK puede participar en un workflow fijo; su nombre de clase no demuestra cuánto control fue delegado.
Control de flujo y contenido son dimensiones diferentes
Un workflow puede pedir a un LLM un resumen, clasificar una entrada, recuperar contexto, llamar herramientas y esperar una decisión humana. Si sus reglas determinan qué viene después, sigue teniendo orquestación predefinida. El contenido generado puede variar entre ejecuciones aunque el recorrido seleccionado obedezca las mismas reglas.
Por ejemplo, recibir un documento, extraer campos, comprobar un schema y enviarlo a revisión puede ser un workflow. La extracción puede utilizar un modelo; la validación puede aplicar reglas programadas; la decisión humana puede cambiar el resultado. Ni la incertidumbre de la extracción ni esa intervención convierten automáticamente al conjunto en un agente autónomo.
También existen workflows sin AI: compilar, ejecutar tests y empaquetar un artefacto siguiendo dependencias declaradas. La estructura secuencial o condicional no es una invención de los sistemas agentic. Agregar una llamada a un modelo introduce una capacidad y nuevos límites, sin borrar los compromisos de control que ya estaban definidos.
La documentación de Sequential workflow en Google ADK distingue el orden de ejecución programado de si los componentes internos usan modelos. Es un ejemplo de implementación, no una obligación de utilizar sus clases. Reproducir el orden tampoco garantiza reproducir entradas, servicios externos o decisiones generadas.
Qué selección recibe el agente
Una investigación de código puede requerir decidir qué archivo leer, qué hipótesis probar y cuándo cambiar de dirección. Delegar esas decisiones permite adaptar el recorrido a observaciones que no estaban enumeradas de antemano. No requiere declarar un plan explícito ni disponer de un gran conjunto de herramientas para que exista selección significativa durante la ejecución.
Esa libertad es acotada. El agente puede operar dentro de políticas, permisos, un grafo, presupuestos, límites de herramientas y stop conditions. «Agent» no significa ausencia de control de flujo. Significa que parte del control se elige durante el trabajo, no que el sistema pueda redefinir sus autorizaciones o ignorar un resultado solicitado.
En Commerce, se puede encargar investigar por qué falló una exportación CSV de Orders. El agente decide si inspeccionar serialización, autorización o datos de entrada según lo que encuentra. Aun así, puede tener prohibido modificar reglas de acceso o instalar dependencias. Elegir pasos dentro del encargo no concede libertad para ampliar el encargo.
Ni varios mensajes ni múltiples llamadas a un LLM prueban esa delegación. Una cadena fija que genera outline, borrador y revisión puede ejecutar tres inferencias sin que ninguna decida la estructura del proceso. Tampoco tener terminal demuestra agencia: un programa puede ejecutar siempre la misma comprobación después de recibir la misma clase de entrada.
Sistemas híbridos: workflow que contiene un agente
Consideremos un recorrido ilustrativo: issue → clasificación → coding-agent → tests → revisión humana. El workflow decide las etapas y los gates. El agente recibe una tarea delimitada en una de ellas y elige su investigación o implementación. La estructura global y la selección interna responden a preguntas diferentes; ambas descripciones pueden ser correctas a la vez.
Para agregar CSV export a Orders, la preparación puede comprobar el checkout y registrar criterios de aceptación. El agente explora el código y propone cambios. Una etapa programada ejecuta las comprobaciones acordadas, y una persona revisa alcance y comportamiento. El resultado de una etapa debe comunicar suficiente información para decidir si la siguiente puede comenzar.
El workflow puede detener el avance ante tests fallidos sin dictar cómo investigarlos. También puede devolver feedback al agente dentro de un presupuesto. Ese ciclo no elimina el control externo: continúan definidos el objetivo, la evidencia requerida y las condiciones para pedir intervención. Volver a intentar no constituye por sí solo una política de recuperación suficiente.
Una afirmación de completion del agente no debe sustituir el gate que verifica el artefacto. Si la tarea produjo cambios fuera del alcance o no pudo ejecutar las pruebas, esa condición debe mantenerse visible. El proceso puede admitir resultados parciales y revisión; no necesita fingir que toda ejecución termina en integración automática.
Sistemas híbridos: agente que invoca workflows
La composición también ocurre en sentido inverso. Tras explorar un repositorio, un coding agent puede elegir entre recorridos predefinidos de investigación de bugs, actualización de dependencias o migración. La selección puede ser dinámica mientras las obligaciones dentro de cada recorrido permanecen explícitas. Invocar un workflow no convierte todo su interior en selección libre del agente.
En Orders, descubrir que la exportación ya existe pero usa un contrato obsoleto puede justificar un recorrido de cambio de integración. Descubrir que el problema es solo documentación conduce a otro alcance. Esa decisión necesita evidencia y autoridad suficientes; no debe basarse únicamente en similitud superficial entre nombres de tareas.
Un router programado también puede seleccionar el mismo recorrido mediante reglas. En ese caso, la existencia de varias rutas no implica un agente router. Lo que cambia es cómo se obtiene la decisión, qué entradas utiliza y quién conserva el control posterior. agentic-workflow-patterns desarrolla Routing como estructura, con implementaciones AI y convencionales.
Las condiciones de entrada y salida siguen importando. Un recorrido que requiere tests de integración no se satisface porque el agente haya elegido correctamente su nombre. Debe poder comunicar qué cumplió y dónde se detuvo. La composición requiere contratos de trabajo, no solo conectar cajas que parecen compatibles en un diagrama.
Comparar sin construir una escala de madurez
La tabla expresa tendencias de diseño; no son garantías independientes de la implementación.
| Pregunta | Mayor control predefinido | Mayor selección agentic |
|---|---|---|
| ¿Quién determina el siguiente paso? | Reglas y dependencias declaradas. | El agente selecciona dentro de límites. |
| ¿Dónde varía la ejecución? | Datos, decisiones de cada paso y ramas previstas. | También puede variar el recorrido de investigación o acción. |
| ¿Qué facilita revisar? | Etapas y condiciones explícitas. | Observaciones y razones operativas de la selección realizada. |
| ¿Qué necesita verificarse? | Implementación del workflow y resultados de sus pasos. | También decisiones dinámicas, alcance y resultados de sus acciones. |
Workflow → Agent → Multi-Agent no es una progresión obligatoria hacia mejor ingeniería. Una tarea con estructura conocida puede beneficiarse de un flujo sencillo. Delegar pasos que ya estaban definidos agrega incertidumbre sin resolver necesariamente otro problema. Un agente único puede bastar para una tarea que parece divisible en roles especializados.
Tampoco toda división entre componentes implica varios agentes. Un clasificador, un compilador y un generador de texto pueden colaborar sin autonomía de tareas separadas. A la inversa, varios agentes pueden ejecutar secuencialmente. El número de participantes, la concurrencia y la distribución de control son dimensiones que conviene examinar por separado.
Beneficios y límites del control explícito
Un flujo declarado facilita localizar etapas, identificar gates y discutir fallos esperados. Puede acotar llamadas, tiempo y caminos de recuperación. Esas ventajas dependen de su diseño: un workflow grande y poco observable también puede resultar difícil de depurar. Previsibilidad estructural no equivale a garantía de calidad de cada salida.
En la exportación CSV, una secuencia conocida puede validar permisos, obtener datos y producir un archivo. Dejar esas reglas explícitas ayuda a conservar contratos. Pedir a un modelo que decida si debe respetar autorización sería una delegación distinta y posiblemente inapropiada. La elección útil distingue generación de contenido de obligaciones que deben cumplirse siempre.
La rigidez también cuesta. Un workflow puede necesitar revisiones frecuentes si las tareas reales no encajan en sus rutas, o perder información al forzar resultados heterogéneos en una interfaz demasiado simple. Enumerar cada excepción no garantiza que se hayan entendido las variaciones importantes. Conviene observar qué queda fuera antes de añadir más ramas.
Un presupuesto de etapas ayuda a estimar trabajo, pero los tiempos externos y las decisiones humanas pueden variar. Reproducibilidad exige además controlar condiciones pertinentes, datos y dependencias. Reejecutar el mismo grafo con un modelo o repositorio distinto no constituye una repetición equivalente aunque las cajas conserven sus nombres.
Beneficios y límites de la adaptación
La selección agentic puede aportar exploración flexible cuando no se conoce la secuencia útil de antemano. Permite descubrir una dependencia inesperada o ajustar una hipótesis a una salida concreta. No garantiza elegir bien: puede ignorar información, seguir una pista débil o ampliar el alcance sin que ese cambio sea evidente.
La variación del recorrido introduce más necesidades de verificación y diagnóstico. Importa saber qué se intentó, qué resultado cambió la decisión y por qué se detuvo. No se exige desarrollar aquí Agent Tracing para reconocer esa necesidad. Una explicación retrospectiva debe contrastarse con acciones y resultados observables, no aceptarse como prueba suficiente.
El costo puede variar por duración, llamadas y uso de herramientas. Delegar más pasos no promete menos latencia, y dividir el trabajo puede introducir coordinación y síntesis. La documentación de multi-agent en OpenAI diferencia tareas independientes de pasos cortos o dependientes que conviene mantener juntos. Es orientación situada, no una receta universal.
Heurística de selección y errores frecuentes
Preguntar primero cuánto de la estructura ya se conoce. Si las transiciones y obligaciones están claras, un workflow explícito puede bastar. Si progresar requiere seleccionar acciones según hallazgos difíciles de anticipar, considerar delegar esa parte. La decisión también depende del impacto de un error, la evidencia disponible y la capacidad de intervenir.
Después precisar la unidad de análisis: sistema completo, etapa de investigación o componente que toma una decisión. Un mismo sistema puede ser un workflow global con ejecución agentic interna. Describirlo en ambos niveles evita discutir etiquetas mientras se dejan sin aclarar autoridad, resultado esperado y condiciones de avance.
Evitar equivalencias falsas: workflow no significa determinismo total ni incapacidad de usar herramientas; agente no significa libertad sin estructura o planificación obligatoria. Una cadena de LLMs no equivale automáticamente a agencia, y varios agentes no definen por sí solos un workflow bien diseñado. Ninguna etiqueta exime de comprobar el resultado de ingeniería.
Relaciones y fuentes
agentic-workflow-patterns organiza las formas recurrentes de secuencia, selección, concurrencia, delegación y feedback. coding-agent especializa su aplicación a desarrollo, y ai-assisted-software-engineering ofrece rutas de lectura. planning, agent-harness, multi-agent-coordination y agent-permissions-and-approval-boundaries conservan sus responsabilidades generales, sin convertir esta frontera de control en una arquitectura obligatoria.
Fuentes primarias consultadas el 2026-10-25. Definiciones de trabajo, tabla y ejemplos de Orders son síntesis del Atlas, no una clasificación normativa de proveedores.
- Anthropic: Building effective agents, distinción de control de flujo; artículo de 2024 con advertencia actual sobre evolución del tooling.
- OpenAI: Orchestration and handoffs, propiedad de la conversación y coordinación, y Multi-agent, alcance de delegación.
- Google ADK: Sequential workflow, ejemplo de separación entre orden programado y componentes que usan AI; no recomendación de framework.