Multi-agente es la palabra de moda que todos pegan en una slide. También es donde Claude Code se vuelve realmente interesante — usado quirúrgicamente.

La forma que funciona: un pequeño pipeline de sub-agentes acotados, cada uno haciendo una sola cosa, con un handoff explícito. La forma que falla: "enjambre de agentes debatiendo la arquitectura".

Vamos a lo táctico.

Los tres patrones que sí entregan

1. Pipeline lineal (el pan de cada día)

test-writer  →  test-fixer  →  code-reviewer  →  release-bot

Cada paso tiene una entrada y una salida. Los fallos detienen el pipeline. Es el 80 % de lo que usan los equipos.

2. Fan-out / fan-in

Cuando una tarea es naturalmente paralela — traducir 5 archivos, generar tests para 12 módulos, escanear logs de 8 servicios — abánicala.

            ┌─ translator(es) ─┐
            ├─ translator(fr) ─┤
spawner ──> ├─ translator(ar) ─┤── merger
            ├─ translator(pt) ─┤
            └─ translator(de) ─┘

Lanzas N sub-agentes especializados en paralelo y un sub-agente merger reconcilia las salidas (deduplica, escoge la variante con más confianza, escribe un único PR).

3. Bucle de crítico

writer  ↔  critic

El writer produce. El crítico puntúa contra una rúbrica. El writer revisa. Para cuando el crítico supera un umbral o tras N rondas.

Brilla para:

• Reescrituras de docs.
• Planes de migración.
• Propuestas de refactor donde "¿está limpio?" es la puerta.

El crítico debe ser un sub-agente distinto del writer. Mismo agente autocriticándose, teatro.

Donde multi-agente deja de pagar

Tras un año, mi opinión honesta sobre los rendimientos decrecientes:

• 2 agentes: gran salto. Writer + reviewer es un win real.
• 3-4 agentes: útil para pipelines claros (test-writer → fixer → reviewer).
• 5+ agentes: marginal en el mejor caso. Coste de coordinación > ganancia de delegación.
• "Enjambre de 10 agentes debatiendo": una demo, no un workflow.

Si tu pipeline tiene más de 4 sub-agentes, pregúntate si la mitad podría ser un comando shell o un target Makefile.

Concreto: un pipeline "PR factory"

Objetivo: tomar un ticket de Linear, entregar un PR.

1. ticket-reader     → parsea el ticket de Linear, devuelve un prompt /feature
2. implementer       → escribe el código
3. test-writer       → escribe / actualiza tests
4. test-fixer        → si algún test falla, arregla el código (no el test)
5. code-reviewer     → revisa el diff, SHIP / FIX-FIRST / REWRITE
6. release-bot       → redacta descripción de PR + entrada de changelog
7. (humano)          → revisa el diff y empuja

Cada paso es un sub-agente en .claude/agents/. El paso humano final no es negociable — ahí ocurre git push.

Tiempo de ejecución en una feature típica: 4-12 minutos de wall clock. Revisión humana al final: 5-15 minutos. De punta a punta: una feature por hora, sostenible.

Cómo invocar un pipeline en la práctica

Dos sabores.

Paso a paso manual (recomendado al principio)

> /agents implementer
> Objetivo: ... Restricciones: ... DoD: ... Archivos: ...

# espera, revisa

> /agents test-writer
> Escribe tests para el nuevo código.

# espera, revisa

> /agents code-reviewer
> Revisa el diff.

Mantienes el control. Lento pero seguro.

Orquestado vía slash command

.claude/commands/pr-factory.md:

1. Lanza `implementer` con el objetivo del usuario.
2. Espera a que termine. Si implementer falla, aborta.
3. Lanza `test-writer` sobre el diff.
4. Lanza `test-fixer` hasta que los tests pasen o tras 3 reintentos.
5. Lanza `code-reviewer` sobre el diff final.
6. Si veredicto != SHIP, eleva al usuario y para.
7. Si no, lanza `release-bot` para descripción de PR.
8. Imprime un resumen de una línea y para. Nunca empujes.

Después:

> /pr-factory
> Objetivo: <rellenar> Restricciones: <rellenar> DoD: <rellenar> Archivos: <rellenar>

Pulsas un solo comando. El pipeline corre. El push sigue siendo una pulsación humana.

Patrones paralelos — cuándo usarlos

Corre agentes en paralelo cuando:

• El trabajo es independiente (traducir 5 archivos, resumir 8 PRs).
• Puedes escribir un merger determinista (concat, dedup, pick-highest-score).
• Puedes presupuestar el coste (paralelo = más llamadas API, menos wall clock).

Evita el paralelo cuando:

• Las tareas tienen dependencias (test-fixer necesita el diff del implementer).
• El paso de merge es difuso ("¿qué arquitectura nos gusta más?"). Eso no es merge — es decisión humana.

El truco más útil: handoffs explícitos

Cada sub-agente termina su turno emitiendo un handoff estructurado:

status: ok | needs-human | failed
artifacts:
  - path: src/cache.ts
  - path: tests/cache.test.ts
notes: "Implementado LRU + TTL. Todos los tests verdes."
next: test-writer | code-reviewer | done

El siguiente agente lee este handoff y sabe exactamente dónde está. Sin volver a deducir contexto, sin "espera, ¿cuál era el objetivo?".

Estandarizar el handoff es la palanca más alta cuando tienes 3+ sub-agentes. Es el equivalente multi-agente de una firma de función bien tipada.

---

Próximo artículo: Construir features completas — tomar todo lo de aquí y de los artículos 3-7 y recorrer una sesión real de ticket-a-PR, comando a comando.