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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
