6. Delegación Multi-Agent — qué compartir y qué quedarse

Esta es la parte 6 de la serie Alice Way. Hasta la parte 5 Hooks y automatización, la serie cubrió cómo diseñar la mente de un colaborador. Este artículo trata de una estructura donde ese único colaborador no lo hace todo: cómo distribuir la mente lateralmente.

0. Delegar es dividir la mente para que un contexto no lo lleve todo

Asignar cada tarea a un único colaborador llena rápido su context window. Una vez llena, la calidad de las decisiones baja. Esa caída obliga al operador a verificar todo cada vez. La carga mental del operador vuelve a subir.

La delegación rompe este ciclo. Las tareas grandes se dividen y se delegan a Subagents; el principal solo recibe un resumen de cada resultado. Cada Subagent se enfoca en una sola cosa con su propio contexto. El contexto del principal se mantiene lleno únicamente con lo que la decisión necesita.

La delegación tiene costes: hay que escribir un informe, verificar el resultado e integrarlo. Si las ganancias de la distribución no superan esos costes, delegar es una pérdida neta.

Este artículo es un registro de qué trabajo vale la pena delegar, cómo construir puertas que hagan rendir cuentas a la delegación, y las trampas que evitar.

El mecanismo de Subagent en sí está tomado del sistema de Subagents de Anthropic Claude Code. Este artículo es un registro de cómo se usa ese mecanismo, no una invención del mismo.

1. La división principal-Subagent — quién lleva qué

La división que encontré.

El núcleo: el principal lleva autoridad de decisión y memoria; el Subagent lleva el trabajo y el contexto profundo. Nunca llevan lo mismo. La superposición es contexto desperdiciado.

La forma más común en que esta división se rompe: el principal intenta conocer cada detalle del trabajo del Subagent. El contexto del principal se llena y la razón de tener un Subagent desaparece.

El principal tiene que saber qué no sabe. La parte desconocida la mantiene el sub.

2. Qué es delegable — cinco condiciones

No todo el trabajo es delegable. Solo el trabajo que pasa todos estos cinco baja a un sub.

2.1 ¿Es cerrada la entrada?

Un Subagent recibe una porción del contexto del principal de una sola vez. Las conversaciones bidireccionales a mitad de tarea del tipo "cuéntame más sobre X" son difíciles. Todo lo necesario al inicio tiene que estar cerrado dentro del informe.

Si la entrada no está cerrada, el Subagent la rellena con suposiciones. Las suposiciones a menudo fallan.

2.2 ¿Puede resumirse la salida?

Cuando el resultado del Subagent vuelve al contexto principal, solo el resumen debe entrar. Si el resultado es intrínsecamente largo y no puede resumirse — por ejemplo "revisar los 100 archivos" — el valor de delegar se reduce. El principal termina absorbiendo un resumen de 100 archivos de todas formas.

2.3 ¿La autoridad de decisión permanece con el principal?

El Subagent no debe entrar en el territorio de decisión del operador a mitad de tarea. "¿Puedo cambiar el esquema de BD?" no es algo que el Subagent decide. Si pueden surgir tales decisiones a mitad de tarea, hay que pre-declarar la tabla de autoridad en el informe o diseñar el Subagent para que se detenga y reporte en los puntos de decisión.

2.4 ¿Es automatizable la verificación?

Si el operador tiene que verificar manualmente el resultado del Subagent en cada ocasión, la ganancia de la delegación desaparece. Solo es delegable el trabajo que incluye un script de verificación automatizado. (Ver §4 sobre puertas.)

2.5 ¿Está enfocado en una cosa?

Un Subagent hace una sola cosa. El trabajo compuesto como "refactorizar este componente + añadir tests + actualizar docs" no se delega como un bloque. Se divide en tres y se envía a tres Subagents distintos. Un único Subagent que lleva múltiples cosas produce contexto enredado y salida vaga.

3. El coste de la delegación — cuándo es mejor hacerlo directamente

La delegación no siempre tiene saldo positivo. El coste en resumen.

• Coste de escribir el informe — poner qué / por qué / cómo / dónde detenerse por escrito
• Coste de preparar el contexto — extraer solo lo que el Subagent necesita y entregárselo
• Coste de verificación — verificaciones automatizadas + re-confirmación del principal para confiar en el resultado
• Coste de integración — absorber el resultado de vuelta en el contexto principal

La suma de estos cuatro costes debe ser menor que el coste de hacerlo directamente para que la delegación resulte rentable. En la práctica: el trabajo que termina en menos de 30 minutos pierde con la delegación; el trabajo que lleva 2+ horas o toca 5+ archivos gana con ella.

La delegación que ignora el tamaño de la tarea no es delegación — es simplemente transferir la culpa.

4. La puerta de delegación — aplicar la promesa en código

La forma más común en que la delegación falla: se escribe el informe pero se omiten la verificación y la puerta de merge. El desvío entre la promesa y el resultado se acumula y solo sale a la luz mucho más tarde.

Tras haber sufrido este patrón una vez, ahora siempre agrupo las tres piezas en el mismo PR para cualquier delegación.

4.1 El informe de delegación

Un documento que especifica qué / por qué / cómo / dónde detenerse. El Subagent lo lee una vez antes de empezar. El informe incluye:

• Objetivo y Definición de Hecho
• Entradas (extraídas del contexto principal)
• Formato de salida (qué archivos, qué estructura)
• Tabla de autoridad de decisión (autónomo / reportar al principal / prohibido)
• Método de verificación (script automatizado nombrado)
• Puerta de merge (qué debe pasar en CI antes del merge)

4.2 El script de verificación automatizada

Para que los humanos no tengan que verificar manualmente cada resultado se incluye un script ejecutable. Para la delegación de "refactorizar componente X," algo como npm run verify:component-x se añade en el mismo PR que el informe.

Un informe sin script de verificación no es un informe. Es solo una expresión de intención.

4.3 La puerta de merge

El script de verificación se ejecuta en CI, y el merge se bloquea si no pasa. Verificar una promesa sin configurar una puerta hace que tarde o temprano algo se mergee sin que la verificación se haya ejecutado nunca.

Las tres piezas (informe + verificación + puerta) se mueven juntas. Omitir cualquiera de ellas hace que la promesa deje de aplicarse en código, y la promesa se rompe.

Si una promesa no se aplica en código, el desvío se acumula.

5. Delegaciones en rotación real

Un subconjunto de lo que delego semanalmente.

5.1 Exploración amplia del código base

"Encuentra cada lugar donde se usa la palabra clave X y cómo" — a un Subagent. El Subagent peina todo el repositorio con grep/glob/find y escribe los resultados. El principal solo recibe el informe.

Si el principal hace esto directamente, cientos de coincidencias llenan su contexto y no queda espacio para decisiones.

5.2 Ejecuciones de build · test

"Ejecuta lint + build + test en este cambio y resume" — también a un Subagent. El Subagent absorbe la salida completa; el principal solo recibe un resumen del tipo "pasó" / "falló (3, primeras dos líneas: ...)".

5.3 Revisiones

"Revisa este PR desde el ángulo de seguridad" — el Subagent lee todo y escribe una lista de problemas. El principal solo recibe el recuento y los tres más importantes.

5.4 Investigación externa amplia

"Problemas de seguridad conocidos con esta biblioteca y alternativas" — investigación externa. El Subagent recopila de múltiples fuentes y redacta un informe. El principal absorbe solo el resumen necesario para la decisión.

5.5 El efecto acumulado

Los ahorros de contexto por tarea son pequeños. Pero cuando ocurren 5–6 delegaciones diariamente, el contexto principal permanece en modo solo-decisiones todo el día. El formato de reporte que ve el operador se vuelve consistente, y los patrones del tipo "el principal está confundido porque lleva demasiado" desaparecen.

6. Trampas — patrones donde falla la delegación

Patrones de fallo que he experimentado al menos una vez.

6.1 Delegación no verificada

La trampa más común. Se escribe el informe, se delega. El resultado vuelve sin forma de verificarlo, por lo que hay comprobación manual en cada ocasión. Toda la ganancia, perdida. → La puerta de tres piezas del §4 es la respuesta.

6.2 Delegación de entrada abierta

"Maneja esto como quieras" — el Subagent rellena con suposiciones, y las suposiciones fallan. → Mantener el informe cerrado aunque sea breve.

6.3 Autoridad borrosa

El Subagent llega a "¿debería cambiar esto?" a mitad del trabajo y procede con su propio juicio. El operador ve resultados que divergen de la intención. → Tabla de autoridad en el informe + patrón de detener-y-reportar en los puntos de decisión.

6.4 Delegación sobre-fragmentada

Delegar tareas de cinco minutos. El coste de escribir el informe supera la propia tarea. Es más rápido hacerlo directamente. → Sin delegación para trabajos de menos de 30 minutos.

6.5 Ignorar el coste de integración

Resultados de Subagents difíciles de integrar a la vez. Cinco Subagents tocando archivos distintos simultáneamente y colisionando. → Pre-particionar las áreas de trabajo de los Subagents en el informe para que no se superpongan.

7. El flujo de decisión delegar-vs-directo

El flujo de decisión que ejecuto mentalmente cuando llega nuevo trabajo.

nuevo trabajo
  ↓
¿menos de 30 min? → sí → directo
  ↓ no
¿entrada cerrada? → no → directo (o preparar entrada primero)
  ↓ sí
¿verificación automatizable? → no → directo (demasiado arriesgado)
  ↓ sí
¿una sola cosa? → no → dividir, delegar cada una
  ↓ sí
→ delegar (agrupar informe + script de verificación + puerta de merge)

Cuando este flujo está interiorizado, la decisión de delegar-vs-directo es rápida. Sin deliberación nueva cada vez.

8. Comprimido en un principio

El núcleo del diseño de delegación se resume en una oración.

"El principal lleva decisiones y memoria; el Subagent lleva trabajo y contexto profundo. La delegación siempre incluye informe + verificación + puerta como un solo paquete."

Cuando esto se cumple, la delegación se convierte en un acelerador que mantiene el contexto principal en modo de decisión. Cuando se rompe, la delegación se convierte en transferencia de responsabilidad y la integración de resultados pasa a ser la carga recurrente del operador.

El siguiente artículo cubre el dispositivo que comprueba si el trabajo delegado (y el directo) está realmente "listo" cuando dice estarlo: bucles de verificación, es decir, cómo fijar la definición de "listo" para el trabajo de código.