Logo GCP con Eduardo

GCP con Eduardo

Descarga el código de la lección

Arquitectura MULTI-AGENTE en Producción: Router y Ejecución en Paralelo (Google ADK)
✦ Guía Técnica & Arquitectura

Arquitectura MULTI-AGENTE en Producción: Router y Ejecución en Paralelo con Google ADK

Diseñar un sistema multiagente no consiste en crear varios prompts y conectarlos. En producción necesitas separar routing, especialización, concurrencia, agregación, aislamiento de estado, observabilidad y control de costes. Google ADK proporciona primitivas de workflow como ParallelAgent y SequentialAgent para construir este tipo de pipelines de forma determinista. La clave arquitectónica es saber cuándo delegar al LLM y cuándo imponer el flujo desde código.

Lo que aprenderás

Diseñar un router de agentes para distribuir peticiones hacia especialistas.
Implementar fan-out / gather con ParallelAgent y resultados independientes.
Reducir latencia evitando pipelines secuenciales cuando no existe dependencia de datos.
Controlar FinOps, errores, estado compartido y observabilidad en producción.
Python 3.11+ Google ADK Gemini LlmAgent ParallelAgent SequentialAgent Router Pattern Cloud Run OpenTelemetry

La arquitectura correcta: Router → Fan-Out → Gather

Un sistema multiagente empresarial suele tener tres responsabilidades diferentes. Primero, identificar qué dominio necesita atención. Segundo, ejecutar los especialistas que realmente sean necesarios. Tercero, consolidar sus resultados en una respuesta coherente.

Una distinción importante es que Google ADK no necesita un objeto llamado literalmente RouterAgent para implementar este patrón. El routing puede realizarse mediante un agente LLM con sub-agentes cuando la decisión debe ser semántica, mientras que ParallelAgent y SequentialAgent proporcionan control determinista sobre la ejecución. Esta separación evita confundir delegación basada en LLM con workflow orchestration.

Modelo mental

Imagina una petición empresarial: “Tengo un cliente que quiere cancelar el contrato, pregunta por una factura pendiente y además quiere conocer las alternativas comerciales.”

Un único agente monolítico tendría que razonar sobre soporte, billing, ventas y legal. Una arquitectura especializada puede clasificar la intención y ejecutar los especialistas relevantes de manera independiente.

Router Support Agent Sales Agent Legal Agent Billing Agent Aggregator

Matriz de decisión arquitectónica

No todos los problemas requieren el mismo nivel de orquestación. La decisión correcta depende de la dependencia entre tareas, la latencia objetivo, la consistencia requerida y el coste máximo aceptable.

Patrón Ejecución Latencia Consistencia Coste Cuándo usarlo
Single Agent Una cadena de razonamiento Media Alta dentro de un único contexto Bajo / medio Casos sencillos y dominios homogéneos.
Router → Specialist Selección de una rama Baja / media Alta en la rama elegida Medio Soporte, ventas, legal o dominios mutuamente excluyentes.
ParallelAgent Fan-out concurrente ≈ rama más lenta Requiere agregación Medio / alto Investigaciones independientes que pueden ejecutarse simultáneamente.
SequentialAgent Pipeline ordenado Suma de etapas Alta y explícita Medio Cuando una etapa depende del resultado de la anterior.
Router + Parallel + Gather Routing + fan-out + síntesis Optimizable Controlada por contrato de estado Alto Casos enterprise con múltiples especialistas independientes.

El punto crítico: paralelismo no significa ejecutar todo

El mayor error de una arquitectura multiagente suele ser convertir ParallelAgent en una excusa para disparar todos los especialistas ante cada consulta.

Antipatrón FinOps: Fan-Out indiscriminado

Supongamos que una petición puede ser resuelta por soporte, pero el sistema ejecuta simultáneamente soporte, legal, ventas, billing y compliance. La latencia puede mejorar frente a una ejecución secuencial, pero el coste de inferencia crece con cada rama y también aumenta el volumen de contexto, herramientas y trazas que deben procesarse.

La solución no es eliminar el paralelismo. Es introducir una política: router primero, fan-out únicamente sobre especialistas relevantes, gather después.

Regla de producción: paraleliza dependencias, no agentes.

Además, cada agente paralelo debe escribir en una clave de estado diferente. La documentación y las referencias actuales de ADK muestran precisamente este patrón con output_key, porque compartir la misma clave entre ramas introduce condiciones de carrera.

Implementación práctica con Google ADK y Python

El siguiente patrón implementa una arquitectura de producción simplificada: un router semántico decide qué especialistas son relevantes y, para el caso en el que se necesitan varias investigaciones independientes, un ParallelAgent realiza el fan-out antes de que un agente final sintetice los resultados.

app/agent.py Python · Google ADK
from google.adk.agents import (
    LlmAgent,
    ParallelAgent,
    SequentialAgent,
)

MODEL = "gemini-3.7-flash"


# -------------------------------------------------------------------
# 1. Especialistas
# -------------------------------------------------------------------

support_agent = LlmAgent(
    name="support_specialist",
    model=MODEL,
    instruction="""
    Eres el especialista de soporte.
    Analiza incidencias, problemas de producto y solicitudes operativas.
    Devuelve únicamente hechos, diagnóstico y acciones recomendadas.
    """,
    output_key="support_result",
)


sales_agent = LlmAgent(
    name="sales_specialist",
    model=MODEL,
    instruction="""
    Eres el especialista comercial.
    Analiza oportunidades, pricing, alternativas comerciales y próximos pasos.
    No inventes descuentos ni condiciones contractuales.
    """,
    output_key="sales_result",
)


legal_agent = LlmAgent(
    name="legal_specialist",
    model=MODEL,
    instruction="""
    Eres el especialista legal.
    Identifica riesgos contractuales y cláusulas relevantes.
    No presentes tu análisis como asesoramiento jurídico definitivo.
    """,
    output_key="legal_result",
)


# -------------------------------------------------------------------
# 2. Fan-out determinista
# -------------------------------------------------------------------
#
# Los especialistas son independientes entre sí.
# Cada uno escribe en una clave de estado diferente.
#

parallel_specialists = ParallelAgent(
    name="parallel_specialists",
    sub_agents=[
        support_agent,
        sales_agent,
        legal_agent,
    ],
)


# -------------------------------------------------------------------
# 3. Gather / síntesis
# -------------------------------------------------------------------

aggregator = LlmAgent(
    name="response_aggregator",
    model=MODEL,
    instruction="""
    Eres el agente de síntesis.

    Combina los resultados disponibles:

    SOPORTE:
    {support_result}

    VENTAS:
    {sales_result}

    LEGAL:
    {legal_result}

    Produce una respuesta única, estructurada y accionable.

    Reglas:
    - No inventes información.
    - Diferencia hechos de recomendaciones.
    - Si una rama no aporta información relevante, ignórala.
    - Si existen contradicciones, señálalas explícitamente.
    """,
)


# -------------------------------------------------------------------
# 4. Workflow completo
# -------------------------------------------------------------------

multi_agent_workflow = SequentialAgent(
    name="multi_agent_workflow",
    sub_agents=[
        parallel_specialists,
        aggregator,
    ],
)


# -------------------------------------------------------------------
# 5. Router conceptual
# -------------------------------------------------------------------
#
# Para routing semántico, puede utilizarse un LlmAgent superior
# que delegue hacia especialistas mediante sub_agents.
#
# En producción, conviene definir explícitamente:
#   - qué intención activa cada especialista
#   - qué herramientas puede utilizar
#   - qué información puede modificar
#   - qué acciones requieren aprobación
#
# No conviertas el router en un "mega-agente" que haga también
# toda la ejecución de negocio.
#

router_agent = LlmAgent(
    name="router_agent",
    model=MODEL,
    instruction="""
    Eres el router principal.

    Clasifica la petición del usuario antes de delegar.

    Puedes delegar a:
    - support_specialist: incidencias y soporte.
    - sales_specialist: oportunidades comerciales.
    - legal_specialist: contratos y riesgos.

    Si la petición requiere varias áreas independientes,
    utiliza el workflow multi_agent_workflow.

    Nunca inventes una categoría.
    Si la intención es ambigua, solicita la información mínima
    necesaria para enrutar correctamente.
    """,
    sub_agents=[
        multi_agent_workflow,
    ],
)


root_agent = router_agent

Nota arquitectónica: el nombre “router agent” describe el patrón de diseño; la ejecución paralela determinista corresponde a ParallelAgent. ADK documenta los workflow agents como primitivas para controlar el flujo sin depender exclusivamente del razonamiento del LLM.

Por qué Fan-Out / Gather reduce la latencia

Consideremos tres especialistas con tiempos aproximados de 900 ms, 1.200 ms y 1.600 ms. Si se ejecutan secuencialmente, el tiempo de las ramas es aproximadamente:

Tsequential ≈ 0,9 + 1,2 + 1,6 = 3,7 s

Con ejecución concurrente, el límite ideal de la fase de fan-out se aproxima a la rama más lenta:

Tparallel ≈ max(0,9, 1,2, 1,6) = 1,6 s

A esto hay que añadir el tiempo del agregador, networking, tool calls, scheduling y cualquier overhead del runtime. Por tanto, 1,6 s no es una garantía de end-to-end latency; es el límite conceptual de la fase paralela.

El ahorro de latencia, además, tiene un precio: se están ejecutando tres inferencias. La optimización real consiste en minimizar simultáneamente critical path y fan-out innecesario.

Patrones de diseño para producción

Una implementación enterprise debe tratar a los agentes como componentes con contratos explícitos, no como simples prompts.

01

Routing explícito

Define las categorías de intención, los especialistas autorizados y las condiciones de escalado. Evita que el router tenga acceso indiscriminado a todas las herramientas del sistema.

02

Estado con contratos

Usa output_key diferentes para cada rama. El agregador debe conocer exactamente qué estructura produce cada especialista. Esto reduce acoplamiento y condiciones de carrera.

03

Fallos parciales

Una rama de ventas no debería necesariamente invalidar una respuesta de soporte. Define timeouts, fallback, estados de error y reglas para degradación controlada.

04

Idempotencia

Las herramientas que producen side effects deben ser idempotentes cuando sea posible. Un retry del modelo nunca debería duplicar accidentalmente un pago, una orden o una modificación contractual.

05

Observabilidad

Mide por separado router, especialistas, herramientas y agregador. Latencia p50/p95/p99, tokens, errores, retries y coste por workflow son métricas operativas, no simples detalles de debugging.

06

Gobernanza

Un agente legal no debería tener automáticamente los permisos de billing. Aplica least privilege también a las herramientas y a las identidades de ejecución de los agentes.

Router semántico vs workflow determinista

Esta es una de las decisiones más importantes en una arquitectura multiagente: ¿dejo que el LLM decida el flujo o lo determino desde código?

Característica Delegación LLM Workflow ADK
Decisión Semántica y dinámica Determinista
Flexibilidad Alta Alta pero explícita
Predictibilidad Menor Mayor
Coste de decisión Incluye inferencia Principalmente computacional
Auditoría Requiere trazabilidad del razonamiento operativo Flujo visible en código
Uso recomendado Clasificación, intención y delegación Orden, paralelismo, límites y dependencias

El patrón Staff/Architect recomendado es híbrido: usar el LLM para decidir cuando la decisión es semántica y usar workflows deterministas cuando la decisión es operacional.

Checklist de implementación empresarial

Utiliza este framework antes de llevar un sistema multiagente a producción.

Define bounded contexts

Cada agente debe tener una responsabilidad clara: soporte, ventas, legal, billing, investigación o síntesis. Si dos agentes tienen prácticamente las mismas responsabilidades, probablemente existe una frontera arquitectónica mal definida.

Diseña el contrato de entrada y salida

Define qué información recibe cada agente, qué estructura devuelve, qué herramientas puede utilizar y qué errores puede producir. Usa claves de estado independientes para ramas paralelas.

Clasifica dependencias

Dibuja el DAG del workflow. Si B necesita el resultado de A, existe una dependencia secuencial. Si C y D sólo necesitan la entrada original, son candidatos naturales para ejecución paralela.

Introduce límites de coste

Controla número de agentes, profundidad de delegación, retries, tokens y llamadas a herramientas. Define presupuestos por request y métricas de coste por workflow.

Diseña fallos parciales

Decide qué ocurre si un especialista falla, tarda demasiado, devuelve información inválida o agota su presupuesto. Una arquitectura resiliente debe poder degradarse sin colapsar todo el workflow.

Instrumenta el critical path

Registra duración del router, duración de cada rama, tiempo del agregador, retries, tool calls, errores y consumo de tokens. Optimiza primero la rama que domina el p95.

Evalúa antes de desplegar

Construye datasets representativos para medir routing accuracy, calidad de cada especialista, tasa de fallback, coste y latencia. Los cambios de prompts y modelos deben compararse contra una baseline reproducible.

Despliega con rollback

Versiona prompts, código y configuración de modelos. Mantén una estrategia de rollback para que una regresión de un especialista no obligue a rediseñar todo el sistema.

Observabilidad: la arquitectura invisible que evita sorpresas

En un sistema multiagente, el tiempo total de respuesta deja de ser suficiente como métrica. Necesitas descomponer la ejecución.

Router latency

¿Cuánto tarda la clasificación? Si el router consume casi tanto como el trabajo que intenta optimizar, el diseño debe revisarse.

Branch latency

Mide cada especialista por separado. En paralelo, la rama más lenta domina el critical path.

Token economics

Un workflow rápido puede ser económicamente malo si dispara múltiples contextos grandes y llamadas innecesarias al modelo.

Tool failures

Separa errores del LLM de errores de herramientas. Un agente puede razonar correctamente y fallar porque una API externa está degradada.

Quality by branch

Evalúa cada especialista individualmente antes de evaluar únicamente la respuesta final del sistema.

Trace correlation

Cada request debe poder reconstruirse desde router hasta agregador, incluyendo branches y tool calls.

Errores críticos que evitar

1. Crear un agente para cada función pequeña

La granularidad excesiva genera overhead de inferencia, más prompts que mantener y una superficie de observabilidad mucho mayor. Un agente debe justificar su existencia mediante una frontera funcional clara.

2. Paralelizar tareas dependientes

Si el agente B necesita un dato generado por A, ejecutarlos en paralelo no es optimización: es una violación del DAG. Utiliza un pipeline secuencial o una fase explícita de gather.

3. Compartir output_key

Dos ramas escribiendo sobre la misma clave convierten el estado compartido en una fuente de carreras. Cada rama debe tener su namespace o clave claramente diferenciada.

4. Permitir side effects durante la exploración

Los agentes de investigación deberían poder consultar información sin obtener automáticamente permisos para modificar sistemas críticos. Separa lectura de escritura y utiliza gates de aprobación para acciones sensibles.

5. Confundir latencia con eficiencia

Bajar una respuesta de 6 segundos a 2 segundos ejecutando cuatro veces más inferencias puede ser una mala optimización. La métrica correcta es multidimensional: calidad + p95 + coste + tasa de error.

Preguntas frecuentes

¿Qué diferencia hay entre un router de agentes y un ParallelAgent en Google ADK?

El router decide qué especialista debe intervenir según la intención, contexto o reglas de negocio. ParallelAgent es una primitiva de workflow para ejecutar simultáneamente varios sub-agentes que ya han sido seleccionados como parte del flujo. No deben considerarse sustitutos: cumplen responsabilidades diferentes.

¿Cuándo conviene ejecutar agentes en paralelo?

Cuando las tareas son independientes y no necesitan el resultado de otro agente para comenzar. El tiempo de la fase paralela se aproxima conceptualmente a la rama más lenta, pero el coste total de inferencia aumenta con cada agente ejecutado. Por eso el paralelismo debe aplicarse después de determinar qué ramas son realmente necesarias.

¿Cómo evitar condiciones de carrera con ParallelAgent?

Cada especialista debe utilizar una clave de salida distinta mediante output_key. Después, un agente de síntesis ejecutado en una fase posterior consume esas claves. Este patrón fan-out/gather mantiene separadas las escrituras de las ramas paralelas y hace explícito el contrato entre especialistas y agregador.

Sobre el Autor: Eduardo Martínez Agrelo

AI & Data Architect

Eduardo Martínez Agrelo es AI & Data Architect, especializado en arquitectura de datos, inteligencia artificial, sistemas distribuidos y diseño de plataformas orientadas a producción. Su enfoque combina profundidad técnica con decisiones arquitectónicas orientadas a escalabilidad, observabilidad, gobierno y eficiencia económica.

En sus contenidos técnicos aborda patrones de arquitectura que permiten pasar de prototipos de IA a sistemas empresariales mantenibles, evaluables y operables.

© 2026 Eduardo Martínez Agrelo · AI & Data Architect

Arquitectura multiagente · Google ADK · Python · Sistemas distribuidos · AI Engineering