Skills como puertas de herramientas: escalar el contexto

Un estudio de caso técnico de NanthAI:Edge.

La mayoría de los agentes de IA amplían sus capacidades de la forma equivocada: cada capacidad nueva añade más texto al prompt, más esquemas de herramientas y más posibilidades de que el modelo elija mal. En NanthAI:Edge, esto no es solo una teoría. El catálogo visible actual de skills ocupa unos 5,1 mil tokens como metadatos, frente a unos 67 mil tokens de los cuerpos completos de las skills visibles. El registro base expone 4 herramientas, frente a las 115 del registro totalmente ampliado. Eso no demuestra un mayor éxito en las tareas, pero sí demuestra que la superficie de contexto es radicalmente menor.

Resumen

Los agentes basados en grandes modelos de lenguaje (LLM) que usan herramientas afrontan una tensión estructural entre la amplitud de capacidades y la economía del contexto. Cada instrucción de trabajo adicional y cada esquema de herramienta adicional que se introduce en el contexto del modelo consume tokens, aumenta la latencia y el coste, y puede hacer menos fiable la selección de herramientas. Este artículo desarrolla el patrón de diseño de acceso progresivo a herramientas controlado por skills, en el que un catálogo compacto de skills, estable para la caché, media tanto la carga de instrucciones bajo demanda como la ampliación gradual del registro de herramientas ejecutables.

Una skill se trata como un paquete de instrucciones modular y descubrible, con metadatos, una guía completa de comportamiento y requisitos declarados de perfiles de herramientas. En lugar de introducir todas las skills y herramientas en cada solicitud, el sistema expone primero metadatos ligeros de las skills; el modelo invoca load_skill cuando una tarea encaja con una skill; las skills cargadas introducen entonces instrucciones detalladas y activan los perfiles de herramientas pertinentes.

El artículo sitúa este patrón frente a la literatura sobre la sobrecarga de prompts, la escalabilidad de las llamadas a funciones, la selección de herramientas basada en recuperación, el almacenamiento de prompts en caché, la divulgación progresiva y la arquitectura modular de agentes. Después analiza NanthAI:Edge como estudio de caso concreto, usando detalles de implementación aportados por el autor del sistema. NanthAI:Edge organiza las capacidades en tres capas: nivel de cuenta, skills y herramientas ejecutables. El artículo explica los beneficios esperados, los riesgos centrales y las contrapartidas de implementación de esta arquitectura.

Resumen del flujo del registro de herramientas, con acceso controlado por skills

1. Introducción

Los sistemas modernos de LLM con agentes suelen construirse combinando tres tipos de contexto en cada solicitud: instrucciones del sistema, esquemas de herramientas y estado de la conversación. A medida que los agentes acumulan capacidades, cada capa tiende a crecer. Los nuevos flujos de trabajo añaden instrucciones al prompt. Las nuevas integraciones añaden esquemas de herramientas. Las nuevas preferencias y memorias del usuario añaden más contexto. El sistema resultante tiene capacidad, pero es cada vez más pesado.

Esto crea dos problemas relacionados:

1. La sobrecarga del prompt ocurre cuando el prompt del sistema acumula numerosas instrucciones de comportamiento, políticas, guías de trabajo, ejemplos, memorias y reglas contextuales.
2. La sobrecarga del registro de herramientas ocurre cuando se exponen al modelo muchas herramientas ejecutables independientemente de su relevancia para la tarea actual.

Ambas son costosas. Consumen tokens de entrada, elevan la latencia, aumentan el coste del proveedor y complican el almacenamiento de prompts en caché. Más importante aún, pueden degradar la calidad de las decisiones. Un modelo al que se pide elegir entre decenas o cientos de herramientas debe comparar más candidatas, prestar atención a más descripciones y resolver más solapamientos semánticos.

Los trabajos recientes sobre selección de herramientas aumentada con recuperación respaldan esta preocupación. El estudio RAG-MCP de Gan y Sun indica que recuperar los esquemas de herramientas pertinentes, en lugar de pasar todos los esquemas, mejoró la exactitud de selección del 13,62 % al 43,13 % en una configuración de MCPBench WebSearch y redujo los tokens del prompt aproximadamente a la mitad. Esas cifras son específicas de esa evaluación y no deben generalizarse a ciegas, pero ilustran el problema central: exponer todas las herramientas en un plano único suele ser una mala arquitectura de la información.

Este artículo examina una alternativa estructurada: el acceso progresivo a herramientas controlado por skills.

El patrón es sencillo:

1. Exponer un catálogo compacto de skills disponibles.
2. Dejar que el modelo cargue una skill pertinente mediante load_skill.
3. Introducir las instrucciones completas de la skill solo después de activarla.
4. Ampliar el registro activo de herramientas únicamente mediante los perfiles que requieren las skills cargadas.

El diseño adapta la divulgación progresiva de la experiencia de usuario y la ocultación de información de la arquitectura de software a la economía de las ventanas de contexto de los LLM. El detalle oculto no se oculta a una persona; se oculta al modelo hasta que la tarea justifica exponerlo.

Analizamos este patrón a través de NanthAI:Edge, un entorno comercial de ejecución de agentes cuya arquitectura implementa capacidades de cuenta por capas, descubrimiento de skills, carga de skills y ampliación de herramientas controlada por perfiles. Los detalles específicos de NanthAI de este artículo son detalles de implementación del estudio de caso aportados por el autor del sistema.

El artículo aporta:

1. Un marco conceptual de las skills como puertas de acceso progresivas a instrucciones y herramientas.
2. Un análisis de caso de la arquitectura de tres capas de NanthAI:Edge.
3. Una discusión sobre estabilidad de caché, intención de enrutamiento y ampliación del registro basada en perfiles.
4. Un catálogo de riesgos centrado en la selección incorrecta de skills y la falta de carga de skills.

2. Antecedentes: sobrecarga del prompt, esquemas y uso de herramientas por agentes

2.1 Llamadas a funciones y exposición de herramientas

Las API de llamadas a funciones requieren que las herramientas se describan al modelo mediante nombres, descripciones en lenguaje natural y esquemas estructurados de parámetros. El modelo decide si llama a una herramienta, a cuál y con qué argumentos. Evaluaciones como Berkeley Function Calling Leaderboard miden esta capacidad en escenarios de un turno, de varios turnos, paralelos y sensibles a la relevancia.

El uso de herramientas no es una sola capacidad. Se descompone en varias:

• Selección de herramientas: elegir la función adecuada.
• Construcción de argumentos: producir parámetros válidos y semánticamente correctos.
• Secuenciación de llamadas: invocar herramientas en el orden adecuado.
• Interpretación de resultados: usar correctamente las salidas de las herramientas.
• Finalización de la tarea: satisfacer la intención real del usuario.

Un sistema puede seleccionar la herramienta adecuada y fallar en los argumentos. Puede llamar a una herramienta plausible y fallar en la tarea. Puede funcionar una vez y degradarse a lo largo de varios turnos. Por eso puntuar solo la respuesta final es insuficiente para evaluar sistemas de agentes.

2.2 Sobrecarga del prompt

La sobrecarga del prompt suele plantearse como una cuestión de costes, pero el problema de fondo es el foco. Los prompts largos pueden incluir información pertinente, información irrelevante, instrucciones desactualizadas, políticas duplicadas y muchas definiciones de herramientas. Las ventanas de contexto más grandes permiten que esa información quepa, pero que quepa no equivale a usarla de forma fiable.

La investigación sobre contextos largos, como «Lost in the Middle», muestra que los modelos pueden usar la información con menor fiabilidad según dónde aparezca en el contexto. Otros estudios de contextos largos y llamadas a herramientas sugieren que la longitud del contexto, el número de herramientas y la acumulación a lo largo de varios turnos pueden interactuar de forma frágil. Los umbrales exactos varían según el modelo y la tarea, así que este artículo evita afirmaciones como «los modelos fallan a partir de N herramientas». La afirmación defendible es más acotada: las instrucciones innecesarias y los esquemas irrelevantes aumentan la superficie de decisión que afronta el modelo y pueden empeorar las condiciones de enrutamiento.

2.3 Sobrecarga del registro de herramientas

La sobrecarga del registro de herramientas es la versión específica de herramientas de la sobrecarga del prompt. Un registro plano y grande obliga a cada herramienta disponible a competir por la atención en cada tarea. Esto es especialmente problemático cuando las herramientas se solapan semánticamente: varias herramientas de búsqueda, documentos, calendario, espacio de trabajo o variantes específicas de distintas integraciones.

Los trabajos de selección de herramientas basada en recuperación abordan directamente este problema. RAG-MCP recupera los esquemas pertinentes antes de enviar el prompt, en lugar de exponer todas las herramientas. Tool Attention y los enfoques de carga dinámica de esquemas también defienden reducir el conjunto activo de candidatas. Estos enfoques no demuestran que el control de acceso mediante skills funcione, pero respaldan la idea más amplia de que el modelo no debería ver siempre todas las capacidades ejecutables.

2.4 Calidad de las descripciones de herramientas

Reducir la exposición de herramientas no basta. Las herramientas y skills que sigan siendo visibles deben describirse con claridad. ToolACE presenta mejoras obtenidas con datos de llamadas a funciones verificados y de alta calidad, lo que muestra que la calidad de los esquemas y las descripciones influye en la exactitud del uso de herramientas. Los estudios sobre documentación de API también sugieren que una documentación de parámetros poco clara y unas interfaces complejas aumentan los errores.

Esto crea la tensión central del diseño:

• Las instrucciones y los esquemas detallados mejoran la ejecución.
• Exponer globalmente todas las instrucciones y esquemas detallados genera sobrecarga.

El control progresivo mediante skills aborda esa tensión separando los metadatos de descubrimiento de los detalles de ejecución.

2.5 Almacenamiento de prompts en caché

El almacenamiento de prompts en caché puede reducir la latencia y el coste al reutilizar prefijos estables. Pero la caché favorece una estructura estable del prompt. Si las listas de herramientas o las instrucciones del sistema se reescriben de forma impredecible, la reutilización de la caché puede empeorar.

Esto crea una segunda tensión de diseño:

• La carga dinámica reduce el contexto irrelevante.
• La inserción dinámica puede romper la estabilidad de la caché.

Por tanto, una arquitectura viable de control de acceso mediante skills debe gestionar dónde y cómo aparecen las instrucciones cargadas. El enfoque de NanthAI:Edge, descrito más adelante, consiste en mantener un prompt base y un catálogo estables y, después, añadir bloques normalizados de skills cargadas en posiciones predecibles.

3. Las skills como paquetes modulares de instrucciones

Una skill es un paquete de capacidades con nombre y que puede descubrirse. No es simplemente una herramienta ni un fragmento de prompt. Se sitúa entre la intención del usuario y las funciones ejecutables.

Una skill suele incluir:

• slug
• nombre
• resumen
• runtimeMode
• instrucciones completas del flujo de trabajo
• identificadores de herramientas requeridas
• perfiles de herramientas requeridos
• integraciones requeridas
• capacidades de cuenta requeridas
• restricciones de políticas
• metadatos de versiones

Una herramienta es una operación ejecutable. Una skill es una capacidad a nivel de flujo de trabajo que puede usar ninguna, una o muchas herramientas.

Por ejemplo, una herramienta de generación de documentos puede crear un archivo .docx. Una skill de «redacción de artículos de investigación» puede definir reglas sobre el manejo de fuentes, el rigor de las citas, la estructura, los requisitos de síntesis y las expectativas de generación del documento, y puede activar herramientas de documentos, búsqueda y análisis.

El control progresivo de acceso mediante skills opera en tres capas de divulgación:

Esta estructura convierte las skills en elementos básicos de la gestión del contexto. Son, al mismo tiempo:

• unidades de capacidad;
• unidades de alcance de instrucciones;
• unidades de ampliación del registro de herramientas;
• unidades de gobernanza y observabilidad.

4. Estudio de caso de NanthAI:Edge

Esta sección resume detalles de implementación del estudio de caso aportados por el autor del sistema. Debe leerse como documentación de arquitectura, no como evidencias auditadas de forma independiente.

4.1 Modelo de capacidades de tres capas

NanthAI:Edge organiza las capacidades en tres capas:

1. Capacidad y nivel de cuenta
2. Skills
3. Herramientas ejecutables

La capa de cuenta determina a qué puede acceder el usuario. Los usuarios del nivel gratuito reciben chat simple sin un registro de herramientas invocable por el modelo. Los usuarios Pro con modelos capaces de usar herramientas reciben un registro base pequeño.

La capa de skills contiene paquetes modulares de instrucciones con metadatos y reglas de activación.

La capa de herramientas ejecutables contiene los esquemas e implementaciones reales, pero las familias de herramientas pesadas no se exponen por defecto. Se habilitan mediante los perfiles declarados por las skills.

4.2 Registro base

El registro base contiene herramientas ligeras de propósito general como:

• load_skill
• list_skills
• search_chats
• fetch_image

La herramienta crucial es load_skill. Convierte el enrutamiento en una acción explícita del modelo. El modelo no necesita todas las instrucciones de antemano; necesita suficientes metadatos para decidir cuándo hacen falta instrucciones más detalladas.

4.3 Metadatos de las skills

Las skills de NanthAI incluyen metadatos estructurados:

• slug
• name
• summary
• runtimeMode
• requiredToolIds
• requiredToolProfiles
• requiredIntegrationIds
• requiredCapabilities

Estos metadatos permiten tanto el descubrimiento por parte del modelo como la aplicación de políticas en tiempo de ejecución. Una skill que requiera Slack, por ejemplo, puede ocultarse si el usuario no ha conectado Slack. Una skill que requiera una capacidad Pro puede omitirse para los usuarios del nivel gratuito.

4.4 Catálogo de skills disponibles

Las skills resueltas como disponibles se representan en un bloque XML <available_skills> del prompt del sistema. Este catálogo contiene metadatos compactos, no instrucciones completas.

Un ejemplo simplificado:

<available_skills>
<skill slug="analytics_report">
<name>Informe analítico</name>
<summary>Usar cuando el usuario necesite análisis de datos, gráficos o resultados analíticos estructurados.</summary>
</skill>
<skill slug="document_drafting">
<name>Redacción de documentos</name>
<summary>Usar cuando el usuario necesite un documento estructurado, una propuesta, un memorando o un archivo generado.</summary>
</skill>
</available_skills>

El catálogo es una superficie de enrutamiento. Indica al modelo qué capacidades existen sin obligarlo a procesar íntegramente cada flujo de trabajo.

4.5 Estados de las skills

NanthAI resuelve las skills en cuatro ámbitos:

• ajustes de cuenta;
• perfil Persona;
• chat;
• anulaciones a nivel de turno.

Cada skill puede tener uno de tres estados:

• always: instrucciones completas introducidas en cada turno;
• available: aparece en el catálogo y se puede cargar bajo demanda;
• never: se excluye por completo.

Esto permite políticas detalladas. Las reglas universales pueden estar siempre activas. Los flujos especializados pueden estar disponibles. Las capacidades no permitidas o irrelevantes pueden ocultarse.

4.6 load_skill

Cuando el modelo determina que una tarea encaja con una skill, llama a load_skill con el slug de la skill. El entorno de ejecución devuelve las instrucciones completas y los metadatos de enrutamiento.

En lugar de depender de los resultados de herramientas en bruto que quedan en el historial, NanthAI normaliza las instrucciones cargadas en un mensaje del sistema dedicado a las skills cargadas. Esto hace explícito el estado activo de las instrucciones y evita acumular un historial ruidoso de llamadas a herramientas.

4.7 Perfiles progresivos de herramientas

Las skills declaran requiredToolProfiles. Cargar una skill puede activar uno o más perfiles de herramientas. Los perfiles aportados por el autor incluyen:

• docs
• analytics
• workspace
• persistentRuntime
• subagents
• google
• microsoft
• notion
• appleCalendar
• cloze CRM
• slack
• scheduledJobs
• skillsManagement
• personas

Ejemplos:

• docs habilita herramientas de generación y edición de documentos y archivos.
• analytics habilita Python y herramientas de datos.
• workspace habilita herramientas de archivos y ejecución del espacio de trabajo.
• los perfiles de integración habilitan herramientas específicas de aplicaciones solo cuando están conectadas.
• subagents habilita la creación de subagentes solo cuando está permitida.

Por tanto, el registro se amplía según las skills activadas, no según la capacidad total de la plataforma.

4.8 Protección en tiempo de ejecución

NanthAI incluye una instrucción de protección en tiempo de ejecución que indica al modelo que no invente herramientas no disponibles: sin acceso al sistema de archivos local, shell, automatización del navegador, servidores MCP no configurados ni obtenciones de datos de red directas fuera de las herramientas explícitas de NanthAI.

Esta protección a nivel de prompt no es por sí sola una frontera de seguridad. La frontera real de seguridad debe imponerse mediante autorización en tiempo de ejecución y listas de herramientas permitidas. Pero la instrucción refuerza la comprensión que tiene el modelo de las capacidades activas.

5. Análisis de la arquitectura

5.1 Modelo de coste en tokens

Con un diseño monolítico, el coste del prompt por turno se aproxima a:

base_prompt + all_skill_instructions + all_tool_schemas + conversation_state

Con el control progresivo de acceso mediante skills, el coste se aproxima a:

base_prompt + skill_catalog_metadata + loaded_skill_instructions + active_profile_tool_schemas + conversation_state

La distinción crucial es qué crece con la capacidad total de la plataforma. En el diseño monolítico, los costes elevados de instrucciones y esquemas crecen con todas las capacidades disponibles. En el diseño progresivo, los costes elevados crecen con las capacidades activadas. El catálogo sigue creciendo, pero solo como metadatos compactos.

Ese es el núcleo económico de la arquitectura.

5.2 El catálogo como superficie de enrutamiento estable para la caché

El bloque available_skills está pensado para mantenerse estable entre turnos salvo que cambien las capacidades del usuario, el perfil Persona, los ajustes del chat o las anulaciones del turno. La estabilidad importa porque la caché de prompts depende de prefijos reutilizables. Un catálogo compacto y estable puede seguir favoreciendo la caché, mientras los cuerpos completos de las skills se mantienen diferidos.

5.3 Bloque de skills cargadas

Normalizar las instrucciones de las skills cargadas en un mensaje dedicado del sistema tiene dos beneficios:

1. Primero, mantiene limpio el estado de las instrucciones. El modelo ve la guía de las skills cargadas como contexto activo del sistema y no como un resultado histórico de una herramienta.
2. Segundo, ayuda a conservar la estructura de la caché de prompts. Si las skills cargadas se añaden después del prompt base y del catálogo estables, las nuevas activaciones amplían el contexto sin reescribir el prefijo estable.

Esta es una de las ideas arquitectónicas más importantes del diseño de NanthAI: la ampliación dinámica de capacidades y la caché de prompts no son compatibles por naturaleza, así que la estructura de mensajes debe conciliarlas explícitamente.

5.4 Ampliación del registro basada en perfiles

Los perfiles de herramientas crean una capa intermedia entre las skills y las herramientas. Esto es preferible a que cada skill sea responsable directa de una larga lista de esquemas individuales de herramientas.

Esa capa intermedia de perfiles tiene varias ventajas:

• varias skills pueden compartir un perfil;
• los perfiles se pueden probar como conjuntos de capacidades;
• la disponibilidad de una integración se puede comprobar una vez por perfil;
• las herramientas relacionadas se pueden exponer juntas;
• las políticas se pueden aplicar a nivel de perfil;
• el registro activo sigue siendo explicable.

Por ejemplo, muchas skills pueden necesitar generar documentos. En lugar de duplicar listas de herramientas de documentos entre skills, pueden activar el perfil docs.

5.5 Intención de enrutamiento

En un registro plano, la intención es implícita. Si el modelo llama a una herramienta, los ingenieros deben deducir por qué. En un sistema controlado por skills, la intención de enrutamiento se hace explícita:

tarea del usuario → skill cargada → perfil activado → herramienta seleccionada

Esto mejora la observabilidad. Los fallos se pueden descomponer por capas:

• ¿Era visible la skill correcta?
• ¿Se cargó?
• ¿Activó el perfil adecuado?
• ¿Se seleccionó la herramienta correcta?
• ¿Eran correctos los argumentos?
• ¿Satisfizo la respuesta final la tarea?

Esto supone una ventaja considerable para la evaluación frente a los prompts monolíticos.

6. Contraargumento central: el enrutamiento por metadatos puede fallar

La objeción más sólida al acceso progresivo controlado por skills es que ocultar las instrucciones completas puede perjudicar el enrutamiento.

Puede que un modelo no sea capaz de distinguir skills similares solo por sus metadatos. Si los resúmenes del catálogo son demasiado breves, vagos o se solapan, el modelo puede:

• cargar la skill equivocada;
• no cargar ninguna skill;
• cargar demasiadas skills;
• activar el perfil de herramientas equivocado;
• producir una respuesta plausible pero insuficientemente especificada.

No es un caso límite menor. Es la contrapartida central. El acceso progresivo intercambia un problema, la sobrecarga global, por otro: la cobertura y precisión del enrutamiento.

La arquitectura es más sólida cuando:

• el catálogo de skills tiene un tamaño moderado;
• los resúmenes distinguen bien las skills;
• las skills no se solapan en exceso;
• se permite pedir aclaraciones como alternativa;
• las decisiones de enrutamiento se registran y evalúan;
• la recuperación semántica puede ayudar a encontrar coincidencias en el catálogo.

Es más débil cuando:

• hay miles de skills similares;
• los resúmenes son genéricos;
• las tareas requieren distinciones sutiles;
• se desanima al modelo a hacer preguntas aclaratorias;
• omitir una skill produce silenciosamente un resultado deficiente pero plausible.

Por tanto, una implementación robusta debe combinar el juicio del modelo con comprobaciones deterministas, recuperación, control de versiones y evaluación.

7. Riesgos y modos de fallo

R1: Selección incorrecta de skills

El modelo carga una skill parecida, pero inadecuada. Esto puede introducir instrucciones erróneas y activar herramientas irrelevantes.

Mitigaciones: resúmenes que distingan las skills, ejemplos, notas sobre «cuándo no usarla», pruebas de enrutamiento sin conexión y umbrales de confianza.

R2: Falta de carga de skills

El modelo continúa sin cargar una skill. Es peligroso porque el resultado puede parecer aceptable mientras incumple los requisitos del flujo de trabajo.

Mitigaciones: instrucciones de carga más claras, detectores de skills omitidas, clasificadores posteriores y comportamiento de aclaración.

R3: Instrucciones desactualizadas

Las instrucciones cargadas pueden persistir después de actualizar una skill.

Mitigaciones: identificadores de versión de las skills, invalidación de caché, reglas de recarga y pruebas de compatibilidad.

R4: Acoplamiento oculto

Las skills y los perfiles pueden desajustarse. Una skill puede dar por disponibles herramientas que en realidad no están en su perfil.

Mitigaciones: requiredToolProfiles, requiredToolIds, pruebas de perfiles y análisis estático de dependencias.

R5: Latencia añadida

load_skill añade una ronda de llamadas a herramientas antes de empezar el trabajo.

Mitigaciones: mantener los flujos frecuentes como always, precarga especulativa o registro base híbrido.

R6: Invalidación de caché

El contenido dinámico insertado demasiado pronto puede impedir la reutilización de la caché.

Mitigaciones: disciplina de prefijos estables, bloque de skills cargadas al que solo se añade contenido y pruebas de caché.

R7: Inyección de prompts

Las skills escritas por usuarios pueden contener instrucciones inseguras.

Mitigaciones: revisión de skills, análisis estático de políticas, entornos aislados, ámbitos de permisos y aplicación de controles en tiempo de ejecución.

R8: Dependencia excesiva del juicio del modelo

El modelo puede enrutar mal ante la ambigüedad.

Mitigaciones: enrutamiento asistido por recuperación, controles deterministas de políticas, aclaraciones del usuario y telemetría.

8. Discusión

El control progresivo de acceso mediante skills replantea el registro de herramientas como una arquitectura de capacidades. En lugar de una lista plana de herramientas, el entorno de ejecución del agente se organiza por capas:

política de cuenta → catálogo de skills → carga de skills → activación de perfiles → ejecución de herramientas

Esto tiene varias implicaciones:

1. Las skills se convierten en la unidad principal de gobernanza. El acceso por nivel, el estado de las integraciones, los perfiles de herramientas y los modos de ejecución se pueden expresar mediante metadatos de las skills.
2. El enrutamiento se puede inspeccionar. Los eventos load_skill se pueden registrar, medir y evaluar.
3. Los mercados de skills se vuelven más manejables. Las skills escritas por usuarios pueden declarar sus requisitos y admitirse con un alcance de capacidades delimitado.
4. Probablemente los diseños híbridos sean los mejores. Las herramientas universales pequeñas deben permanecer en el registro base. Las herramientas especializadas, de alto riesgo, costosas o poco frecuentes deben quedar tras una puerta de acceso. Las skills always deben ser escasas. available debe ser el valor predeterminado para los flujos especializados. never debe suprimir las capacidades no permitidas.
5. La calidad del catálogo de skills se convierte en parte del producto. Los resúmenes del catálogo no son etiquetas internas; son interfaces de enrutamiento para el modelo. Requieren el mismo rigor que la documentación de API.

Esta es la dirección que estamos tomando en NanthAI:Edge: las capacidades deben poder descubrirse sin introducirse permanentemente en el contexto, y las herramientas potentes deben aparecer solo cuando el flujo activo las justifique.

9. Mediciones estáticas de la arquitectura

Aunque la validación completa del comportamiento requiere un conjunto de pruebas de referencia, algunas afirmaciones se pueden evaluar directamente a partir de la implementación actual de NanthAI:Edge. En concreto, el código permite medir la superficie de contexto expuesta por el catálogo de skills y el registro progresivo de herramientas.

Estas mediciones cuantifican la vertiente de economía del contexto del argumento: cuánto contenido de prompts y esquemas de herramientas se evita al exponer metadatos compactos de skills y un registro base pequeño, en lugar de introducir desde el principio el cuerpo de cada skill y todos los esquemas de herramientas.

9.1 Compresión del catálogo de skills

El catálogo actual del sistema NanthAI:Edge contiene 55 skills visibles y 11 ocultas o no visibles. Las skills visibles se representan en el catálogo available_skills dirigido al modelo como metadatos ligeros: nombre de la skill, resumen e indicaciones de requisitos. Sus cuerpos completos de instrucciones se omiten hasta que se carga explícitamente una skill.

Mediciones sobre el catálogo visible actual:

Esto significa que la superficie predeterminada de descubrimiento de skills ocupa aproximadamente una decimotercera parte del conjunto completo de instrucciones de las skills visibles. El modelo sigue pudiendo ver que las capacidades existen, pero no paga todo el coste de sus instrucciones salvo que una tarea realmente las requiera.

Esto respalda la primera afirmación de economía del contexto de la arquitectura: el descubrimiento de skills puede seguir siendo amplio mientras la activación de instrucciones se mantiene selectiva.

9.2 Compresión del registro de herramientas

El efecto en el registro de herramientas es aún más marcado. En el registro progresivo actual, el conjunto base expone solo cuatro herramientas de propósito general:

• load_skill
• list_skills
• search_chats
• fetch_image

Cuando se amplían todos los perfiles de herramientas, el registro contiene 115 herramientas. La diferencia en tokens de esquemas es considerable:

Esto respalda la segunda afirmación de economía del contexto: el espacio predeterminado de acciones ejecutables del modelo es mucho menor que el conjunto total de capacidades de la plataforma.

Con un diseño monolítico, el modelo vería todo el registro en cada turno que permita herramientas. Con la ampliación progresiva del registro, solo ve las herramientas base hasta que una skill cargada activa uno o más perfiles.

9.3 Ejemplos de costes de perfiles activos

Distintos flujos activan distintos perfiles de herramientas. Por tanto, el ahorro depende de la tarea. Un flujo analítico acotado expone muchas menos herramientas que uno de generación de documentos, y ambos exponen muchas menos que un registro totalmente ampliado.

Estos ejemplos ilustran por qué importa la capa intermedia de perfiles. Una tarea de análisis de datos no necesita herramientas de calendario, Slack, edición de documentos, tareas programadas o gestión de perfiles Persona. Una tarea de Slack no necesita ejecución de Python ni herramientas de generación de documentos. Una tarea de documentos puede necesitar el perfil docs, relativamente pesado, pero sigue evitando la mayoría de herramientas de integración y ejecución salvo que se requieran explícitamente.

Por tanto, el sistema desplaza el coste de los esquemas de herramientas de «todo lo disponible para el usuario» a «todo lo justificado por el flujo actualmente activado».

9.4 Interpretación

Estas mediciones validan la premisa de reducción de contexto de la arquitectura, no toda su promesa de comportamiento.

Muestran que el diseño progresivo de NanthAI:Edge reduce de forma considerable:

• la exposición predeterminada de instrucciones de skills;
• la exposición predeterminada de esquemas de herramientas;
• el tamaño del espacio de acciones que afronta el modelo;
• el contenido del prompt que debe mantenerse estable para la caché;
• las herramientas candidatas irrelevantes antes de la activación específica de la tarea.

Sin embargo, las mediciones no demuestran que el modelo enrute mejor, elija herramientas con más exactitud o complete las tareas con mayor éxito. Esas afirmaciones requieren evaluar el comportamiento.

Las mediciones estáticas responden a una pregunta:

¿Reduce realmente el control progresivo de acceso mediante skills la exposición de contexto y esquemas en esta implementación?

La respuesta es sí. En la implementación actual, la reducción es grande: aproximadamente un 92,5 % para las instrucciones de skills y un 97,7 % para el registro base de herramientas respecto a la exposición completa.

10. Conclusión

Los sistemas de IA con agentes afrontan un problema creciente de arquitectura de la información. A medida que se acumulan herramientas, integraciones, flujos y políticas, los diseños monolíticos de prompts y registros de herramientas se vuelven cada vez más costosos y difíciles de evaluar. Las ventanas de contexto grandes ayudan con la capacidad, pero no resuelven la relevancia, el enrutamiento, la estabilidad de caché ni la gobernanza.

El acceso progresivo a herramientas controlado por skills ofrece una alternativa fundamentada. Un catálogo compacto permite descubrir skills. load_skill permite su activación explícita. Las instrucciones de las skills cargadas aportan una guía específica para la tarea. Los perfiles de herramientas permiten una ampliación delimitada del registro. La autorización y las protecciones en tiempo de ejecución conservan los límites de capacidad.

El estudio de caso de NanthAI:Edge muestra cómo se puede implementar este patrón mediante niveles de cuenta, estados de skills por capas, catálogos de skills disponibles, mensajes normalizados de skills cargadas, registros controlados por perfiles y protecciones en tiempo de ejecución. La arquitectura es prometedora porque alinea el coste del contexto con la capacidad activada en lugar de con la capacidad total de la plataforma.

La pregunta central sin resolver es empírica: ¿supera el coste de enrutamiento que introduce seleccionar primero las skills por metadatos los beneficios de reducir la sobrecarga del prompt y del registro? La respuesta dependerá del tamaño del catálogo, del solapamiento entre skills, de la familia del modelo, de la distribución de tareas y de la calidad de la implementación.

Las plataformas de agentes deben exponer las capacidades de forma progresiva, hacer observable el enrutamiento y activar las herramientas solo cuando la tarea las justifique.

Referencias

• Gan, T., & Sun, Q. (2025). RAG-MCP: Mitigating Prompt Bloat in LLM Tool Selection via Retrieval-Augmented Generation. arXiv. https://arxiv.org/abs/2505.03275

• Liu et al. (2025). Lost in the Middle: How Language Models Use Long Contexts. https://arxiv.org/abs/2307.03172

• Gim, I., Chen, G., Lee, S.-s., Sarda, N., Khandelwal, A., & Zhong, L. (2024). Prompt Cache: Modular Attention Reuse for Low-Latency Inference. Proceedings of MLSys 2024. https://proceedings.mlsys.org/paper_files/paper/2024/file/a66caa1703fe34705a4368c3014c1966-Paper-Conference.pdf

• Liu, W., et al. (2024). ToolACE: Winning the Points of LLM Function Calling. arXiv. https://arxiv.org/html/2409.00920v2

• Yang, S., et al. (2023). Improving Planning with LLMs: A Modular Approach. arXiv. https://arxiv.org/html/2310.00194v4

• Wang, et al. (2025). Evaluating Position Bias in Large Language Model Recommendations. arXiv. https://arxiv.org/html/2508.02020v1

• Berkeley Function Calling Leaderboard. https://gorilla.cs.berkeley.edu/leaderboard.html

• Nielsen, J. (2006). Progressive Disclosure. Nielsen Norman Group. https://www.nngroup.com/articles/progressive-disclosure/

• Fowler, M. Function calling using LLMs. https://martinfowler.com/articles/function-call-LLM.html

• AWS. AI agents in enterprises: Best practices with Amazon Bedrock AgentCore. https://aws.amazon.com/blogs/machine-learning/ai-agents-in-enterprises-best-practices-with-amazon-bedrock-agentcore/

• Descripción de la arquitectura de NanthAI:Edge. Material del estudio de caso aportado por el autor; no verificado de forma independiente.

También publicado en LinkedIn.