Multi-agent orchestration patterns: 6 patrones con tradeoffs

Multi-agent se volvió tema vendido demás. En 80% de los casos que vemos, un agente bien diseñado vencería a tres agentes en “crew”. Pero hay casos genuinos donde multi-agente paga. Seis patterns, con tradeoffs.

Pattern 1 · Sequential pipeline

Agente A → output → Agente B → output → Agente C.

Cuándo vale: tareas con fases distintas y cambio de modelo apropiado por fase. Investigador (Sonnet) → escritor (Opus) → revisor (Haiku para checagem rápida).

Tradeoff:

• ✅ Cada fase optimizada por modelo adecuado.
• ✅ Auditability alta (cada output es checkpoint).
• ❌ Latencia suma. 3 agentes secuenciales = 3× la latencia de 1 agente.
• ❌ Error propaga. Falla en A se vuelve basura en B y C.

Mitigación: validation entre stages, con retry.

Pattern 2 · Specialist routing (router + experts)

Agente router clasifica request → rutea para expert apropiado (jurídico, financiero, soporte). Cada expert es especializado.

Cuándo vale: dominio donde especialización real existe y el router clasifica con alta confianza.

Tradeoff:

• ✅ Cada expert puede tener system prompt corto y focado.
• ✅ Cost-efficient (expert simple puede usar Haiku).
• ❌ Router equivocado destruye el sistema.
• ❌ Cross-domain (request que toca jurídico + financiero) se vuelve problema.

Mitigación: router con confidence threshold; cuando bajo, escala para multi-expert o humano.

Pattern 3 · Debate / dialéctico

Dos agentes argumentan posiciones opuestas; un tercero decide.

Cuándo vale: decisión con tradeoffs sensibles (aprobar/rechazar pedido complejo, elegir entre alternativas).

Tradeoff:

• ✅ Captura matices que un agente único se salta.
• ❌ Carísimo. 3× el costo, y latencia más alta.
• ❌ Riesgo de “debate teatral” — agentes generan argumentos sin real adversarialidad.

Pattern usado en: Constitutional AI training de Anthropic; raramente en producción comercial directa.

Pattern 4 · Hierarchical (manager + workers)

Manager agent rompe task en subtasks, distribuye a workers, agrega.

Cuándo vale: tasks que descomponen bien (research en N tópicos paralelos, código en N módulos).

Tradeoff:

• ✅ Paralelismo real.
• ❌ Coordinación cuesta. Manager necesita ventana grande de contexto.
• ❌ Cuando subtasks son interdependientes, manager se vuelve cuello de botella.

Pattern 5 · Adversarial / red team

Un agente genera, otro intenta romper. Iterativo hasta estabilizar.

Cuándo vale: producir output robusto (código con edge cases cubiertos, texto sin ambigüedad legal).

Tradeoff:

• ✅ Output final mucho mejor que single-agent.
• ❌ Iteraciones infinitas si design ruin. Time-box obligatorio.

Pattern 6 · Single agent con advisor escalation

Un agente principal. Adviser (otro modelo) consultado cuando confidence baja o stakes altos.

Cuándo vale: la mayoría de los casos. Ese es el pattern de HES.

Tradeoff:

• ✅ Simplicidad. Advisor max_uses=1 por interacción controla costo.
• ✅ Cubre 80% del valor de multi-agent con fracción del overhead.
• ❌ No cubre tasks que necesitan paralelismo real.

Ese es nuestro pattern default (literal).

El anti-pattern: “crew” para todo

Frameworks como CrewAI popularizan “delegate tasks to a crew of specialized agents”. En producción real, vemos:

• 5 agentes consumiendo 5× los tokens para entregar lo que 1 entregaría.
• Bug en un agente cascada para los otros (vector 5 de la Prompt Infection Taxonomy).
• Debugging se vuelve pesadilla (¿qué agente erró?).

Heurística: empieza con 1 agente. Agrega segundo solo cuando demuestre cuello de botella específico que descomposición resuelve.

Cost matrix (estimativa relativa)

Pattern	Tokens	Latencia	Complejidad
Single agent	1×	1×	Baja
Single + advisor (raro)	1.5×	1.5×	Media
Sequential pipeline	3×	3×	Media
Specialist routing	1.5-2×	1.5×	Alta
Debate (3 agents)	3×	2×	Alta
Hierarchical	2-5×	2-3×	Muy alta
Adversarial loop	2-10×	2-5×	Muy alta

Dónde profundizar

Para el framework de delegación (qué tarea delegar a qué agente): Agent Trust Stack. Para safety en multi-agent (cross-agent propagation): Prompt Infection Taxonomy.