![Imagen de portada de [Contexto IA #5] Subagentes: aislamiento y delegación](/assets/images/posts/6f12e091-1d37-4258-b659-1070e39916f1/1.jpg)
En las entregas anteriores vimos cómo ahorrar contexto: borrar el historial en cada límite de trabajo (parte 3) y diseñar costes fijos breves (parte 4). Aun así, hay tareas que siguen siendo demasiado grandes. Un ejemplo típico es: «Averigua cómo fluye la lógica de pagos en este código base». Un agente diligente leería decenas de archivos y, como vimos en la parte 1, todo lo leído se acumula en el contexto. Cuando termina la investigación, ya no queda contexto para hacer aquello que ese conocimiento permite: modificar el código.
Esta entrega trata sobre los subagentes, que resuelven el problema de forma estructural. La idea clave es sencilla: no tiene por qué existir una sola ventana de contexto.
Trabajar en otro contexto y traer solo la conclusión
Un subagente es una instancia de agente independiente creada por el agente principal. Lo esencial es que recibe una ventana de contexto nueva y limpia, propia.
El flujo es el siguiente. El agente principal envía a un subagente una sola instrucción: «Investiga y resume cómo fluye la lógica de pagos». El subagente lee decenas de archivos en su propio contexto, busca y sigue las relaciones entre llamadas. Durante el proceso se acumulan decenas de miles de tokens, pero todos pertenecen al contexto del subagente. Al terminar, devuelve un informe ordenado y desaparece. En el contexto principal solo quedan una instrucción y un informe: unos cientos o unos pocos miles de tokens.
Es una estructura organizativa conocida. En lugar de investigar personalmente el mercado, un gerente encarga el trabajo a un investigador y recibe un informe de una página. La clave es que los cien documentos revisados por el investigador no se amontonan en el escritorio del gerente. Su escritorio, es decir, el contexto principal, conserva solo la información necesaria para decidir.
¿Qué tareas conviene delegar?
Las tareas que conviene delegar tienen algo en común: el proceso es pesado y la conclusión, ligera.
Primero, la exploración y la investigación. Tareas como «todos los lugares donde se usa esta función» o «comprender el código relacionado con este error» requieren leer mucho, pero la respuesta final es solo una lista o un resumen. Son tareas típicas para un subagente. Claude Code ofrece agentes específicos para exploración por la misma razón.
Segundo, las tareas que pueden dividirse en paralelo. Si hay que analizar cinco módulos, cinco subagentes pueden hacerlo simultáneamente, cada uno en su propio contexto. No solo se reduce el tiempo: también se evita que sus resultados intermedios se mezclen en un único contexto y generen confusión.
Tercero, aunque de otra naturaleza, las tareas que necesitan una perspectiva nueva. La revisión de código es el ejemplo más claro. El contexto del agente principal que acaba de escribir el código está lleno de supuestos de implementación y pruebas fallidas. Si revisa su propio código en ese estado, es fácil que quede atrapado en sus supuestos y sea demasiado indulgente. Si entregas solo el código a un subagente sin contexto, lo verá con los ojos de un revisor desconocido. Aquí, el aislamiento no ahorra tokens: funciona como un mecanismo de calidad.
Por el contrario, delegar ciertas tareas sale a cuenta negativa. Para trabajos ligeros, como leer uno o dos archivos, el coste de ida y vuelta de la delegación es mayor. Tampoco encajan bien las tareas que dependen mucho del contexto de la conversación. La razón aparece a continuación.
El coste del aislamiento: los subagentes no saben nada
El contexto limpio de un subagente no es gratis. Que esté limpio también significa que no sabe nada de la conversación anterior.
Los supuestos acumulados durante una hora en la sesión principal—el proyecto debe mantener una API heredada, no se deben tocar las pruebas y este es el enfoque que prefiere el usuario—son completamente desconocidos para el subagente. Si no se escriben en la instrucción, no existen. Por eso, la calidad de la delegación converge en la calidad de la instrucción. Debes incluir en una sola instrucción los antecedentes necesarios, las restricciones y el formato deseado del resultado para evitar recibir un informe basado en supuestos equivocados.
La devolución funciona igual. El agente principal solo recibe el informe final del subagente, así que cualquier hallazgo que no aparezca en él desaparece cuando el subagente se marcha. Por eso resulta útil especificar el formato del informe en la instrucción, por ejemplo: «Incluye las evidencias que influyeron en tu juicio y la lista de archivos comprobados». Aquí también reaparece el context poisoning de la parte 2. Si el informe del subagente es impreciso, el error se trasplanta al contexto principal en forma comprimida, y el agente principal tiende a creerlo porque no tiene el original para verificarlo. Cuanto más importante sea la conclusión, más necesario es recibirla junto con sus evidencias.
Resumen
- Un subagente trabaja en un contexto limpio e independiente y devuelve solo la conclusión. La clave es que las decenas de miles de tokens del proceso no entren en el contexto principal.
- Las tareas cuyo proceso es pesado y cuya conclusión es ligera—exploración, investigación y análisis paralelo—son buenas candidatas para delegar. En revisiones y tareas similares, el aislamiento también mejora la calidad al aportar una perspectiva nueva.
- El coste del aislamiento es la ruptura del contexto. Como el subagente no conoce el historial de la conversación, la instrucción debe incluir todos los antecedentes y restricciones relevantes, y el informe debe exigir las evidencias que lo respaldan.
Solo queda una pieza de la serie. /clear hace desaparecer la conversación y el subagente desaparece al terminar la sesión. Pero el proyecto continúa. ¿Dónde debe guardarse el conocimiento que tiene que sobrevivir al final de una sesión? La próxima entrega trata sobre el almacenamiento fuera del contexto: la memoria y la externalización.