Un subagente no es paralelismo gratuito ni una forma de hacer que Claude Code "piense mejor" — es una herramienta específica para aislar contexto cuando una tarea intermedia generaría demasiado ruido en la conversación principal.
Un subagente en Claude Code es una instancia separada del agente, con su propio prompt de sistema, su propio conjunto restringido de herramientas, y — crucialmente — su propio contexto aislado de la conversación principal. Cuando el agente principal delega una tarea a un subagente, este ejecuta su trabajo de forma independiente (leyendo archivos, ejecutando comandos, razonando sobre el problema) y al finalizar devuelve solo un resumen al agente principal, no el detalle completo de cada paso intermedio que tomó.
Esto es fundamentalmente distinto de simplemente "pedirle a Claude que haga varias cosas en la misma conversación" — la diferencia está en qué contexto persiste. Sin subagentes, cada archivo leído, cada comando ejecutado y cada iteración de depuración queda en el historial de la conversación principal, consumiendo espacio de contexto y, en conversaciones largas, aumentando el riesgo de que información relevante se diluya entre ruido operativo.
El error conceptual más común es pensar en subagentes como una forma de "acelerar" el trabajo mediante paralelismo. Aunque es cierto que múltiples subagentes pueden ejecutarse en tareas independientes, la razón principal para usarlos no es la velocidad — es evitar que el detalle de una tarea secundaria contamine el contexto de la tarea principal.
Un ejemplo concreto: si le pides a Claude Code "implementa el endpoint de pago y revisa que no haya vulnerabilidades de seguridad en el módulo de autenticación", la revisión de seguridad puede implicar leer una decena de archivos, razonar sobre varios vectores de ataque, y descartar la mayoría de ellos como no aplicables. Todo ese proceso de exploración no aporta valor si queda en el contexto principal — lo que importa es el hallazgo final. Delegar esa revisión a un subagente significa que el agente principal solo recibe "se encontró una vulnerabilidad de inyección SQL en la línea 84 de auth.py", sin el detalle de las quince líneas que se descartaron en el camino.
Delegar tiene un costo: cada subagente empieza sin el contexto acumulado de la conversación principal, así que si la tarea depende fuertemente de decisiones o descubrimientos ya hechos en la sesión actual, hay que comunicárselos explícitamente en la instrucción de delegación — el subagente no los infiere solo. Para tareas cortas y secuenciales donde el siguiente paso depende directamente del resultado inmediato anterior (por ejemplo, "lee este archivo, ahora edítalo, ahora corre el test correspondiente"), delegar añade overhead de coordinación sin beneficio real: es más simple y más rápido que el agente principal lo haga directamente.
La heurística práctica: usa subagentes para líneas de trabajo paralelas o independientes entre sí (revisar múltiples módulos no relacionados, correr distintas suites de test), y trabajo directo para operaciones secuenciales de un solo archivo o un flujo estrictamente lineal.
Un subagente puede — y en la mayoría de los casos debería — tener un conjunto de herramientas más restringido que el agente principal. Un subagente de "revisión de código" probablemente solo necesita Read y Grep, sin acceso a Bash ni a Edit — no debería poder modificar el código que está revisando. Esta restricción no es solo buena práctica de seguridad; también reduce el espacio de decisiones del subagente, haciéndolo más predecible y enfocado en la tarea específica que se le delegó.
Cada subagente invocado implica su propia llamada al modelo con su propio consumo de tokens — delegar no es gratis. Para tareas triviales, el overhead de iniciar un subagente (definir el contexto de la tarea, esperar su ejecución completa, procesar el resumen devuelto) puede superar el beneficio de aislamiento de contexto que se buscaba. La regla práctica es reservar la delegación para tareas donde el trabajo intermedio sería genuinamente voluminoso o donde el aislamiento de responsabilidad (que un subagente de revisión no pueda editar código, por ejemplo) aporta una garantía de seguridad que vale la pena por sí misma.
Al introducir subagentes en un flujo de trabajo de equipo, conviene empezar con dos o tres roles bien definidos y de alto valor — por ejemplo, un subagente de revisión de seguridad, uno de ejecución y diagnóstico de tests, y uno de investigación de documentación externa — en vez de fragmentar cada tarea posible en su propio subagente. Medir cuánto contexto se ahorra y cuánto tiempo total toma la tarea completa (delegación incluida) frente a hacerlo todo en la conversación principal es la forma más confiable de decidir si vale la pena expandir el patrón a más roles dentro del equipo.
Carlos Montiel es arquitecto de soluciones IA empresarial. Implementa LLMs, Agentes, RAG y orquestadores en empresas de Guatemala y Latinoamérica. Contáctalo para una consultoría.
Contactar a Carlos Montiel