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.

¿Cuándo conviene migrar de scripts seriales al modelo lead-specialist nativo?

Conviene migrar cuando el tiempo acumulado de ejecución serial supera los diez minutos y las tareas analizan repositorios sin compartir dependencias de escritura en caliente. Si las subtareas son idempotentes y leen rutas separadas, la reducción de latencia compensa el overhead de invocación de Anthropic sin disparar los costos de red.

Para determinar la viabilidad técnica, comparemos los tres enfoques de orquestación más recurrentes en ingeniería de software:

Esquema de ejecución	Latencia de inicio	Aislamiento de contexto	Tolerancia a fallos	Caso de uso recomendado
Monolítico serial	Nula (sesión continua)	Nulo (context pollution alto)	Baja (un error aborta el flujo)	Refactorizaciones guiadas paso a paso en un solo módulo.
Hacks vía subprocess CLI	Alta (~6-12 segundos)	Total (procesos de OS separados)	Media (depende de exit codes de shell)	Pipelines legados de CI/CD sin soporte para tool calling.
Lead + Specialists (v2.1.130)	Baja (~2-4 segundos)	Total por Task instanciada	Alta (reporte granular al lead)	Auditorías masivas, linting contextual y migración de APIs.

Impacto financiero y operativo para equipos en América Latina

Para las empresas de desarrollo en México, Colombia, Argentina y el resto de la región, la adopción de arquitecturas multiagente implica un análisis riguroso de costos de API frente a horas de ingeniería. De acuerdo con la estructura tarifaria oficial de Anthropic para Claude 3.5 Sonnet, el costo se sitúa en 3.00 USD por millón de tokens de entrada y 15.00 USD por millón de tokens de salida. Al disparar tres subagentes en paralelo, el volumen de tokens de entrada se triplica durante la lectura inicial de las definiciones del proyecto.

Sin embargo, según mediciones del reporte anual de State of DevOps de DORA, reducir los tiempos de retroalimentación en tareas de revisión de código de 30 minutos a menos de 10 minutos disminuye las tasas de retrabajo en un 22%. Cuando el costo del tiempo de un desarrollador senior en la región ronda entre 25 y 45 USD por hora, quemar 0.30 USD adicionales en tokens por cada auditoría paralela no solo es justificable, sino que genera un ahorro neto de horas facturables. El cuello de botella real no es el gasto del modelo, sino la latencia de red: los enlaces transfronterizos hacia los centros de datos en Estados Unidos (us-east-1) agregan entre 120 y 180 milisegundos de handshake por cada conexión concurrente, por lo que paralelizar llamadas evita que esa latencia se sume de manera lineal.

Implementación defensiva: qué puede fallar en entornos reales

Al implementar el patrón lead-specialist en repositorios productivos, existen tres riesgos operativos que deben mitigarse desde el diseño del pipeline:

• Race conditions en el filesystem: Si dos subagentes intentan escribir metadatos en un archivo centralizado o actualizar dependencias en package.json de forma simultánea, se producirá corrupción de datos. La regla de oro es asignar directorios de salida únicos mediante UUIDs o IDs deterministas (por ejemplo, .tasks/output-{id}.json).
• Límites de concurrencia de la API (Rate Limits): En cuentas con niveles de consumo iniciales (Tier 1 o Tier 2 de Anthropic), disparar más de cuatro subagentes concurrentes puede detonar errores 429 Too Many Requests. El lead agent debe contar con reintentos con retroceso exponencial (exponential backoff) o limitar la concurrencia a través de una cola controlada.
• Alucinación de completitud: Un specialist puede reportar una tarea como completada simplemente porque el modelo alcanzó su límite de tokens de generación. El lead nunca debe confiar únicamente en el texto devuelto; debe validar programáticamente la existencia y el tamaño de los artefactos generados en disco antes de marcar la subtarea como resuelta.

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?