Subagentes de Claude Code: cuándo ayudan y cuándo no

Los subagentes de Claude Code se explican normalmente como una forma de ejecutar trabajo en paralelo. Esa es la mitad pequeña de la historia. La grande es el contexto: un subagente lee veinte archivos, explora tres callejones sin salida y devuelve seis líneas. Tu conversación principal nunca ve los otros diecinueve mil tokens.

En cuanto los piensas como cortafuegos de contexto y no como trabajadores extra, se vuelve obvio qué tareas les encajan y cuáles empeoran.

Qué son exactamente los subagentes de Claude Code#

Un subagente es una ejecución separada con su propia ventana de contexto, su propio acceso a herramientas y sus propias instrucciones. Recibe un prompt del agente principal, hace un trabajo acotado y devuelve un informe.

De ahí salen tres consecuencias, y las tres importan:

No ve tu conversación. Solo lo que pongas en el prompt. No conoce las decisiones que tomaste hace una hora.

Su exploración queda contenida. Cada archivo que abrió, cada giro equivocado, cada salida larga de herramienta vive en su contexto y muere con él.

Cuesta tokens dos veces. Una por su trabajo, otra por tu lectura del resumen. Ese es el precio del aislamiento, y en tareas pequeñas no compensa.

Los tres trabajos donde brillan#

Búsqueda amplia. "¿Dónde está implementado este comportamiento en el código?" Un subagente busca, abre candidatos, descarta los que no son y devuelve tres rutas. La alternativa es tu contexto principal llenándose de archivos que no volverás a mencionar.

Revisión independiente. Revisar tu propio trabajo es débil porque el razonamiento que produjo el código produjo también el punto ciego. Un subagente con solo el diff y los estándares no tiene ese ancla. Aquí es donde saco más valor real.

Reparto de trabajo independiente. Varias piezas sin relación entre sí, ejecutándose a la vez, cada una informando. Ahorro real de tiempo de reloj cuando las piezas de verdad no dependen unas de otras.

La forma común: lee mucho, informa poco, no necesita conversación.

Cuándo lo empeoran#

Tareas pequeñas y bien especificadas. Si sabes el archivo y el cambio, un subagente añade arranque, exploración que no necesitabas y un resumen que tienes que leer. Hazlo y ya.

Cualquier cosa que necesite ida y vuelta. Un subagente no puede preguntarte a mitad de tarea. El trabajo que requiere aclaración produce una respuesta segura a la pregunta equivocada.

Tareas que dependen de contexto no dicho. El fallo más común con diferencia. El subagente no sabe que ya descartaste ese enfoque, así que lo propone otra vez, con argumentos.

Trabajo con efectos secundarios, repartido. Varios agentes editando la misma zona a la vez produce conflictos que cuestan más de desenredar que lo que ahorró el paralelismo.

Escribe primero el contrato de retorno#

Antes del prompt, decide qué vuelve. Este único hábito arregla la mayoría de los resultados decepcionantes.

Sé específico: rutas de archivo con número de línea, una lista de hallazgos con severidad, un sí o un no con evidencia. "Investiga X y cuéntame lo que encuentres" devuelve un ensayo que luego tienes que leer y juzgar.

El briefing debería leerse como instrucciones a un profesional competente que nunca ha visto el proyecto:

• Qué es el proyecto, en dos líneas.
• La pregunta concreta, acotada para que se pueda responder.
• Restricciones y decisiones ya tomadas, sobre todo las descartadas.
• La forma exacta de la respuesta que quieres.
• Qué no tocar.

Los prompts vagos son donde el coste en tokens deja de merecer la pena.

Leer lo que vuelve#

Un informe de subagente es una afirmación, no un resultado. Lo produjo una ejecución que no viste, desde archivos que no le viste abrir, y a veces está seguro y equivocado justo de la forma que un buen resumen esconde.

Tres hábitos lo mantienen honesto.

Comprueba los anclajes. Si informa rutas y líneas, abre una. Si el anclaje está mal, desconfía del resto.

Vigila las coberturas. Frases como "parece que" o "probablemente" en un informe que debía dar una respuesta definitiva suelen significar que no encontró lo que pediste y reconstruyó algo plausible.

Acepta los hallazgos negativos. Un subagente que dice "no he encontrado ninguna implementación de esto" es más útil que uno que nombra un archivo con poca confianza, y solo obtienes esa respuesta si tu prompt la permite explícitamente.

Cómo encaja con el resto de Claude Code#

Los subagentes son una de varias formas de controlar contexto y comportamiento, y a menudo no son la correcta.

El archivo de contexto del proyecto lleva lo que toda ejecución necesita: convenciones, comandos, qué no tocar. Es más barato que informar a un subagente cada vez.

Los hooks de Claude Code aplican reglas de forma determinista. Si quieres que se ejecuten los tests siempre, un hook lo hace con fiabilidad y un subagente cuando se acuerda.

Las Claude Skills empaquetan un procedimiento repetible. Si escribes el mismo prompt largo de subagente cada semana, eso debería ser una skill.

Una regla práctica#

Delega cuando la respuesta valga más que la lectura. Esa es toda la heurística.

Si una tarea implica abrir quince archivos para producir una frase, delega. Si implica abrir uno para hacer una edición, no. Si necesitas tres opiniones independientes sobre el mismo diff, lanza tres subagentes con briefings distintos y compara.

Y cuando un subagente devuelva algo que contradice lo que sabes, la culpa casi siempre es del briefing. Añade el contexto que faltaba y vuelve a lanzarlo en vez de discutir con la salida.

La versión corta#

Los subagentes son cortafuegos de contexto que además corren en paralelo. Úsalos para búsquedas amplias, revisiones independientes y trabajo genuinamente paralelo. Escribe el contrato de retorno antes del prompt. Infórmalos como si no supieran nada, porque no lo saben.

Si quieres el flujo completo, qué es Claude Code cubre los fundamentos y mi curso de Claude Code cubre montarlo como sistema de uso diario.