Subagentes de Claude Code: para qué sirven y cómo se usan

Los subagentes suenan a exceso. Varios Claude trabajando a la vez sobre el mismo proyecto, cada uno con su tarea, mientras tú miras.

Yo pensaba lo mismo hasta que los usé en un trabajo largo de verdad. Ahí cambia la cosa, y no por la velocidad, que también, sino por algo menos evidente que te cuento abajo.

Esto es lo que son, cuándo compensan y cómo se montan sin liarte.

¿Para qué sirven los subagentes de Claude Code?

Un subagente es una copia de Claude que trabaja en una tarea concreta, con sus propias instrucciones y, esto es lo importante, con su propia conversación aparte.

Sirven para dos cosas.

La primera es obvia: hacer varias cosas a la vez. Si tienes que escribir cinco documentos independientes, en vez de escribirlos uno detrás de otro, lanzas cinco subagentes y los escriben en paralelo.

La segunda es la que de verdad importa: no ensuciar tu conversación principal. Cuando le pides a Claude que revise cuarenta archivos, esos cuarenta archivos se le quedan metidos en la cabeza y a partir de ahí razona peor y más lento. Si lo hace un subagente, lo que vuelve a tu conversación es solo la conclusión. El montón de basura se queda fuera.

Esa segunda razón es la que hace que los use a diario, y es la que casi nadie cuenta.

¿Cuándo compensa y cuándo no?

Compensa cuando la tarea es larga y el resultado es corto. Buscar algo entre muchos archivos, revisar un montón de documentos, investigar un tema y devolver un resumen.

Compensa cuando hay trabajo repetitivo e independiente. Cinco cosas parecidas que no dependen unas de otras.

No compensa para tareas cortas. Lanzar un subagente tiene un coste de arranque: hay que explicarle todo el contexto desde cero porque no ha visto vuestra conversación. Para algo de dos minutos, tardas más en explicárselo que en hacerlo.

Y no compensa cuando las tareas dependen entre sí. Si el segundo trabajo necesita el resultado del primero, no hay paralelismo posible por mucho que te empeñes.

Cómo se lanza uno, en la práctica

En la conversación normal, se lo pides en español. Literalmente: "lanza un subagente que revise todos los archivos de esta carpeta y me diga cuáles están sin terminar".

Si quieres varios a la vez, se lo dices igual de claro: "lanza cinco subagentes en paralelo, uno por cada documento de esta lista, y que cada uno escriba su archivo".

Lo que hace la diferencia entre que salga bien o mal es cómo escribes el encargo. Un subagente no ha visto nada de lo que habéis hablado tú y Claude antes. Empieza en blanco.

Por eso el encargo tiene que llevar tres cosas:

1. Qué archivos tiene que leer, con la ruta exacta. Si no se lo dices, se pone a buscar y se va por las ramas. 2. Qué tiene que hacer, concreto, sin ambigüedad. 3. Qué tiene que devolver y dónde. Si escribe un archivo, la ruta. Si devuelve un resumen, qué debe contener.

Sin eso, tienes cinco subagentes haciendo cinco cosas distintas de lo que querías.

Subagentes con personalidad fija

Además de lanzarlos al vuelo, se pueden dejar definidos. Son archivos de configuración dentro de tu proyecto donde describes un tipo de subagente: qué hace, con qué tono, qué archivos carga siempre y qué herramientas puede usar.

Yo tengo definidos varios así, y los llamo por su nombre. Uno que escribe, otro que revisa, otro que busca. Cada uno con sus instrucciones fijas, que no tengo que repetir cada vez.

Es la misma idea que hay detrás de crear tus propias skills para ahorrar horas: lo que repites tres veces, se escribe una vez y se deja guardado.

Lo que se te va a atascar

Se pisan entre ellos. Si lanzas cinco subagentes y dos tocan el mismo archivo, la lías. Regla que no me salto: cada subagente escribe en su propio archivo. Luego uniré yo, o lo unirá la conversación principal.

No saben nada de tu contexto. Este es el fallo más común. Das por hecho que sabe cómo escribes, qué proyecto es, qué decidisteis ayer. No lo sabe. Si el resultado sale genérico, casi siempre es por esto: le faltaba contexto en el encargo.

Gastan bastante. Cada subagente consume por su cuenta. Cinco en paralelo gastan como cinco conversaciones. Si tienes plan limitado, mide antes de lanzar tandas grandes.

El informe que devuelven puede ser larguísimo. Si no le dices qué quieres de vuelta, te devuelve una parrafada que te llena la conversación principal, que es justo lo que querías evitar. Pídele explícitamente un informe de tres líneas.

Cuesta seguirles la pista. Cuando hay varios trabajando, no ves lo que hace cada uno en detalle. Es incómodo al principio. Se lleva mejor si el encargo es tan claro que no necesitas mirar.

¿Y esto para qué sirve si no programo?

Para lo mismo, cambiando el tipo de trabajo.

Revisar una carpeta entera de notas y decirte qué está sin terminar. Escribir varios textos independientes a la vez. Repasar una documentación larga y sacar solo lo que te interesa. Comparar diez documentos entre sí.

Cualquier cosa que sea "muchos archivos, poca conclusión" es candidata perfecta. Y si tu proyecto ya es grande, esto conecta directamente con el problema de manejar el contexto en proyectos grandes, que es el techo real de trabajar así.

Un ejemplo completo, con las frases exactas

Para que se vea el mecanismo, un caso real de trabajo largo: quince documentos que hay que escribir siguiendo el mismo criterio.

Primero preparo el terreno en la conversación principal. Escribo un archivo con las instrucciones comunes: qué tono, qué estructura, qué hay que leer antes de escribir. Eso lo hago una vez.

Luego reparto el trabajo en un archivo por tanda, con las filas que le tocan a cada uno.

Y entonces lanzo: "lanza tres subagentes en paralelo. Cada uno lee el archivo de instrucciones comunes y su propio archivo de encargo. Cada uno escribe sus documentos en su carpeta. Que me devuelva cada uno un informe de tres líneas: qué ha escrito, qué no ha podido y por qué".

Fíjate en lo que hay ahí y que no es casualidad: instrucciones comunes en un sitio, encargos separados, carpetas separadas y formato de respuesta acotado.

Sin esas cuatro cosas, lo que vuelve es un caos que tardas más en ordenar que en haberlo hecho tú.

Cuánto se gana de verdad

No es que vaya tres veces más rápido. Nunca es tan limpio.

Lo que ganas es que el trabajo largo deja de ser una sola conversación interminable que se va degradando. Cada pieza se hace en fresco, con la cabeza limpia, y tú te quedas con la parte de decidir y revisar.

Eso, en trabajos de varias horas, se nota más en la calidad del final que en el reloj. La última pieza sale igual de bien que la primera, y cuando lo haces todo seguido en una sola conversación, eso no pasa nunca.

Y ahora qué

Prueba una vez, con algo pequeño y real. Coge una carpeta tuya con muchos archivos y pide: "lanza un subagente que lea todo esto y me devuelva en cinco líneas qué hay aquí dentro".

Vas a ver dos cosas: que la respuesta llega limpia y que tu conversación principal sigue igual de fresca que antes. Ese es todo el truco. Si te has quedado atrás en lo básico, empieza por la guía de Claude Code para no programadores y vuelve a esto después.

Trabajar así, con varias piezas moviéndose a la vez sin que se te caiga nada, es de lo que va Yo SA: montar una estructura de empresa siendo una sola persona.

Ver Yo SA