Agentic Workflow Patterns

Estructuras de trabajo, no un inventario de agentes

Agentic Workflow Patterns es una agrupación editorial del Atlas para estructuras recurrentes que organizan llamadas a modelos, herramientas y agentes. Incluye secuencia, selección de rutas, concurrencia, descomposición, separación entre plan y ejecución y refinamiento por feedback. Algunas realizaciones son agentic; otras utilizan control convencional sin agentes autónomos. El nombre del grupo no convierte cada paso en un agente.

workflows-vs-agents conserva la distinción de control; agents define al sistema agente. Aquí examinamos cómo se organiza trabajo, no nuevas categorías de actores ni estilos arquitectónicos completos. Las familias pueden componerse. Se mantienen juntas para facilitar comparación sin exigir una página por cada variante o nombre informal utilizado en una herramienta.

Building effective agents organiza cinco familias de workflows: chaining, routing, parallelization, orchestrator-workers y evaluator-optimizer. El Atlas añade Planner–Executor como separación de responsabilidades que conviene contrastar con orquestación. Esta agrupación y sus generalizaciones a componentes convencionales son síntesis editorial, no una taxonomía única atribuida a Anthropic ni un estándar universal de seis patrones.

Sequential Pipeline / Prompt Chaining

Qué organiza y cómo fluye. El resultado de una etapa alimenta otra posterior mediante una secuencia explícita. Las etapas pueden producir artefactos intermedios y tener gates de validación. Prompt Chaining es el caso centrado en encadenar llamadas a modelos; Sequential Pipeline también puede incluir transformaciones programadas, herramientas o decisiones humanas entre esas llamadas.

Cuándo resulta útil. Cuando se conocen responsabilidades sucesivas y cada una puede recibir entradas suficientes. Idea → outline → draft → review es una ilustración textual de producción de un artículo. Puede ejecutarse con el mismo modelo varias veces, modelos distintos o pasos convencionales. La secuencia no concede por sí misma autonomía sobre la tarea.

En Commerce, analizar el contrato de CSV export de Orders, proponer una solución, implementar y comprobar puede organizar un recorrido. Que esas fases estén declaradas no obliga a delegarlas a agentes distintos. Un script puede ejecutar checks conocidos y un coding-agent puede ocupar solo la fase que necesita investigar o modificar el repositorio.

Trade-offs. Separar etapas facilita examinar artefactos y localizar fallos. También acumula latencia y transfiere información entre contratos que pueden resultar insuficientes. Si la extracción inicial omite una restricción de autorización, las etapas siguientes pueden desarrollar una solución coherente con una premisa equivocada. Validar formato no descubre necesariamente ese error semántico.

Qué no implica. Una cadena de prompts no es automáticamente multi-agent ni una metodología de desarrollo. Specification-Assisted Development puede organizarse como workflow sin que el patrón prescriba SDD o agentes. pipe-and-filter conserva su alcance arquitectónico más amplio; la semejanza de composición no convierte esta secuencia de ejecución AI en una definición nueva de aquel estilo.

Routing

Qué organiza y cómo fluye. Selecciona uno o varios destinos según entrada y estado: una ruta, modelo, agente, herramienta o workflow. Puede implementarse mediante reglas, if/else, clasificación, similitud de embeddings, un LLM o un agente. La decisión relevante es la selección; no exige razonamiento autónomo ni que todos los destinos sean del mismo tipo.

Cuándo resulta útil. Cuando existen categorías con tratamientos diferentes y puede identificarse una ruta adecuada. Una petición de soporte puede ir a billing, technical support o returns. En desarrollo, una solicitud puede corresponder a bug, feature, documentación o dependencia. Las categorías necesitan criterios y un tratamiento de los casos ambiguos, no solo nombres de especialistas.

En CSV export, una regla puede separar cambios documentales de cambios de implementación mediante metadata explícita del issue. Si la descripción es ambigua, otro mecanismo puede ayudar a interpretarla. Elegir destino por una etiqueta programada no requiere un agente router. Model Routing, en Application Patterns, especializa la selección de modelo; Routing conserva aquí la elección más amplia de destinos.

Trade-offs. Puede concentrar contexto y capacidades en un tratamiento pertinente, pero una clasificación incorrecta envía el trabajo al lugar equivocado. Hay que observar la ruta seleccionada y conservar información suficiente para corregirla. Un número de confianza emitido por un LLM no es por sí mismo una probabilidad calibrada; no se recomienda un umbral universal para decidir cuándo automatizar.

Qué no implica. Routing no es toda orquestación ni transferencia obligatoria de propiedad. La documentación de OpenAI sobre orchestration y handoffs distingue un especialista que toma la conversación de otro invocado como capacidad por un manager. Esa diferencia de implementación importa, sin volver manager, handoff y selección de ruta sinónimos universales.

Parallelization / Fan-out–Fan-in

Qué organiza y cómo fluye. Distribuye trabajo independiente o parcialmente independiente para ejecutarlo concurrentemente y reúne resultados. Fan-out describe el despacho; fan-in, la agregación. Sectioning divide una tarea en partes; voting o varias perspectivas repite intentos y combina sus resultados. Son formas relacionadas, no garantías de independencia estadística ni acuerdo correcto.

Cuándo resulta útil. Cuando hay independencia aprovechable o perspectivas complementarias cuya combinación aporta evidencia. Las ramas pueden ser funciones, llamadas al mismo modelo o agentes con instrucciones diferentes. El ejemplo de Parallel workflow de Google ADK separa scheduling programado de componentes internos y hace explícita la necesidad de gestionar estado e intercambio.

En CSV export, revisar documentación de formato y explorar casos de autorización puede hacerse en paralelo mientras no dependan de un contrato todavía desconocido. Implementar backend y tests que asumen contratos distintos introduce otro problema. Antes de separar trabajo, acordar qué información comparten y qué resultado debe reunirse para que el conjunto sea consistente.

Trade-offs. La concurrencia puede reducir latencia si existe capacidad disponible y los costos de coordinación no dominan. Añade llamadas, síntesis, posibles resultados parciales, trabajo duplicado y contención. Una rama lenta puede demorar el fan-in. Más respuestas similares no constituyen corroboración independiente cuando todas repiten la misma premisa equivocada o contexto insuficiente.

Qué no implica. Varias llamadas paralelas no son automáticamente Parallel Agent Execution ni Multi-Agent Coordination; varios agentes pueden ejecutar secuencialmente. Tampoco hace falta un synthesis agent: puede combinar una función, un LLM, un coordinador o una persona. workspace-isolation-for-coding-agents trata separación de copias y estado de trabajo, sin equivaler a seguridad de sandbox.

Orchestrator–Workers

Qué organiza y cómo fluye. Un coordinador determina subtareas durante la ejecución, distribuye trabajo y reúne resultados. El contraste con paralelización estática es que la descomposición puede depender de la entrada y de los hallazgos. La coordinación puede incluir seguimiento, reasignación y síntesis, sin que toda realización deba implementar todas esas funciones.

Cuándo resulta útil. Cuando la tarea global está acotada pero las piezas necesarias no pueden enumerarse suficientemente de antemano. Un worker puede realizarse mediante una llamada a modelo, herramienta, workflow o agente especializado. Esta ampliación del Atlas distingue el rol funcional de las realizaciones con worker LLMs descritas por Anthropic; no requiere procesos o modelos separados.

En Orders, la exploración puede revelar cambios en consulta, autorización y documentación para CSV export. El coordinador divide entonces esas responsabilidades y conserva los compromisos compartidos del formato. Si descubre que la implementación ya existe y solo falta ajustar una política, debería cambiar la distribución, no ejecutar igualmente todas las subtareas porque sus nombres parezcan parte del patrón.

Trade-offs. La adaptación puede evitar una descomposición rígida, pero un error del coordinador afecta a varias ramas. Concentrar todo el contexto, todas las decisiones y toda la síntesis crea presión y un posible cuello de botella. Los workers pueden recibir contexto acotado; eso ayuda a especializar y también puede ocultar restricciones globales. No se presupone memoria compartida global.

Qué no implica. Orquestar no es solo elegir destino, aunque pueda utilizar Routing. Tampoco obliga a que cada worker sea un subagent autónomo. Los términos de multi-agent de OpenAI corresponden a capacidades concretas de delegación y coordinación; son una posible implementación. agent-handoffs, subagents-and-delegation y multi-agent-coordination conservan sus hogares generales, sin duplicarse aquí.

Planner–Executor

Qué organiza y cómo fluye. Separa formular un plan, tareas o estrategia de realizar las acciones correspondientes. El plan es un artefacto de trabajo que informa ejecución; no certifica que el problema esté entendido. Puede producirlo una persona, una llamada al modelo, un agente o un procedimiento predefinido. Los ejecutores también admiten distintas realizaciones.

Cuándo resulta útil. Cuando explicitar decisiones previstas facilita revisar dependencias, restricciones o aceptación antes de actuar. Puede usarse el mismo modelo con responsabilidades o prompts distintos; no requiere dos modelos, un planner costoso ni executors baratos. Google ADK documenta planners que estructuran planificación antes de acciones: es un ejemplo particular, no la definición del patrón ni de Planning completo.

En CSV export, el plan puede fijar qué contrato conservar, qué partes necesitan investigación y qué evidencia buscar. La ejecución descubre quizá que el serializer usado por Orders pertenece a otra frontera. Esa observación exige revisar supuestos, replanificar o pedir intervención. Persistir con un plan obsoleto no preserva disciplina; conserva una interpretación que ya encontró evidencia contraria.

Trade-offs. La separación hace revisables ciertas decisiones y puede coordinar trabajo dependiente. Añade transferencia de contexto, mantenimiento del plan y la posibilidad de confundir una lista completa con una estrategia válida. El ejecutor necesita poder comunicar bloqueos y hallazgos. Un plan demasiado detallado puede volverse frágil; uno demasiado vago puede no orientar ninguna decisión útil.

Qué no implica. Planner–Executor enfatiza planificar frente a realizar. planning conserva la actividad general, sin implicar este patrón. Orchestrator–Workers enfatiza descomponer, delegar y reunir trabajo dinámicamente. Pueden combinarse: un planner propone pasos y un orchestrator los distribuye a workers. También puede existir un executor único que siga un plan sin delegación. No se usa Planner, Manager y Orchestrator como nombres intercambiables para toda responsabilidad.

Evaluator–Optimizer

Qué organiza y cómo fluye. Un componente produce o refina un candidato; otro aporta evaluación según criterios; el feedback orienta una nueva iteración. La realización con llamadas a LLMs es una posibilidad. En la generalización del Atlas, un evaluador también puede ser una regla, schema, compilador, test suite, análisis estático o persona. Los roles de evaluator y optimizer pueden implementarse sin dos agentes.

Cuándo resulta útil. Cuando los criterios aportan feedback suficientemente significativo para guiar una mejora y esta se puede observar. Una rúbrica de estilo, un requisito verificable o un test fallido orientan cambios diferentes. Loop workflow de Google ADK muestra repetición con terminación explícita; un loop por sí solo no garantiza mejora del candidato.

En Orders, un candidato puede cumplir columnas y formato CSV pero omitir una restricción de acceso. La evaluación necesita criterios que contemplen esa obligación. Generar otro candidato ante un fallo representativo puede ser útil; redefinir el test para que acepte la salida no demuestra resolver el requisito. Hay que revisar tanto la calidad de la evidencia como lo que se está optimizando.

Trade-offs. Una rúbrica incorrecta puede favorecer un objetivo equivocado; generador y crítico pueden compartir supuestos. «Se ve bien» no prueba corrección. Build, tipos, tests, análisis pertinente y revisión humana pueden ofrecer evidencia complementaria o más directa según la afirmación. Deben existir condiciones de detención: aceptación suficiente, presupuesto, máximo acordado, falta de progreso o escalamiento, sin defaults numéricos universales.

Qué no implica. Agent Evaluation estudia sistemáticamente comportamiento entre tareas y evidencias; este patrón organiza feedback durante una ejecución. Tampoco sustituye Generated Code Verification. Generator–Critic, Critic–Refiner, Reflection e Iterative Refinement pueden describir realizaciones vecinas, pero no se declaran universalmente idénticas. No requiere una relación adversarial ni promete que más rondas produzcan una respuesta mejor.

Comparación de estructuras

Tendencias conceptuales del Atlas; «dinámico» no significa necesariamente decidido por AI.

Patrón	Forma de control	Decisión dinámica	Paralelismo	¿Exige varios agentes?	Propósito típico
Sequential Pipeline / Prompt Chaining	Etapas dependientes	Puede existir dentro de etapas o gates	Solo partes independientes	No	Separar transformaciones sucesivas
Routing	Selección de caminos	Regla, clasificador, modelo o agente	Si selecciona varias rutas compatibles	No	Elegir tratamiento pertinente
Parallelization / Fan-out–Fan-in	Ramas y reunión	Despacho fijo o adaptativo	Es su foco	No	Concurrencia o perspectivas
Orchestrator–Workers	Descomposición y coordinación	La división puede adaptarse	Opcional según dependencias	No; puede usar agentes	Resolver partes descubiertas durante el trabajo
Planner–Executor	Plan y realización	Puede revisar el plan con feedback	Según lo que permita el plan	No	Separar decisiones previstas y acciones
Evaluator–Optimizer	Candidato, feedback y revisión	Según evaluación y detención	Opcional en candidatos o evaluación	No	Refinar frente a criterios

Escalamiento humano y efectos

Human Escalation atraviesa las familias: incertidumbre relevante, consecuencias, falta de capacidades o autorización pueden requerir intervención. No es un séptimo patrón obligatorio ni se limita a que un router declare baja confianza. El resultado debe conservar qué se intentó, qué decisión falta y qué evidencia puede usar la persona que continúa.

Una aprobación puede detener una etapa sin transferir toda la tarea. Un handoff puede transferir responsabilidad de respuesta bajo un runtime particular. Human in the Loop tiene su tratamiento general en Application Patterns; aquí basta evitar que el escalamiento se reduzca a un número de confianza o a la ficción de que siempre existe un destinatario disponible.

Si una etapa produce efectos externos, repetirla necesita considerar idempotency y las condiciones de retry. Volver a generar un borrador no tiene las mismas consecuencias que repetir una operación de negocio. El patrón de control no elimina incertidumbre sobre efectos; no se desarrolla aquí otro capítulo de sistemas distribuidos.

Composición ilustrativa y contratos

Como ejemplo composicional, una entrada puede pasar por router, planner, orchestrator, workers concurrentes, síntesis y evaluación, con feedback acotado. No es arquitectura recomendada por defecto. Cada componente debe tener una razón: si la tarea tiene un recorrido conocido, incorporar todos esos roles solo reproduce trabajo de coordinación y más puntos de fallo.

Los intercambios pueden ser texto, archivos, mensajes u objetos estructurados. Importan responsabilidades y condiciones de aceptación, no un formato global de memoria obligatorio. Para CSV export, un worker necesita saber qué columnas y reglas conservar, qué puede modificar y qué debe devolver. JSON válido o un archivo bien formado no garantizan que el contrato semántico esté satisfecho.

Elegir y justificar complejidad

Partir de estructura de tarea, incertidumbre, independencia, criterios de calidad, latencia, costo e impacto del fallo. Si una regla resuelve una selección con suficiente fiabilidad y bajo costo, un LLM puede ser innecesario; eso no constituye una prohibición universal de inferencia. Si basta un agente con herramientas y contexto adecuados, agregar especialistas necesita justificar su coordinación.

Cada etapa añade estado, transferencia de información, tiempo y modos de fallo. Una secuencia propaga errores iniciales; routing puede desviar; una rama puede fallar o retrasarse; un coordinador puede dividir mal; un crítico puede premiar el criterio equivocado. Observar ruta, etapa y razón de detención ayuda a diagnosticar sin materializar todavía Agent Tracing.

Más componentes y herramientas también amplían superficies de autoridad y confianza. Su análisis detallado pertenece a temas futuros, igual que AI Economics y evaluación entre tareas. No hay ganador universal ni jerarquía pipeline → agent → multi-agent. Elegir necesita evidencia sobre el trabajo real y conservar la alternativa más simple que satisfaga sus requisitos.

Relaciones y fuentes

ai-assisted-software-engineering ofrece navegación hacia estos conceptos generales de Agentic Systems. Los ejemplos de coding-agent no restringen las estructuras a programación. Graph Engineering, Loop Engineering y Diamond Pattern no se promueven a conceptos canónicos aquí: describir grafo, loop o geometría fan-out/fan-in no exige inventar otra identidad ni adoptar un framework.

Fuentes primarias consultadas el 2026-10-25. Las seis secciones, tabla, generalizaciones a componentes no agentic y Commerce son síntesis del Atlas. El resumen secundario del video aportado para la iteración orientó ejemplos y preguntas, sin convertirse en autoridad primaria ni atribución de origen.

• Anthropic: Building effective agents, familias de composición; artículo de 2024 cuyo inventario de tooling no se trata como actual.
• OpenAI: Orchestration and handoffs y Multi-agent, responsabilidades de coordinación y delegación.
• Google ADK: Sequential workflow, Parallel workflow, Loop workflow y planners en LlmAgent, ejemplos concretos, no requisitos del Atlas.