💻 computer science

ALARA for Agents: Least-Privilege Context Engineering Through Portable Composable Multi-Agent Teams

Este artículo presenta un enfoque de ingeniería de contexto basado en el principio ALARA y una capa de datos declarativa (CAT) junto con la herramienta \texttt{npcsh} para gestionar de forma segura y unificada el acceso a herramientas en sistemas multiagente, evaluando su eficacia en más de 2500 ejecuciones con 22 modelos locales.

Autores originales: Christopher J. Agostino, Nayan D'Souza

Publicado 2026-03-24

📖 5 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Christopher J. Agostino, Nayan D'Souza

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que estás construyendo un equipo de robots muy inteligentes para ayudarte a trabajar. Estos robots son como asistentes personales superpoderosos que pueden buscar en internet, escribir código, organizar archivos y mucho más.

El problema es que, hasta ahora, darle instrucciones a estos robots era como hablarle a un niño pequeño usando solo palabras sueltas en una hoja de papel. Si le decías: "Por favor, no toques la caja de herramientas de electricidad, solo usa la de carpintería", el robot podría entenderte, o podría ignorarte, o podría confundirse si le hablabas de muchas cosas a la vez. A veces, le dabas demasiadas herramientas y se abrumaba; otras veces, le dabas herramientas peligrosas que no necesitaba y podía causar accidentes.

Los autores de este paper, Christopher y Nayan, dicen: "¡Basta de adivinanzas!". Han creado un sistema nuevo llamado ALARA (que significa "lo más bajo razonablemente posible", un concepto que tomaron de la seguridad nuclear) aplicado a los robots.

Aquí te explico cómo funciona su sistema con una analogía sencilla:

1. El Sistema de "Cajas de Herramientas" (Jinxes y NPCs)

Imagina que tienes un taller gigante. En lugar de dejar todas las herramientas sueltas en el suelo para que el robot elija, el sistema crea cajas de herramientas específicas para cada tarea.

Las "Jinxes" (Herramientas): Son como recetas o instrucciones escritas en un formato que la computadora entiende perfectamente (no solo texto). Si una herramienta dice "Cortar madera", el robot sabe exactamente cómo hacerlo. No hay ambigüedad.
Los "NPCs" (Los Robots): Cada robot tiene su propia tarjeta de identificación. En esa tarjeta, el humano escribe una lista: "Este robot solo puede usar la caja de herramientas de 'Carpintería' y 'Pintura'".
La Magia: Si el robot intenta usar un martillo eléctrico (que no está en su lista), el sistema le dice: "No, eso no existe para ti". No es que el robot decida no hacerlo; es que, para el sistema, esa herramienta literalmente no existe en su mundo. Esto evita errores y hace que el robot sea mucho más seguro.

2. El Problema de la "Memoria Larga"

Los robots a veces se confunden si les das demasiada información a la vez. Es como si le pidieras a alguien que cocine una cena compleja mientras le estás contando toda la historia de su vida. Se olvida de lo que tiene que hacer.

El sistema de los autores divide el trabajo en equipos pequeños.

Si tienes una tarea grande, un "capitán" (un robot coordinador) no le habla a todos los robots de golpe.
El capitán llama a un "sub-equipo" (por ejemplo, el equipo de investigación).
El equipo de investigación solo ve sus propias notas y herramientas. El capitán no se entera de los detalles confusos del equipo de investigación, y viceversa. Esto mantiene la mente de cada robot clara y enfocada.

3. La Prueba de Fuego (El Experimento)

Los autores probaron su sistema con 22 robots diferentes (desde versiones muy pequeñas y rápidas hasta versiones gigantes y complejas) y les dieron 115 tareas reales (como buscar información en la web, escribir scripts, o delegar tareas a otros robots).

¿Qué descubrieron?

No es solo cuestión de tamaño: Tener un robot "gigante" (con más inteligencia) no siempre es mejor. Un robot más pequeño, pero entrenado específicamente para usar herramientas, hizo un trabajo mucho mejor que un robot gigante que no sabía cómo usarlas. Es como tener un Ferrari (robot gigante) que no sabe conducir, frente a un coche pequeño (robot pequeño) con un conductor experto.
Más herramientas no es mejor: Darle al robot 100 herramientas hizo que cometiera más errores. Darle solo las 3 o 4 que realmente necesitaba lo hizo más rápido y preciso.
El error de delegar: La parte más difícil para todos los robots fue "delegar" (pedirle a otro robot que haga algo). A menudo, cuando un robot falla y le pides que lo intente de nuevo, se confunde más porque recuerda el error anterior. A veces, es mejor empezar de cero con una mente fresca.

En Resumen

Este paper nos dice que para que los robots (IA) trabajen bien con nosotros, no debemos confiar en que "entiendan" nuestras instrucciones de texto. En su lugar, debemos diseñar sus límites y herramientas de forma estructural, como si fueran planos de construcción.

Antes: "Por favor, sé cuidadoso y no uses herramientas peligrosas". (El robot podría fallar).
Ahora: "Tu caja de herramientas solo tiene un destornillador y un martillo. No hay herramientas peligrosas en tu caja". (El robot no puede fallar en ese aspecto).

Es como pasar de darle instrucciones verbales a un niño para que no se meta en la cocina, a ponerle un candado en la puerta de la cocina y darle solo las llaves de su habitación. Es más seguro, más claro y funciona mejor.

1. El Problema

Los sistemas multi-agente basados en modelos de lenguaje grandes (LLM) han proliferado, pero la infraestructura que los gobierna (el "arnés" o harness del agente) carece de un mecanismo unificado y escalable para gestionar aspectos críticos como el acceso a herramientas, los límites de comportamiento y la coordinación entre agentes.

Actualmente, las especificaciones de comportamiento están fragmentadas en:

Archivos de instrucción en prosa (ej. .cursorrules, CLAUDE.md): Dependen de la interpretación del modelo, lo cual no es garantizable debido a la naturaleza contextual de la generación de significado en los LLM.
Código de configuración interna de frameworks: Difícil de auditar o modificar sin experiencia profunda.
Servidores MCP: Limitan el alcance de las herramientas al servidor, no al agente individual.

Esta fragmentación provoca tres problemas principales:

Degradación del rendimiento: Las instrucciones clave se pierden en el contexto a medida que crece el historial de conversación.
Fallas de especificación: Un análisis de 1,600 trazas mostró que el 44% de los fallos se deben a especificaciones deficientes, no a la capacidad del modelo.
Vulnerabilidades de seguridad: El acceso excesivo a herramientas (privilegios excesivos) crea superficies de ataque para inyección de prompts.

2. Metodología y Diseño

Los autores proponen aplicar el principio ALARA (As Low As Reasonably Achievable), originario de la seguridad radiológica, al contexto de los agentes: limitar el acceso a herramientas y contexto al mínimo estrictamente necesario para el rol del agente.

Para lograrlo, introducen npcsh, un shell de línea de comandos y una capa de datos declarativa llamada CAT (Context-Agent-Tool). El sistema se basa en archivos estructurados que el sistema puede analizar y aplicar, en lugar de instrucciones en prosa que el modelo debe interpretar.

Componentes Clave del Sistema CAT:

Archivos de Contexto (context): Definen equipos, sub-equipos y el agente orquestador.
Archivos NPC (NPC): Definen agentes individuales. Específicamente, incluyen una lista de Jinxes permitidos. Esta lista actúa simultáneamente como catálogo de herramientas y conjunto de permisos. Si una herramienta no está en la lista, no existe en el esquema del agente, eliminando la posibilidad de invocación accidental o maliciosa.
Jinxes: Plantillas de ejecución en YAML (basadas en Jinja) que definen las herramientas.
- Cada Jinx especifica nombre, descripción, entradas tipadas y pasos de ejecución.
- Pueden encadenarse para formar grafos acíclicos dirigidos (DAG) de capacidades compuestas.
- Funcionan mediante flujos basados en prompts, lo que permite su uso con modelos locales pequeños que no soportan llamadas a funciones nativas estructuradas.

Evaluación (Benchmark)

Modelos: 22 modelos alojados localmente de 9 familias (desde 0.6B hasta 35B parámetros), ejecutados en hardware de consumo.
Tareas: 115 tareas prácticas en 13 categorías (operaciones de archivos, búsqueda web, encadenamiento de herramientas, delegación multi-agente, etc.).
Métricas: Se analizaron 2,530 ejecuciones, midiendo tasas de éxito, conteo de llamadas a herramientas, duración y estrategias de reintento.

3. Contribuciones Clave

Capa de Datos Declarativa (CAT): Una arquitectura basada en archivos que permite la gestión portátil y composicional de equipos de agentes, separando la definición de herramientas (Jinxes) de la definición de agentes (NPC).
Aplicación Estructural de Menos Privilegio: A diferencia de las instrucciones en prosa, el sistema elimina estructuralmente las herramientas no permitidas del esquema del agente, garantizando que el modelo no pueda invocarlas, independientemente de la inyección de prompts.
npcsh: Una interfaz de shell que unifica la ejecución interactiva humana y la orquestación automática de agentes bajo el mismo conjunto de archivos.
Benchmark de Evaluación Robusto: Un conjunto de pruebas diseñado para ser agnóstico al framework, permitiendo comparar la capacidad real de los modelos en tareas de agentes sin confundirla con la orquestación del framework.

4. Resultados Principales

La familia del modelo es más importante que el tamaño: Las diferencias entre familias de modelos superan a las diferencias dentro de la misma familia al escalar parámetros. Los modelos entrenados específicamente para el uso de herramientas (como Qwen3.5) alcanzan puntuaciones del 88% con 35B parámetros, mientras que modelos no entrenados para ello (como Gemma3) no superan el 57% incluso con 27B parámetros.
Correlación con MMLU: Existe una relación lineal fuerte ( $r \approx 0.8$ ) entre la inteligencia general (MMLU) y el rendimiento de agencia, pero hay outliers que indican que el entrenamiento específico para herramientas es un factor determinante.
Volumen de Llamadas a Herramientas: El número medio de llamadas a herramientas por tarea es el predictor más fuerte del éxito ( $r \approx 0.7$ ), superando a la duración de la tarea o al número de intentos. Los modelos exitosos hacen más llamadas, no necesariamente más intentos.
Efectividad de los Reintentos: El 80% de las tareas exitosas se completan en el primer intento. El valor de los reintentos varía drásticamente según la categoría de la tarea (ej. +21% en búsqueda web vs. +3% en delegación). En tareas complejas como la delegación, los reintentos a menudo degradan el rendimiento debido a la pérdida de contexto o historial.
Dificultad de la Delegación: La delegación entre agentes es la categoría más difícil para todos los modelos, con las tasas de éxito más bajas y la menor ganancia por reintento, sugiriendo que los fallos son principalmente de especificación y diseño más que de capacidad del modelo.

5. Significado e Impacto

El trabajo demuestra que la fiabilidad en el uso de herramientas es una capacidad entrenada distinta que los benchmarks generales no predicen con precisión. Al mover la especificación de comportamiento de la "prosa interpretativa" a la "especificación declarativa estructurada", el sistema:

Mejora la Seguridad: Elimina la superficie de ataque de la inyección de prompts al restringir el esquema de herramientas.
Facilita el Mantenimiento: Permite a los equipos colaborar en la definición de agentes mediante archivos versionables, similar a "Infraestructura como Código" (IaC).
Optimiza Recursos: Al identificar que ciertos modelos pequeños pero bien entrenados superan a modelos grandes no entrenados, permite el uso eficiente de hardware local.
Establece un Nuevo Estándar: Propone que la ingeniería de contexto debe ser un proceso de restricción estructural (ALARA) en lugar de una instrucción abierta.

El framework y el benchmark son de código abierto en https://github.com/NPC-Worldwide/npcsh.