Subagents and Delegation
Subagents and Delegation describe un patrón en el que un agente o runtime asigna trabajo acotado a otra ejecución agente y utiliza su resultado dentro de una responsabilidad más amplia. Un subagent es esa ejecución delegada, con límites de tarea, contexto, herramientas, autoridad, estado y duración definidos por la implementación. No queda definido por una marca de producto ni por utilizar un modelo diferente del agente que lo invoca.
La delegación puede ser secuencial o concurrente. Puede ayudar a separar contexto, especializar una investigación o dividir trabajo con resultados claros. También introduce coordinación y revisión. Utilizar subagentes no demuestra mayor madurez y no convierte automáticamente un problema sencillo en uno que deba distribuirse entre participantes.
Trabajo delegado y responsabilidad
Delegar incluye comunicar objetivo, alcance, restricciones, información pertinente y resultado esperado. El llamador conserva la responsabilidad más amplia de integrar esa contribución en el encargo que recibió. Esa relación no significa que deba conducir cada búsqueda del subagente, pero sí que el retorno no constituye aceptación automática del resultado final.
Un encargo como “revisar este contrato y señalar incompatibilidades” tiene una frontera diferente de “modificar todos los consumidores”. El agente delegado necesita saber cuál le corresponde. La capacidad técnica de editar no amplía el trabajo solicitado, y la especialización de su nombre no determina qué recursos puede utilizar.
La autonomía puede ser útil dentro de límites claros. El subagente puede elegir lecturas o experimentos pertinentes sin pedir aprobación para cada decisión rutinaria ya cubierta. Si descubre una ambigüedad que cambia requisitos o efectos, debe devolverla o escalarla por el mecanismo apropiado. Delegar una pregunta no autoriza inventar su respuesta de negocio.
Subagent y Agent Profile
Agent Profiles describe configuración reutilizable de un rol o especialidad. Un subagent es una ejecución efectiva. Un perfil puede configurar un subagente, un agente principal o distintas sesiones, según el sistema. Conservar una definición de reviewer no significa que haya un reviewer ejecutándose.
La diferencia importa al interpretar resultados. Un perfil puede declarar acceso a ciertas herramientas y la sesión concreta no tenerlas disponibles o autorizadas. Puede conservar instrucciones que todavía necesitan cargarse. La configuración expresa capacidades o intención reutilizable; el trabajo real depende de qué contexto, herramientas y condiciones recibió la ejecución.
Tampoco una ejecución delegada necesita un perfil persistente. El runtime puede crearla con un encargo acotado y configuración suficiente para esa tarea. Exigir un archivo o un rol permanente para cada delegación añade mantenimiento sin estar implícito en el patrón.
Subagent y herramienta
Una herramienta expone una capacidad o acción mediante una interfaz. Un subagente realiza trabajo agentic delegado, pudiendo seleccionar varios pasos a partir de observaciones. Una herramienta puede envolver esa ejecución y devolver su resultado, pero la interfaz de invocación y la relación de delegación describen responsabilidades distintas.
Tool Calling puede solicitar la capacidad que crea o consulta un subagente. La estructura de la llamada no demuestra cuánto control se delegó ni qué límites tendrá la ejecución. Un comando que corre una comprobación predefinida no se convierte en subagente solo porque se invoca desde un modelo.
Del mismo modo, varias herramientas ejecutadas concurrentemente no implican varias ejecuciones agentes. Para reconocer la delegación interesa quién recibió un objetivo y qué selección de próximos pasos puede realizar, no contar procesos o nombres de funciones.
Límites de contexto y estado
Un runtime puede proporcionar contexto separado o una selección del contexto del llamador. También puede permitir compartir ciertas fuentes o estado. Esas condiciones necesitan conocerse, no deducirse de la palabra subagent. Una ejecución nueva puede carecer de una decisión crucial que el llamador daba por implícita.
El encargo debería transferir información suficiente para trabajar sin copiar todo el historial por defecto. Importan revisión de partida, restricciones y evidencia relevante. Context Engineering for Software Development conserva la selección y transferencia de información en desarrollo; la separación de contextos no garantiza que ambos participantes comprendan la tarea de la misma manera.
El estado de una delegación puede incluir trabajo pendiente, resultado parcial o motivo de detención. Un subagente que alcanzó un límite no necesariamente cumplió su objetivo. El llamador necesita interpretar ese estado y decidir si obtiene más evidencia, cambia el encargo o continúa con una parte independiente.
Autoridad y aislamiento
Agent Permissions and Approval Boundaries sigue delimitando acciones. El llamador no debería usar delegación para eludir una restricción propia ni asumir que el subagente heredó autoridad ilimitada. La configuración del runtime y los sistemas externos determinan qué acceso existe realmente.
Un contexto separado tampoco es un sandbox. Las ejecuciones pueden compartir filesystem, credenciales o servicios externos. Agent Sandboxing restringe recursos y efectos; Workspace Isolation for Coding Agents separa copias de trabajo. Ambos pueden apoyar ciertas delegaciones sin estar garantizados por crear un subagente.
Si el resultado contiene instrucciones para ampliar el alcance, el llamador debe contrastarlas con el encargo y la autoridad vigente. Una recomendación del subagente es información para decidir, no una autorización nueva. Esa frontera permite utilizar especialización sin delegar inadvertidamente el control de las políticas.
Delegación adicional
Una ejecución delegada puede recibir capacidad para delegar otra parte del trabajo, si el runtime y el encargo lo permiten. Eso no implica delegación recursiva ilimitada. Cada frontera necesita conservar alcance, autoridad y resultado esperado; de otro modo, una tarea acotada puede transformarse en una cadena difícil de integrar y supervisar. La responsabilidad del llamador no desaparece porque el resultado provenga indirectamente de otra ejecución.
También interesa distinguir restricciones de ejecución de instrucciones informativas. Un límite comunicado en texto puede orientar al subagente, pero el sistema debe conocer qué controles efectivos impiden ampliar recursos o duración cuando esa propiedad sea importante. Agregar más niveles para compensar un encargo ambiguo puede amplificar pérdida de contexto y costo. Una alternativa más simple es corregir la frontera de trabajo o resolver una decisión antes de distribuirla. No se impone aquí una profundidad máxima universal ni se exige que todos los runtimes permitan crear ejecuciones adicionales.
Specialist Routing
Specialist routing selecciona una ejecución o configuración apropiada para una clase de trabajo. Puede orientar una revisión hacia conocimiento de interfaces, tests o rendimiento. Los roles son ejemplos de especialización, no conceptos canónicos distintos ni un inventario obligatorio de agentes para todo proyecto.
La selección puede realizarse con reglas, clasificación o decisiones del agente. Agentic Workflow Patterns mantiene Routing como patrón general: elegir una ruta no exige que el router sea agente ni que el destino sea un subagente. Una herramienta o workflow convencional puede ser suficiente para una pregunta bien delimitada.
La especialidad tampoco garantiza corrección. Un reviewer configurado para seguridad puede carecer de un contrato relevante o interpretar mal una evidencia. Conviene definir qué contribución se espera y cómo se contrastará, en vez de atribuir confianza automática al nombre del rol.
Result Aggregation
Los resultados delegados pueden requerir validación, comparación, integración o síntesis. El llamador necesita conservar procedencia y límites: qué se inspeccionó, qué revisión se utilizó y qué no pudo comprobarse. Un resumen breve puede ser útil sin borrar las condiciones que determinan si la contribución es aplicable.
Las discrepancias no se resuelven necesariamente por mayoría. Dos subagentes pueden compartir la misma premisa equivocada, mientras otro detecta una restricción real. Interesa contrastar evidencia y autoridad de las afirmaciones. Tampoco una respuesta más extensa merece más peso por volumen de texto.
Agregar resultados no establece su corrección ni la del producto combinado. Generated Code Verification conserva el juicio sobre un cambio concreto. Si varias tareas producen modificaciones, hay que considerar sus interacciones y el estado integrado, no solo que cada participante reportó éxito por separado.
Delegation y handoff
Agent Handoffs transfiere responsabilidad o control a otra ejecución. En la delegación acotada, el llamador conserva una responsabilidad más amplia y espera integrar el resultado. Un sistema puede combinar ambas relaciones; no se impone un lifecycle universal donde todo hijo deba retornar o toda transferencia cree un subordinado.
Enviar contexto tampoco determina cuál de las dos relaciones ocurrió. Puede ser una contribución informativa, un pedido de trabajo o parte de una transferencia de control. Interesa hacer explícito quién debe actuar después y quién decide si el resultado global está listo.
Esta distinción evita abandonar trabajo entre participantes. Si ambos creen que el otro conserva el siguiente paso, la tarea puede quedar sin dueño. Si ambos continúan modificando el mismo recurso, pueden duplicar efectos o producir cambios incompatibles.
Relación con coordinación y protocolos
Multi-Agent Coordination aborda dependencias, propiedad y conflictos entre varias ejecuciones. La delegación describe una relación concreta que puede formar parte de esa coordinación. No todos los sistemas multiagente son jerárquicos ni todo trabajo delegado necesita una arquitectura extensa de coordinación.
MCP, ACP o A2A pueden participar en integraciones según el sistema. A2A es interoperabilidad entre agentes, no la definición de subagente. Un runtime puede delegar localmente sin ese protocolo y puede comunicarse con otro sistema sin establecer una relación subordinada.
Parallel Agent Execution agrega concurrencia cuando las tareas lo permiten. El subagente puede ejecutarse secuencialmente y seguir siendo trabajo delegado. La separación de roles no demuestra independencia de datos, artefactos o recursos externos.
Ejemplo: revisar sin modificar
Un agente prepara un cambio y delega revisar compatibilidad de una interfaz. El encargo entrega revisión, contrato y límites: identificar consumidores afectados, sin editar archivos ni publicar. El subagente puede explorar rutas pertinentes y devolver hallazgos con su evidencia. No necesita conocer toda la conversación para esa contribución.
El llamador encuentra una observación que depende de un consumidor fuera del repositorio. Debe mantenerla como incertidumbre o buscar evidencia adicional, no convertirla en defecto confirmado por el solo hecho de provenir del especialista. Si después autoriza una modificación, ese nuevo trabajo necesita delimitarse y relacionarse con el objetivo original.
El ejemplo también muestra que una revisión delegada no garantiza verificación independiente. Puede compartir la especificación incorrecta del autor o utilizar el mismo resumen sin comprobarlo. La independencia relevante depende de las fuentes y supuestos contrastados, no de que haya otra ejecución.
Costo y uso proporcional
La delegación puede duplicar exploración, transferir contexto y agregar espera o revisión. Un resultado comprimido puede ahorrar lectura y omitir una excepción decisiva. Una tarea pequeña puede resolverse con menos coordinación mediante un único agente. La elección debe considerar el trabajo real, no una preferencia general por multiplicar participantes.
El caso de investigación multiagente de Anthropic, publicado en junio de 2025, describe un líder y subagentes con contextos propios para explorar aspectos de una consulta. Es un ejemplo de una carga de investigación; sus decisiones no convierten ese diseño en la arquitectura indicada para toda tarea de coding.
Una buena frontera de delegación produce una contribución que puede integrarse y evaluarse. Si el llamador necesita reconstruir todo el trabajo para entender el resultado, quizá el encargo era ambiguo o la división no aportaba valor. Mejorar la frontera puede ser más útil que agregar más especialistas.
Evidencia y terminación
Agent Tracing puede relacionar asignación, ejecución, resultado y agregación. Los Development Context and Execution Records pueden conservar lo pertinente para revisión y continuidad. Ninguno exige registrar razonamiento privado ni considera una respuesta final como prueba de que cada acción anunciada ocurrió.
El cierre debería permitir saber qué aportó el subagente y qué responsabilidad permanece en el llamador o se transfirió. Una ejecución puede terminar con hallazgos parciales o una limitación legítima. Comunicarlo con precisión permite continuar sin fingir una completitud que la evidencia no sostiene.
Subagents and Delegation ofrece una forma de distribuir trabajo acotado. No reemplaza claridad del encargo, autoridad, verificación ni coordinación de recursos compartidos, y no convierte al sistema multiagente en una etapa superior de madurez.
Fuentes
- Anthropic: How we built our multi-agent research system, 2025-06-13: caso de investigación citado. Las fronteras conceptuales del Atlas no generalizan su implementación a todos los agentes.