Multiagent en CC v2.1.130: lead delega a specialists

El cambio que importa en v2.1.130

La versión 2.1.130 de Claude Code estabilizó el patrón lead agent + specialists: un agente principal recibe la tarea, la descompone, delega subtareas a agentes especializados que corren en paralelo, y reúne los resultados. No es revolucionario; es lo que ya hacías con scripts y subprocess, pero ahora con tool calls de primera clase y un protocolo de comunicación que el modelo entiende. Lo que realmente cambió es que ya no necesitas el truco de "agente que invoca a Claude vía CLI": el harness expone Task como herramienta nativa.

Agent vs subagent: la distinción que confunde

• Agent: autónomo, decide qué herramientas usar, tiene su propio loop. Es el lead.
• Subagent (Task): recibe una tarea acotada, ejecuta, devuelve un resultado estructurado, termina. No mantiene conversación, no decide pivotear.

El error común: tratar al subagent como un agente más con menos privilegios. Si necesitas conversación iterativa, no es subagent. Si la tarea es "busca todos los archivos que cumplen X y devuélveme la lista", sí lo es.

El filesystem como bus de comunicación

Cuando lead y specialists comparten cwd, el filesystem es el protocolo: el lead escribe .tasks/research.md, lanza specialists que leen ese archivo y escriben .tasks/research-findings-id.md, y el lead consolida. Más confiable que pasar todo por argumentos: sobrevive a context limits, queda como log, y permite specialists que se ejecutan en sesiones distintas. Patrón que funciona en producción:

// Lead agent
const subtasks = [
  { id: "schema", prompt: "Audita el schema de Prisma..." },
  { id: "api", prompt: "Audita los controllers del módulo CRM..." },
  { id: "frontend", prompt: "Audita los componentes en app/crm/..." }
];

await Promise.all(subtasks.map(t =>
  invokeTask({
    description: t.id,
    prompt: t.prompt + " Escribe hallazgos a .tasks/audit-" + t.id + ".md",
    subagent_type: "code-reviewer"
  })
));

// Lead reads .tasks/audit-*.md y produce el reporte final

Cuándo el costo de coordinar vence al serial

La intuición engaña aquí. Tres specialists en paralelo no son tres veces más rápidos: hay overhead de spawn (~2-4s por subagent), context independiente (cada uno relee archivos), y consolidación final. La regla práctica:

• Sub-30 segundos por subtarea, tarea total < 1 minuto: hazlo serial. El overhead te come la ganancia.
• Subtareas independientes de 2-10 minutos cada una: paraleliza. Aquí está el sweet spot.
• Subtareas que comparten estado mutable: serial obligatorio. Dos specialists editando el mismo archivo es un desastre.

El anti-patrón: "un agente para todo"

El patrón degenerado más común es crear specialists para cosas que no son specialists, solo para "tener arquitectura". file-reader-agent que solo lee archivos. commit-agent que solo hace git commit. Estos no son specialists; son herramientas con disfraz de agente, y le cuestan al lead el doble de tokens y el doble de latencia.

Un specialist genuino tiene: (a) un dominio donde sabe más que el lead (porque tiene un system prompt especializado), (b) una tarea que se beneficia de contexto fresco (sin el ruido de la conversación del lead), o (c) una latencia que paraleliza con otras subtareas. Si no cumple ninguna de las tres, es ruido.

El patrón que sí paga

Auditorías de codebase grandes: lead descompone por módulo, lanza un specialist code-reviewer por módulo (en paralelo), cada uno escribe hallazgos, lead consolida y prioriza. Un audit que tomaba 25 minutos serial baja a 8 minutos. Las dependencias entre módulos las maneja el lead en la consolidación, no los specialists.

Lo que sigue rompiendo

• Specialists que llaman a specialists: dos niveles funcionan, tres ya son inestables. Mantén plano.
• Compartir context entre specialists: no hay shared memory. Si necesitas que B vea lo que descubrió A, A escribe a disco y B lee.
• Errores silenciosos: si un specialist falla, el lead no siempre se entera bien. Loguea explícitamente exit status y verifica los archivos esperados antes de consolidar.

La pregunta correcta no es "¿debería usar multiagent?", es "¿esta tarea tiene tres subtareas verdaderamente independientes de minutos cada una?". Si no, el código serial es más rápido y más debugeable. ¿En tu próximo audit tienes ese perfil de carga?