Herramienta frente a habilidad frente a subagente: el espectro de delegación y su gobernanza

De todas las líneas que traza el glosario de agentes, la que separa herramientas, habilidades y subagentes es la más difusa; el propio glosario admite que el límite cambia según el framework. Sin embargo, el espectro subyacente es estable y vale la pena diseñar en torno a él: una herramienta es una acción, una habilidad es un procedimiento empaquetado y un subagente es un delegado que razona. Son tres tipos distintos de delegación y —la parte que la mayoría de las arquitecturas pasa por alto— tres problemas de gobernanza diferentes. Autorizar una herramienta, versionar una habilidad, dar una identidad a un subagente: si te equivocas de peldaño, gobernarás a un delegado con capacidad de razonamiento como si fuera una llamada a una función, que es exactamente como se producen las sorpresas en el radio de impacto.

Ingrid, una staff engineer, estaba revisando un agente antes de pasarlo a producción cuando se topó con una línea en su lista de herramientas que la hizo detenerse: una "herramienta" no era una herramienta. Nueve entradas eran llamadas a funciones honestas: consultar la base de datos de pedidos, publicar un mensaje en Slack. La décima, "resolve-customer-issue", era todo un segundo agente con la etiqueta de nombre de una herramienta: tenía su propio prompt, su propio presupuesto de llamadas al modelo, su propio acceso a herramientas y razonaba durante hasta quince pasos antes de devolver una cadena de texto. Había heredado los permisos del agente padre al por mayor —el modo de fallo que una configuración gobernada evita al delimitar explícitamente el alcance del delegado en lugar de permitirle heredar las concesiones del padre—, aparecía en las trazas como una única llamada opaca y había sido revisada por seguridad como "una herramienta", lo que equivale a decir que no se había revisado en absoluto. No había nada malicioso en ella. Todo en ella estaba mal clasificado.

La mala clasificación es el modo de fallo que este vocabulario existe para prevenir. El glosario de agentes de Hugging Face —cuyos términos sigue esta serie, vinculados a la infraestructura en nuestra publicación principal— separa los tres con claridad, al tiempo que admite que los frameworks difuminan sus fronteras. Esta publicación aborda el espectro peldaño a peldaño: qué es cada uno, cuándo recurrir a él y la superficie de gobernanza que exige cada uno. Porque la décima entrada de Ingrid no era un problema de nombres. Era un problema de delegación clasificado bajo el régimen de gobernanza equivocado.

1. El espectro, definido

Una herramienta es una acción. El modelo emite una solicitud estructurada —llama a esta función con estos argumentos— y el harness la ejecuta: una llamada a una API, una consulta a una base de datos, un comando de shell, una búsqueda web. El resultado regresa al contexto y el bucle continúa. La herramienta no razona; se ejecuta. Todo lo que el modelo sabe sobre ella es su descripción, y la llamada en sí es un evento discreto e inspeccionable con argumentos de entrada y un resultado de salida.

Una habilidad es conocimiento empaquetado. Mientras que una herramienta es "ejecuta este comando", una habilidad agrupa lo necesario para lograr un objetivo —investigar este tipo de error, generar este tipo de informe—, normalmente como instrucciones y procedimientos estructurados (el patrón SKILL.md) que se cargan en el contexto del agente bajo demanda. Una habilidad no ejecuta nada por sí misma; da forma a cómo el agente utiliza las herramientas de las que dispone. Es scaffold, hecho portable y reutilizable entre agentes.

Un subagente es un delegado. El agente emisor delega una subtarea en otro agente —uno con su propio modelo, su propio scaffold, su propia ventana de contexto y, posiblemente, sus propias herramientas— que razona a lo largo del trabajo de forma independiente y devuelve un resultado. El agente padre recibe el resultado en lugar de gestionar cada paso intermedio, de la misma manera que un manager no escribe en el teclado por un colaborador directo. Esa opacidad es el propósito y, al mismo tiempo, el problema de gobernanza. La distinción respecto a una herramienta es exactamente con la que tropezó Ingrid: una herramienta ejecuta; un subagente decide, puede utilizar herramientas a su vez y puede equivocarse de formas abiertas que una función no permite.

2. Elegir un peldaño: el más bajo que cumpla la función

El espectro intercambia control por capacidad a medida que se asciende. Una herramienta es máximamente legible —su comportamiento es su implementación, su invocación es un único evento auditable— y mínimamente capaz: gestiona exactamente aquello para lo que fue codificada. Un subagente es máximamente capaz —puede absorber ambigüedad, adaptarse a mitad de la subtarea y recuperarse de sorpresas— y mínimamente legible: su comportamiento surge de un modelo que razona en un contexto que no ves desde el padre. Una habilidad se sitúa en un punto intermedio: aumenta la competencia del agente en un tipo de tarea sin añadir un nuevo principal delegado.

Esto ofrece una heurística de selección clara: elige el peldaño más bajo que cumpla la función. Si la subtarea es determinista y está bien especificada —obtener este registro, ejecutar estas pruebas—, es una herramienta; envolverla en un subagente añade coste, latencia y un modo de fallo de final abierto a cambio de nada. Si la subtarea es un procedimiento que un experto del dominio podría redactar —clasificar un error de esta manera, estructurar el informe así—, es una habilidad: el propio razonamiento del agente padre, mejorado con conocimientos empaquetados, sin necesidad de delegación. Reserva el subagente para subtareas que requieran un juicio genuino con su propio estado de trabajo —analizar a fondo este corpus de registros, investigar esta cuestión— donde el trabajo abrumaría el contexto del padre o requeriría un razonamiento que el padre no debería entrelazar con su hilo principal. El delegado mal clasificado de Ingrid, juzgado por esta heurística, era legítimamente un subagente; el error nunca fue el peldaño, fue la clasificación.

3. Herramientas: gobernar la llamada

Dado que una herramienta es una acción ejecutada discreta, su unidad de gobernanza es la llamada. Hay tres preguntas asociadas a cada invocación: ¿está autenticado este emisor?, ¿está autorizado este emisor para esta herramienta?, y ¿es aceptable esta llamada en particular? —esta última cubre tanto los argumentos de entrada (una instrucción inyectada camuflada en un parámetro) como el resultado de salida (un secreto o datos de carácter personal en la respuesta). Esa es la superficie por llamada, y es exactamente lo que un MCP gateway existe para proporcionar: un registro para que los agentes accedan solo a herramientas autorizadas, autenticación centralizada para que los agentes no lleven credenciales por herramienta, RBAC por herramienta y guardrails antes/después de la llamada con una traza de auditoría por llamada. El MCP Gateway de TrueFoundry implementa este peldaño de extremo a extremo, incluyendo superficies de herramientas seleccionadas con privilegio mínimo por rol mediante servidores MCP virtuales.

Cabe incluir aquí una nota sobre la capa de scaffold por ser uno de los fallos de herramientas más frecuentes en la práctica: el modelo selecciona las herramientas basándose puramente en sus descripciones, por lo que una descripción vaga o solapada produce un uso indebido que ninguna comprobación por llamada detectará; la llamada está autorizada, bien formada y es incorrecta. Trata las descripciones de las herramientas como scaffold revisado y versionado, y trata una herramienta que se siga usando mal como si tuviera un error de documentación antes de asumir que el modelo tiene un error de razonamiento.

4. Habilidades: gobernar el artefacto

Una habilidad no ejecuta nada, por lo que la gobernanza por llamada no tiene de dónde agarrarse; su unidad de gobernanza es el artefacto. Las preguntas que importan son la procedencia y el versionado: quién escribió este procedimiento, quién lo revisó, qué versión ejecuta cada agente y qué cambió entre versiones —porque una habilidad es comportamiento, y una edición no revisada en una habilidad ampliamente utilizada es un cambio de comportamiento silencioso en todos los agentes que la montan. El modo de fallo de las habilidades no gobernadas es el modo de fallo del copiar y pegar no gobernado: procedimientos bifurcados en variantes privadas, versiones desfasadas ejecutándose indefinidamente y ninguna forma de responder a "¿qué agentes están afectados?" cuando un procedimiento resulta ser erróneo.

La solución es la misma que recibió el código: un registro. El Skills Registry de TrueFoundry trata las habilidades como artefactos SKILL.md versionados con RBAC: publicados, revisados, fijados por versión por los agentes y montados en el contexto bajo demanda en lugar de pegarse en cada definición. El montaje bajo demanda importa por partida doble: es una ventaja de ingeniería de contexto (el procedimiento solo ocupa espacio en la ventana cuando es relevante) y una ventaja de gobernanza (el registro sabe exactamente qué agentes usan qué habilidad y en qué versión, por lo que la pregunta de "¿qué agentes están afectados?" tiene respuesta). Una habilidad en un registro es conocimiento institucional; una habilidad en el portapapeles es un rumor.

5. Subagentes: gobernar el principal

Un subagente razona, por lo que ni la llamada ni el artefacto son la unidad de gobernanza adecuada; lo es el principal. Cuatro propiedades hacen que un subagente sea gobernable, y las cuatro faltaban en la décima entrada de Ingrid. Identidad: el subagente actúa como sí mismo, no de forma anónima dentro de su padre, por lo que sus acciones son atribuibles. Permisos delimitados: recibe las herramientas que su subtarea necesita, no las concesiones del padre por herencia; un delegado de análisis de registros no tiene por qué tener acceso de escritura del padre al sistema de pedidos. Recursos acotados: sus propios presupuestos de pasos y tokens, de modo que un delegado que se desvíe no pueda consumir silenciosamente la ejecución del padre (la preocupación de prevención de bucles de nuestro post sobre multiagentes, un nivel más abajo). Su propia traza: el registro del padre muestra la delegación y el resultado; el registro del subagente muestra los quince pasos intermedios —una línea única u opaca en una traza es exactamente como se esconde un delegado mal clasificado.

Este es el peldaño donde el harness demuestra su valor, porque estas propiedades son propiedades en tiempo de ejecución. El Agent Harness de TrueFoundry ejecuta subagentes como componentes de primer nivel de su mecanismo de ingeniería de contexto: cada delegado trabaja en una ventana de contexto aislada y devuelve conclusiones, no transcripciones, al padre; y cada uno aparece en la traza paso a paso con sus propias llamadas a modelos, llamadas a herramientas y costes. La delegación sin gobernanza por principal es la forma en que los permisos de un agente se convierten silenciosamente en un organigrama de copias no auditadas; la delegación con ella es simplemente una buena descomposición.

6. El eje del contexto: el espectro como instrumento de gestión de ventanas

Hay un segundo eje que recorre el espectro, el cual no tiene nada que ver con la seguridad y todo que ver con la calidad: lo que cada peldaño le cuesta a la ventana de contexto del padre. Una herramienta precargada cuesta su descripción en cada paso en el que está expuesta (cada descripción de herramienta precargada puede viajar dentro del contexto) más sus resultados a medida que llegan —razón por la cual el manejo de resultados (truncado, descarga) es trabajo del harness, y por la cual un agente con ochenta herramientas precargadas a nivel general puede pagar un coste de contexto permanente por todas ellas, las use o no, que es exactamente por lo que existe la carga diferida de herramientas bajo demanda. Una habilidad, montada bajo demanda, no cuesta nada hasta que es relevante y su procedimiento completo solo cuesta mientras lo sea. Un subagente es el instrumento de contexto más potente de todos: saca la subtarea completa fuera de la ventana del padre; el delegado consume su propio contexto limpio en la investigación de quince pasos y devuelve tres frases.

Leído de esta manera, el espectro funciona también como un kit de herramientas de ingeniería de contexto, que es exactamente como lo trata la suite de ingeniería de contexto del harness: las superficies de herramientas seleccionadas mantienen bajo el coste de descripción permanente, las habilidades cargan procedimientos justo a tiempo y los subagentes aislan las subtareas con gran carga de contexto para que la ventana del padre se mantenga reducida a lo largo de una ejecución extensa. La misma decisión de descomposición —qué peldaño gestiona este trabajo— es simultáneamente una decisión de gobernanza y una decisión de presupuesto de ventana, y las arquitecturas que se perciben fluidas son aquellas en las que ambas se tomaron deliberadamente.

7. Composición de los peldaños: un ejemplo práctico

Los peldaños se componen, y un agente realista utiliza los tres. Tomemos el agente de operaciones de clientes de Ingrid, reclasificado correctamente:

Un agente, tres peldaños —cada uno gobernado en su propia superficie (ilustrativo)

La composición se interpreta de forma natural: las herramientas son lo que puede hacer, las habilidades son lo que sabe hacer y el subagente es lo que delega. Y cada línea aterriza en un sistema de gobernanza diferente que ya sabe qué hacer con ella: el MCP Gateway autoriza y audita las llamadas, el Skills Registry rastrea las versiones y el harness ejecuta al delegado con su propia identidad, presupuesto y traza. La arquitectura no consta de tres casos especiales; es un único espectro con la gobernanza vinculada previamente a cada peldaño. Eso es lo que significa en la práctica "codificar el espectro, no las etiquetas": independientemente de cómo llame un framework a estas entidades, clasifica cada una por lo que es —acción, procedimiento o principal— y los controles adecuados se aplicarán a continuación.

8. Refactorización a lo largo del espectro

El peldaño adecuado hoy puede variar con el tiempo. Una herramienta a la que se le añaden opciones y comportamientos condicionales está evolucionando hacia un procedimiento —considera si esa lógica pertenece a una habilidad que orqueste herramientas más simples. Una habilidad que no deja de decir "juzga si..." está evolucionando hacia un delegado —los procedimientos no deberían requerir juicio; esa es la señal para promover ese juicio a un subagente con su propio alcance. Y un subagente cuyas ejecuciones resultan ser casi idénticas cada vez está evolucionando hacia abajo —si el delegado nunca llega a ejercer juicio, degrada el trabajo a una habilidad más herramientas y recupera legibilidad y coste.

Dos prácticas hacen que esta refactorización sea segura. En primer lugar, la traza te indica cuándo hacerla: los registros paso a paso muestran la herramienta siendo invocada con argumentos cada vez más extraños, la habilidad siendo anulada por razonamientos ad hoc, o el subagente generando los mismos cinco pasos en cada ejecución. En segundo lugar, la evaluación te dice si funcionó: un cambio de peldaño es un cambio de comportamiento —un cambio de política, en el vocabulario del glosario—, el cual el bucle de evaluación debe validar como cualquier otro. La descomposición no es una decisión de diseño puntual; es una propiedad que se mantiene, y el espectro le da a ese mantenimiento una dirección.

9. Preguntas frecuentes

Los frameworks realmente no se ponen de acuerdo en estos términos — ¿sigue importando la distinción? Las etiquetas varían; el espectro no, y el glosario es totalmente transparente sobre esto. Lo que importa operativamente es clasificar cada capacidad por lo que es —una acción ejecutada, un procedimiento cargado, un principal razonador— porque la clasificación determina la gobernanza. El incidente de Ingrid no fue causado por el nombre dado por un framework; fue causado por una gobernanza que siguió al nombre en lugar de a la naturaleza de la entidad.

¿Es un subagente simplemente una herramienta desde el punto de vista del emisor? Mecánicamente a menudo se invoca a través de la misma interfaz, por lo que la mala clasificación resulta tan fácil. La diferencia está al otro lado de la llamada: el comportamiento de una herramienta es su implementación; el comportamiento de un subagente es un modelo razonando en su propio contexto, con sus propias herramientas, capaz de equivocarse de formas abiertas. Misma convención de llamada, especie diferente —y la gobernanza debe adaptarse a la especie.

¿Cuándo es mejor una habilidad que simplemente escribir instrucciones más largas? Cuando el procedimiento es reutilizable, compartido o merece ser gobernado. Las instrucciones integradas en el prompt son adecuadas para el comportamiento puntual de un solo agente. En el momento en que un procedimiento es utilizado por varios agentes, mantenido por alguien distinto al autor del agente, o lo suficientemente importante como para querer saber qué versión se ejecuta en cada lugar, se trata de una habilidad y pertenece a un registro con versiones y RBAC, no al portapapeles.

¿Debería un subagente heredar alguna vez los permisos de su padre? Por defecto, no. La herencia es conveniente y silenciosamente maximalista: el delegado obtiene todo lo que tiene el padre, lo necesite o no, lo cual invierte el principio de mínimo privilegio precisamente donde la autonomía de razonamiento hace que más importe. Delimita el alcance del subagente a las herramientas de su subtarea. Si eso resulta laborioso, es la arquitectura indicándote que el límite de delegación merece el mismo cuidado que cualquier otro límite de confianza, porque lo es.

¿Subir por el espectro no implica simplemente más coste y latencia? Por lo general, sí —un subagente realiza llamadas a modelos que una herramienta no haría— y eso forma parte de la heurística del peldaño más bajo. Pero la comparación no es peldaño contra peldaño en el vacío; es frente a la alternativa de que el padre realice el trabajo dentro de su ventana. Una subtarea con gran carga de contexto realizada por el padre puede degradar toda la ejecución (y su coste se arrastra en la creciente ventana del padre); la misma subtarea delegada se ejecuta en un contexto limpio y económico. Mide por tarea completada, no por llamada.

La décima entrada de Ingrid nunca necesitó ser prohibida; necesitaba ser clasificada. Reclasificada como lo que era, obtuvo una identidad, un alcance, un presupuesto y una traza, y pasó a producción una semana después como el componente más revisado del agente en lugar del menos. Esa es toda la promesa del espectro: las capacidades de un agente no son una lista plana de "herramientas", sino tres tipos de delegación, cada uno con una gobernanza que ya reconoce su naturaleza. Acción, procedimiento, principal. Clasifica en consecuencia.

Referencias

• Hugging Face — agent glossary (Mayo de 2026) — las definiciones de herramienta/habilidad/subagente sobre las que se construye esta publicación, parafraseadas con el debido crédito.
• TrueFoundry MCP Gateway — gobernanza por llamada para el peldaño de herramientas: registro, autenticación, RBAC, guardrails, auditoría.
• TrueFoundry Skills Registry — gobernanza por artefacto para el peldaño de habilidades: versiones, procedencia, RBAC, montaje bajo demanda.
• TrueFoundry Agent Harness — gobernanza por principal para el peldaño de subagentes: aislamiento, presupuestos, trazas.
• The agent glossary, mapped to production — la publicación principal de esta serie.

Ingrid es un perfil compendio ilustrativo, no una persona, organización o incidente específico. El vocabulario sigue el glosario de agentes de Hugging Face (Mayo de 2026), el cual señala que los límites entre herramienta/habilidad/subagente cambian según el framework. Los fragmentos de configuración se han simplificado para facilitar la lectura y no constituyen esquemas literales de producto. Las capacidades de TrueFoundry reflejan la documentación pública en el momento de la redacción; verifique la documentación actual.

‍