Patrones de diseño de arquitectura agéntica

Fuente: Google Cloud Architecture Center — “Choose a design pattern for your agentic AI system”.

Con los componentes básicos de un agente ya claros, la pregunta práctica es: ¿qué patrón de arquitectura usar para un problema específico? Fíjate en algo: en el Capítulo 6 ya construimos un flujo completo (la solicitud de vacaciones) con un solo agente manejando prompts, memoria, herramientas, y cierto grado de autonomía. Eso, sin que lo hubiéramos nombrado todavía, ya es un patrón específico — el más simple de todos. Vamos a irle poniendo nombre a lo que ya construimos, y a ver cuándo ese diseño deja de ser suficiente.

Antes de elegir un patrón: define tus requisitos

Cuatro preguntas orientadoras, aplicadas a nuestro propio caso de RR.HH.:

Características de la tarea: ¿nuestra solicitud de vacaciones se puede resolver en pasos predefinidos, o es abierta? En su forma simple, es bastante estructurada — no necesita razonamiento abierto tipo investigación.
Latencia y rendimiento: el empleado está esperando en vivo una respuesta — esto prioriza rapidez sobre exhaustividad.
Costo: ¿cuántas llamadas al modelo estamos dispuestos a pagar por cada solicitud, multiplicado por miles de empleados? (recordemos el trilema de inferencia de Parte III).
Involucramiento humano: ya establecimos que enviar la solicitud real requiere confirmación — una restricción de diseño no negociable, sin importar qué patrón elijamos.

Si tu carga de trabajo es predecible o se puede resolver con una sola llamada al modelo (resumir un documento, traducir texto, clasificar feedback), probablemente no necesitas una arquitectura agéntica — por ejemplo, “resume esta política de vacaciones en un párrafo” no necesitaría nada de lo que sigue.

Sistema de agente único

Usa un modelo, un conjunto definido de herramientas, y un prompt de sistema comprehensivo para manejar autónomamente una solicitud, confiando en las capacidades de razonamiento del modelo para interpretar la petición, planear pasos, y decidir qué herramientas usar. Esto es, exactamente, lo que armamos en el Capítulo 6: un agente, con un prompt, con acceso a tres herramientas, decidiendo por sí solo en qué orden consultarlas.

Si estás empezando en desarrollo de agentes, se recomienda comenzar aquí — permite refinar la lógica central, el prompt, y las definiciones de herramientas, antes de agregar complejidad arquitectónica.

Dónde este patrón empieza a quebrarse: el rendimiento se degrada con más herramientas y mayor complejidad de tareas. Imaginemos que el mismo asistente de RR.HH. también debe manejar reembolsos de gastos, horas extra, y quejas de acoso laboral — todo en el mismo agente, con el mismo prompt gigante tratando de cubrir reglas de cuatro dominios distintos. Un prompt que intenta ser experto en los cuatro simultáneamente va a ser peor en cada uno que cuatro prompts especializados por separado — y una queja de acoso laboral necesita un manejo de confidencialidad y escalamiento completamente distinto al de una solicitud de vacaciones, mezclados en el mismo flujo de decisión. Esto es precisamente el caso para el que existen los sistemas multi-agente.

Sistemas multi-agente: los patrones específicos

Un sistema multi-agente orquesta múltiples agentes especializados para resolver un problema complejo, descomponiendo un objetivo grande en sub-tareas asignadas a agentes dedicados. Un concepto central aquí es la ingeniería de contexto: gestionar qué información recibe cada agente especializado — aislando contexto por agente, persistiendo información entre pasos, o comprimiendo datos para mejorar eficiencia.

Patrón secuencial

Escenario: procesar un recibo de gastos. Un empleado sube un recibo con la nota “cena con cliente, $85”. Procesar esto tiene una secuencia natural y fija: extraer los datos del recibo → validar contra la política de gastos → aprobar y generar el registro de pago.

Recibo → [Agente Extractor] → datos estructurados
              ↓
       [Agente Validador] → ¿cumple política?
              ↓
       [Agente de Aprobación] → registro final para pago

El patrón secuencial ejecuta agentes especializados en un orden lineal y predefinido, donde la salida de uno es la entrada directa del siguiente — usando un agente de flujo de trabajo secuencial que opera con lógica predefinida, sin necesitar consultar a un modelo de IA para orquestar. El orden ya está decidido de antemano por diseño humano, no por una decisión del LLM en cada ejecución.

Separar en tres agentes especializados (en vez de uno haciendo todo) trae varias ganancias concretas, no solo “orden”: (1) costo — cada agente puede usar el modelo del tamaño que su tarea realmente necesita (el Extractor, una tarea de lectura simple, puede usar un modelo barato; el Validador, que razona sobre política vía RAG, necesita algo más capaz); pagar un modelo caro para las tres tareas cuando solo una lo necesita sería desperdiciar dinero en cada llamada. (2) accuracy — un prompt enfocado en una sola tarea, sin diluir atención entre dominios distintos, funciona mejor, y cada paso se puede evaluar y mejorar por separado (Capítulo 3) sin mezclar resultados. (3) menos falsos positivos — cada frontera entre agentes es un punto de control explícito donde se puede detectar una inconsistencia (ej. un monto de $8,500 marcado como sospechoso) antes de que se propague hasta la aprobación final.

Lo que no se gana es velocidad — de hecho, se pierde: cada agente es una llamada adicional, y la latencia total es aproximadamente la suma de las latencias individuales, no menos. Comparado con un agente único haciendo las tres cosas en una sola llamada, el secuencial es más lento de punta a punta. Esa ganancia de velocidad es, específicamente, lo que resuelve el siguiente patrón.

El trade-off de flexibilidad también es real: un recibo de $2,000 por un evento corporativo, que ameritaría una ruta de aprobación distinta, va a forzarse por el mismo Extractor → Validador → Aprobador que un recibo de$ 12 — el pipeline no puede saltarse pasos ni tomar rutas alternativas. Eso es exactamente lo que el patrón coordinador, más adelante, sí permite.

Patrón paralelo (concurrente)

Escenario: analizar comentarios de una encuesta de clima laboral. Un comentario llega en texto libre, y hace falta: detectar sentimiento, extraer palabras clave, categorizar por departamento, y detectar urgencia. Ninguna de estas cuatro tareas depende de las otras — todas leen el mismo texto original de forma independiente.

                    Comentario del empleado
                            │
        ┌──────────┬────────┴────────┬──────────┐
        ▼          ▼                 ▼          ▼
  [Sentimiento] [Palabras clave] [Categoría] [Urgencia]
        └──────────┴────────┬────────┴──────────┘
                            ▼
                    [Agente de síntesis]

El patrón paralelo despacha el mismo input a varios subagentes que trabajan al mismo tiempo, y sus resultados se sintetizan al final — usando, igual que el secuencial, un agente de flujo de trabajo fijo, sin consultar a un modelo de IA para orquestar.

Aquí sí se gana velocidad, y ahora podemos ser precisos sobre por qué: como los cuatro agentes corren simultáneamente, la latencia total es aproximadamente el máximo de las cuatro latencias individuales, no la suma. Con números ilustrativos: si cada agente tarda ~800ms, el secuencial tardaría ~3,200ms (uno tras otro); el paralelo tarda ~800ms en total. El costo que se paga a cambio: cuatro llamadas al modelo en vez de una, consumiendo más recursos totales, solo que repartidos en paralelo en vez de en serie — se gana en tiempo de reloj, no en costo total.

La complejidad nueva que introduce: el agente de síntesis final tiene que reconciliar resultados potencialmente contradictorios (¿qué pasa si “categoría” dice IT pero “sentimiento” detecta frustración tan alta que amerita también atención de cultura laboral?) — algo que no existe en el secuencial, donde no hay resultados paralelos compitiendo.

Útil específicamente cuando las sub-tareas son genuinamente independientes y la latencia total importa más que el costo total de cómputo.

Patrón de bucle (loop)

Escenario: seguimiento de onboarding de un empleado nuevo. Un agente revisa diariamente si el empleado completó su checklist (contrato, laptop, capacitación, datos bancarios), y si no, envía un recordatorio — hasta que todo esté listo, o hasta un máximo de días, en cuyo caso escala a un humano.

Día 1 → [Verificar checklist] → ¿completo? NO → [Enviar recordatorio] ─┐
Día 2 → [Verificar checklist] → ¿completo? NO → [Enviar recordatorio] ─┤
Día 3 → [Verificar checklist] → ¿completo? SÍ  → [Notificar a RR.HH.] ─┘

El patrón de bucle ejecuta repetidamente una secuencia de subagentes hasta cumplir una condición de salida (máximo de iteraciones, o un estado personalizado) — usando, otra vez, un agente de flujo de trabajo fijo, sin orquestación por IA. La condición de salida puede evaluarse en cualquier punto del flujo, no necesariamente al final.

La diferencia clave frente a secuencial y paralelo: la duración total es impredecible — el empleado podría completar todo el mismo día, o tardar una semana. Esto encaja naturalmente en el “mundo sensible al throughput” del trilema de inferencia (Parte III), no en el de latencia — es un proceso de fondo, asíncrono, como la “carga nocturna de leads” del caso de los 1,500 vendedores.

El riesgo real: si la condición de salida no está bien definida, el bucle puede correr indefinidamente — por eso siempre necesita, además de la condición de éxito, un límite duro (nuestro “días_máximos”) que garantice que el proceso termine de una forma u otra.

Patrón de revisión y crítica (generador-crítico)

Escenario: redactar una carta de amonestación disciplinaria. Este es un documento donde un error tiene consecuencias legales reales — tiene que citar la política violada, mantener tono factual, y seguir el formato de disciplina progresiva.

[Agente Generador] → borrador
        ↓
[Agente Crítico] → ¿cumple los criterios?
        ├── SÍ → aprobada
        └── NO → retroalimentación específica → [Generador] → nuevo borrador → ...

Este patrón es una implementación del patrón de bucle: un agente generador crea un output inicial, y un agente crítico lo evalúa contra criterios predefinidos, aprobando, rechazando, o devolviéndolo con retroalimentación para revisión. El crítico usa exactamente la misma técnica de evaluación guiada por rúbrica del Capítulo 3 — la diferencia no es el mecanismo, es que aquí vive integrado dentro del flujo en vivo, con poder de forzar una nueva iteración, en vez de evaluar offline después del hecho.

Ejemplo de una vuelta: un primer borrador dice “usted ha estado llegando tarde de manera irresponsable” — el crítico lo rechaza por no citar la política violada, usar lenguaje emocional, y no incluir fechas. El segundo borrador, incorporando esa retroalimentación específica, cita “Política de Asistencia §4.2”, enumera fechas exactas, y usa lenguaje neutral — se aprueba. La retroalimentación específica (no solo “rechazado”) es lo que permite corregir en la siguiente vuelta, en vez de reintentar al azar.

El costo: cada ronda de revisión suma una llamada adicional al modelo, acumulando latencia y gasto con cada iteración — vale la pena para documentos de alto riesgo (como esta carta), sobre-ingeniería para tareas de bajo riesgo (un recordatorio informal de reunión).

Una aclaración importante: ¿quién orquesta, código o IA?

Vale la pena dejar esto completamente explícito, porque es una de las confusiones más comunes al aprender sistemas agénticos: los cuatro patrones que acabamos de ver (secuencial, paralelo, bucle, revisión-crítica) no tienen ninguna capacidad inherente de “saberse organizar”. Toda su orquestación es código normal, no un modelo de IA decidiendo el flujo.

Retomando el ciclo Generador-Crítico:

intentos = 0
max_intentos = 3
carta_aprobada = False

while not carta_aprobada and intentos < max_intentos:
    borrador = llamar_llm(prompt_generador, retroalimentacion_previa)
    veredicto = llamar_llm(prompt_critico, borrador, criterios)
    if veredicto.aprobado:
        carta_aprobada = True
    else:
        retroalimentacion_previa = veredicto.razones
        intentos += 1

if not carta_aprobada:
    escalar_a_humano()

El while, el if, el conteo de intentos — código de programación ordinario, sin ninguna IA involucrada en decidir el flujo. Las únicas líneas donde interviene un LLM son las dos llamadas a llamar_llm(). El nombre “agente de flujo de trabajo” que usa la fuente de Google Cloud para estos patrones es, honestamente, un poco engañoso — no es un “agente” que razone sobre el flujo; es simplemente el código de control que lo ejecuta.

Esto conecta directo con el “grado de autonomía” del Capítulo 6: los cuatro patrones vistos hasta aquí son, todos, implementaciones de autonomía baja a nivel de orquestación — aunque cada agente individual dentro del flujo sí use un LLM para su tarea específica, la decisión de qué agente llamar y cuándo no la toma ningún modelo, ya viene resuelta por el diseño humano.

El patrón coordinador, que viene a continuación, es genuinamente distinto: ahí, un LLM sí analiza la solicitud entrante y decide dinámicamente a qué agente enviarla — la orquestación misma pasa a ser una decisión de IA, no código fijo. Esta es la distinción exacta que Google Cloud usa para separar “flujos de trabajo deterministas” de “flujos que requieren orquestación dinámica”.

Patrón de refinamiento iterativo

Escenario: redactar la descripción de un puesto técnico difícil de cubrir. A diferencia de la carta de amonestación, aquí no hay un veredicto binario limpio — la calidad de una descripción de puesto es un espectro que mejora con cada pasada de pulido: claridad de responsabilidades, lenguaje sin sesgo de género, número realista de requisitos “obligatorios”.

Iteración 1: [Agente] → borrador inicial
Iteración 2: [Agente] → mejora claridad de responsabilidades
Iteración 3: [Agente] → ajusta lenguaje para reducir sesgo
Iteración 4: [Agente] → recorta requisitos de 15 a 5 reales
             ¿Umbral de calidad alcanzado? → SÍ → fin

Otra implementación del patrón de bucle, pero con una diferencia de diseño frente al generador-crítico del patrón anterior: aquí, uno o más agentes modifican progresivamente un mismo resultado, guardado en el estado de sesión — en vez de dos roles separados (uno que genera, otro que solo aprueba/rechaza). El criterio de parada también es distinto: no es binario (aprobado/rechazado contra una rúbrica), es progresivo — un puntaje de calidad, evaluado con la misma técnica de calificación 1-5 del Capítulo 3, que va subiendo hasta cruzar un umbral, o hasta un máximo de iteraciones.

Adecuado para tareas de generación complejas difíciles de lograr en un solo intento — escribir y depurar código, desarrollar un plan detallado, redactar y revisar un documento largo — todas comparten la característica de mejorar de forma incremental y medible con cada revisión, más que resolverse con un veredicto limpio de sí/no. Hereda el mismo riesgo de no converger que cualquier bucle, con la misma solución: un límite duro de iteraciones máximas, y escalamiento a un humano si se alcanza sin cruzar el umbral.

Patrón coordinador

Escenario: un solo punto de entrada para todo el asistente de RR.HH. Recordemos el problema que motivó todo este capítulo: un agente único se rompe si tiene que manejar vacaciones, gastos, y quejas de acoso laboral con un solo prompt gigante. El coordinador resuelve esto sin obligar al empleado a saber a qué “bot” dirigirse — todo llega a un único punto de entrada, y el coordinador decide a dónde enviarlo.

Mensaje del empleado
        ↓
[Agente Coordinador] → analiza la intención con un LLM
        ├── "solicitud de vacaciones" → [Agente único, Cap. 6]
        ├── "recibo de gastos" → [Pipeline secuencial]
        ├── "pregunta sobre política" → [Solo RAG, Cap. 5]
        └── "queja sensible / acoso" → [Escalamiento humano inmediato]

Un agente central (coordinador) analiza y descompone la solicitud del usuario en sub-tareas, despachando cada una a un agente especializado. A diferencia de todos los patrones anteriores, el coordinador sí usa un modelo de IA para orquestar y enrutar dinámicamente — la variable que decide el enrutamiento viene de una llamada al LLM interpretando lenguaje libre y ambiguo, no de una regla fija como “si tipo_documento == 'recibo'”.

El caso que más importa — por qué la queja sensible no puede fallar: si el coordinador malinterpreta un mensaje ambiguo y clasifica una queja seria como “pregunta_politica”, el resultado es una queja delicada respondida por un bot en vez de escalar de inmediato a un humano — el mismo tipo de riesgo que vimos con el caso Finnbot en Parte III: autonomía real para decidir rutas, donde una mala clasificación no es cosmética. La mitigación no es eliminar la autonomía del coordinador — es exigir un umbral de confianza más alto para categorías de riesgo alto: ante la duda, inclinarse por escalar a un humano de más, no de menos.

Útil para automatizar procesos que requieren enrutamiento adaptativo. Más flexible que flujos rígidos predefinidos, pero implica una llamada adicional dedicada solo a clasificar, antes siquiera de resolver la solicitud real — más costo y latencia que un pipeline fijo, a cambio de que cada especialista mantenga su prompt enfocado, sin que ninguno necesite saber los detalles de los demás dominios.

Patrón de descomposición jerárquica de tareas

Escenario: diseñar la propuesta de compensación total para un puesto nuevo. A diferencia del coordinador (que enruta a una rama excluyente), aquí el problema se reparte entre varias sub-tareas que se ejecutan todas y después hay que recombinar: benchmarking salarial, diseño de beneficios, y estructura de equity.

Solicitud: "Diseña la compensación total para ML Senior"
                    ↓
        [Agente Raíz] — descompone la tarea en sub-tareas
    ┌───────────────┼───────────────┐
    ▼               ▼               ▼
[Benchmarking   [Beneficios]    [Equity]
 Salarial]
    └───────────────┴───────┬───────┘
                             ▼
                  [Agente Raíz] — sintetiza
                  las tres piezas en una propuesta final

Una implementación del patrón coordinador que organiza agentes en una jerarquía de múltiples niveles: un agente raíz recibe una tarea compleja, la descompone en sub-tareas más manejables, delega a subagentes especializados de niveles inferiores, y luego sintetiza sus resultados — el mismo agente raíz suele encargarse tanto de descomponer al inicio como de sintetizar al final, en dos momentos distintos del mismo flujo. Comparte con el patrón paralelo la necesidad de reconciliar resultados de varias fuentes, y con el coordinador el hecho de que un LLM decide activamente cómo dividir el problema, en vez de que la división esté fija de antemano.

Ideal para problemas ambiguos y abiertos que requieren razonamiento de múltiples pasos — investigación, planeación, síntesis. Puede producir resultados más comprehensivos que cualquier patrón anterior, pero agrega la complejidad arquitectónica y el costo más altos de toda la taxonomía hasta este punto.

Nota: cuando la coordinación no necesita IA en absoluto. Es tentador citar el experimento de Anthropic donde 16 agentes Claude construyeron un compilador de C completo (100,000 líneas de Rust, capaz de compilar el kernel de Linux) en dos semanas como ejemplo de coordinador o descomposición jerárquica — pero técnicamente no lo es. El sistema coordinó el trabajo mediante un mecanismo de bloqueo basado en git que asignaba tareas distintas a cada agente, y verificó cada resultado contra GCC como “oráculo de referencia” — sin ningún agente-LLM orquestando dinámicamente ni sintetizando resultados con razonamiento. Es un recordatorio útil de que estos patrones son herramientas conceptuales para pensar arquitecturas, no una lista exhaustiva de todo lo que funciona en la práctica: a veces la coordinación más robusta es la que menos depende de que un LLM decida el flujo, y más de infraestructura determinista y verificación objetiva.

Patrón swarm (enjambre): un enfoque colaborativo de comunicación todos-con-todos, donde múltiples agentes especializados trabajan juntos para refinar iterativamente una solución. Un agente “despachador” enruta la solicitud inicial, pero no orquesta el flujo de trabajo (a diferencia del coordinador) — cada agente puede comunicarse con cualquier otro, compartir hallazgos, criticar propuestas, y transferir la tarea a otro agente que considere mejor posicionado para el siguiente paso. Requiere una condición de salida explícita (máximo de iteraciones, límite de tiempo, o consenso alcanzado) para evitar que el proceso nunca termine. Útil para problemas ambiguos que se benefician de debate e iteración (ej. diseñar un producto nuevo con un agente de investigación de mercado, uno de ingeniería, y uno de modelado financiero, debatiendo trade-offs hasta converger). Puede producir soluciones excepcionalmente creativas, pero es el patrón multi-agente más complejo y costoso, con riesgo real de bucles improductivos o falta de convergencia.

Patrones adicionales fuera de la taxonomía multi-agente

Patrón ReAct (Reason and Act)

Escenario: “mi cheque de este mes llegó más bajo de lo esperado, no sé por qué.” A diferencia de todo lo visto hasta ahora, aquí no sabemos de antemano qué pasos hacen falta ni en qué orden — podría ser horas mal registradas, un cambio en deducciones, un ajuste de impuestos, o varias cosas a la vez. Ningún pipeline fijo puede anticipar esto, porque la ruta de investigación depende de lo que se descubra en cada paso.

Pensamiento: "necesito revisar las horas registradas este mes"
Acción: consultar_horas_trabajadas(empleado)
Observación: horas normales, sin anomalía

Pensamiento: "las horas están bien, quizás cambió algo en las deducciones"
Acción: consultar_deducciones_beneficios(empleado)
Observación: se agregó un descuento de seguro dental desde este mes

Pensamiento: "esto explica la diferencia, tengo información suficiente"
Acción: [formular respuesta final, sin más herramientas]

El modelo enmarca su proceso de pensamiento y acciones como una secuencia de interacciones en lenguaje natural, operando en un bucle iterativo de pensamiento → acción → observación hasta cumplir una condición de salida. La diferencia real con el patrón secuencial de gastos: ahí el orden es siempre el mismo, sin importar el caso; aquí, si el problema hubiera sido de horas en vez de deducciones, el agente habría necesitado herramientas y número de pasos completamente distintos — la ruta se construye sobre la marcha. En términos del Capítulo 6, esto es autonomía alta: el agente decide cuántas rondas de investigación necesita y cuáles herramientas usar en cada una, no solo el orden entre herramientas fijas.

Útil para tareas dinámicas que requieren planeación y adaptación continua. Un solo agente ReAct puede ser más simple y económico que un sistema multi-agente complejo, y el registro del razonamiento ayuda a depurar. El costo es distinto al del patrón de bucle: ahí la duración era impredecible por una variable externa (cuándo el empleado completa su checklist); aquí es impredecible por cuánto razonamiento interno necesita el modelo para resolver el problema en una sola sesión — cada vuelta suma latencia, sin límite predecible de antemano, por lo que en la práctica siempre se define un máximo de vueltas antes de escalar a un humano.

Patrón human-in-the-loop

Este patrón ya lo usamos varias veces sin nombrarlo formalmente: en el Capítulo 5c, el agente de vacaciones preguntaba antes de enviar la solicitud real; en el pipeline de gastos, un recibo de $2,000 se enrutaba a aprobación manual. Todas esas son instancias del mismo patrón — que no compite con los demás, sino que se les puede agregar a cualquiera de ellos.

Escenario adicional: procesar el despido de un empleado. Un agente podría redactar toda la documentación — calcular la liquidación vía RAG, generar la carta de terminación con el mismo patrón generador-crítico de la carta de amonestación, armar el checklist de salida. Pero ejecutar eso (enviar la notificación oficial, procesar el pago final) es exactamente el tipo de acción irreversible y de alto impacto del caso Finnbot (Parte III): nunca debería automatizarse sin que un humano con autoridad confirme explícitamente antes.

El agente integra puntos de intervención humana directamente en su flujo: en un checkpoint predefinido, pausa su ejecución y espera revisión antes de continuar. Vale la pena nombrarlo como su propio patrón, y no dejarlo implícito, porque fuerza una pregunta de diseño explícita — ¿en qué puntos exactos de este flujo necesito un checkpoint humano, y con qué criterio? — en vez de resolverla por instinto, caso por caso.

Patrón de lógica personalizada

Escenario: el pipeline de gastos, llevado a la complejidad de una empresa real. Ya habíamos notado la limitación del patrón secuencial puro: un recibo de $12 y uno de$ 2,000 no deberían tratarse igual. Resolvámoslo combinando patrones:

def procesar_gasto(recibo):
    datos = agente_extractor(recibo)
    
    if datos.monto < 100:
        # gasto pequeño: pipeline secuencial simple
        veredicto = agente_validador(datos)
        return agente_aprobador(veredicto)
    
    else:
        # gasto grande: aprobación paralela de dos partes distintas
        aprobacion_manager = agente_aprobacion_manager(datos)
        aprobacion_finanzas = agente_aprobacion_finanzas(datos)
        
        if aprobacion_manager.aprobado and aprobacion_finanzas.aprobado:
            return agente_aprobador(datos)
        elif aprobacion_manager.aprobado != aprobacion_finanzas.aprobado:
            return escalar_a_humano(datos, razon="desacuerdo entre manager y finanzas")
        else:
            return rechazar(datos)

Aquí combinamos, dentro de un mismo flujo: secuencial (gastos pequeños), paralelo (las dos aprobaciones simultáneas para gastos grandes), y human-in-the-loop (cuando hay desacuerdo) — todo decidido por reglas de negocio explícitas (monto < 100), no por un LLM razonando sobre qué camino tomar como en el coordinador.

Máxima flexibilidad, con el trade-off más honesto de todos los patrones: control quirúrgico sobre cada caso, pero tú eres responsable de diseñar, implementar, y depurar cada rama del árbol de decisión — cada camino posible tiene que estar contemplado explícitamente en el código, a diferencia del coordinador, donde el LLM decide dinámicamente sin que tengas que anticipar cada combinación. Es el patrón que más se parece a programación de software tradicional, porque en esencia lo es: los agentes son piezas dentro de una lógica de control que tú sigues escribiendo a mano.

Tabla de decisión: eligiendo el patrón correcto

Característica de la carga de trabajo	Patrón recomendado	Nuestro ejemplo
Flujo rígido, multi-paso, predefinido, sin necesidad de orquestación por modelo	Secuencial	Procesar un recibo de gastos: extraer → validar → aprobar
Tareas independientes ejecutables al mismo tiempo	Paralelo	Analizar un comentario de encuesta: sentimiento + palabras clave + categoría + urgencia, a la vez
Requiere mejora progresiva del output en varios ciclos	Refinamiento iterativo	Pulir la descripción de un puesto técnico difícil de cubrir
Tareas estructuradas que requieren herramientas externas, desarrollo rápido de prototipo	Agente único	El asistente de vacaciones del Capítulo 6, en su forma original
Enrutamiento dinámico a subagentes especializados según entrada variada	Coordinador	El punto de entrada único del asistente de RR.HH., enrutando entre vacaciones/gastos/política/quejas
Tareas ambiguas y abiertas que requieren orquestación de múltiples niveles	Descomposición jerárquica	Diseñar la compensación total de un puesto: benchmarking + beneficios + equity
Debate colaborativo y refinamiento iterativo entre especialistas	Swarm	Diseñar un producto nuevo con agentes de mercado, ingeniería, y finanzas debatiendo trade-offs
Razonamiento y adaptación continua para tareas dinámicas	ReAct	Investigar por qué el cheque de un empleado llegó más bajo de lo esperado
Monitoreo o sondeo repetido hasta cumplir una condición de salida	Loop	Seguimiento diario del checklist de onboarding de un empleado nuevo
Requiere un paso de validación distintivo antes de completar	Revisión y crítica	Redactar una carta de amonestación disciplinaria, con verificación legal antes de aprobar
Supervisión humana obligatoria por riesgo, seguridad, o cumplimiento	Human-in-the-loop	Confirmar antes de enviar una solicitud de vacaciones, o antes de ejecutar un despido
Lógica de negocio única, ramificación compleja	Lógica personalizada	El pipeline de gastos completo, con rutas distintas según el monto

Métricas de decisión, de un vistazo

Más allá de “qué patrón encaja con qué tipo de tarea” (la tabla anterior), a veces ayuda comparar los patrones directamente en las dimensiones que más importan al diseñar un sistema real:

Patrón	Latencia relativa	Costo por solicitud	Mantenibilidad	Flexibilidad	Riesgo principal
Secuencial	Suma de cada paso	Bajo	Alta	Baja	Rigidez ante casos no anticipados
Paralelo	El máximo de los pasos, no la suma	Medio (N llamadas simultáneas)	Media	Baja	Reconciliar resultados contradictorios
Bucle	Impredecible (depende de cuándo se cumple la condición)	Variable	Media	Baja	Bucle infinito sin límite duro
Revisión y crítica	Una ronda + una por cada rechazo	Medio-alto	Media	Media	Costo si hay muchas rondas de rechazo
Refinamiento iterativo	Una ronda por cada mejora incremental	Medio-alto	Media	Media	Mismo riesgo que el bucle: sin límite, puede no converger
Coordinador	Clasificación + la sub-tarea elegida	Medio	Media-baja	Alta	Mala clasificación en casos de alto riesgo
Descomposición jerárquica	Descomposición + sub-tareas en paralelo + síntesis	Alto	Baja	Muy alta	La más compleja de depurar de todas
Swarm	Muy alta (múltiples rondas de debate)	Muy alto	Muy baja	Muy alta	No convergencia, bucles improductivos
ReAct	De 1 a varias vueltas × la latencia de cada una	Variable (depende de cuántas vueltas)	Baja	Muy alta	Deriva — perderse en investigaciones improductivas

Cómo usar esta tabla, con cautela: estas son comparaciones relativas y cualitativas, útiles para razonar sobre trade-offs — no cifras medidas ni umbrales universales. Por ejemplo, es razonable pensar “si mi aplicación necesita respuestas casi instantáneas, un patrón con múltiples rondas (Swarm, ReAct con muchas vueltas) probablemente no encaja” — pero el punto exacto donde eso deja de ser cierto depende enteramente de tu caso específico, tu modelo y tu infraestructura (recordando el trilema de inferencia de Parte III). La única forma confiable de saber si un patrón cumple tus requisitos de latencia o costo es medirlo con tu propia carga de trabajo real, no aplicar un umbral genérico leído en una tabla.