Agent Extension Packages
Packaging de capacidades y artefactos
Un Agent Extension Package es una unidad distribuible que agrega o configura capacidades y artefactos admitidos por un host de agentes. Puede agrupar instrucciones, procedimientos, integraciones y recursos. Es una definición de trabajo del Atlas: describe packaging y distribución, sin imponer un manifiesto único ni afirmar que todos los paquetes tengan el mismo contenido o mecanismo de instalación.
El problema aparece cuando varias piezas relacionadas deben compartirse y mantenerse juntas. Un equipo puede querer distribuir procedimientos de revisión y recursos de apoyo como una unidad versionada. El paquete facilita esa distribución, pero no reemplaza el significado de cada pieza. Una skill incluida sigue siendo una skill; una configuración de integración sigue necesitando un cliente que la interprete.
Empaquetar también agrega decisiones sobre procedencia, versiones y compatibilidad. Un paquete puede ser legible y, aun así, depender de herramientas ausentes o proponer operaciones fuera del scope autorizado. El inventario de componentes describe disponibilidad potencial; no demuestra que el agente pueda o deba utilizarlos en cualquier tarea.
Plugin vs Extension
Plugin y Extension son nombres frecuentes de mecanismos de extensibilidad. Los proveedores pueden usarlos para unidades parecidas o para superficies diferentes. El Atlas los agrupa aquí cuando describen paquetes para extender sistemas de agentes, sin declarar que ambos términos sean sinónimos universales ni que compartan un formato portable.
Un producto puede llamar plugin a un bundle con varias capacidades y otro extension a una integración con su CLI. La categoría conceptual depende de su responsabilidad de distribución y carga, no de la palabra elegida. Tampoco se pretende redefinir aquí la arquitectura general de plugins de aplicaciones: el foco son artefactos utilizados en entornos de desarrollo con agentes.
Esta distinción permite mantener estable la navegación aunque cambie el catálogo de productos. Un nuevo filename, marketplace o mecanismo de instalación no exige un canonical distinto si sigue representando la misma responsabilidad. Las diferencias técnicas pueden documentarse como ejemplos fechados o, cuando se justifique, en futuras Technology Notes.
Contenidos posibles
Un paquete puede incluir agent-skills, agent-profiles, lifecycle-hooks, prompts, comandos, configuración de servidores MCP o recursos de apoyo, según lo que soporte su host. No hay una lista universal obligatoria. Distribuir solo skills puede ser suficiente; exigir todas las categorías introduciría componentes innecesarios y compatibilidad que el autor no necesita mantener.
| Contenido posible | Responsabilidad que conserva |
|---|---|
| Skill | Procedimiento reutilizable para una clase de tareas. |
| Profile | Configuración de una especialización. |
| Hook | Comportamiento asociado a un evento del runtime. |
| Prompt | Estructura de encargo o interacción. |
| Configuración MCP | Integración que el cliente deberá interpretar. |
| Recursos | Referencias, scripts, ejemplos o assets de apoyo. |
La unidad de distribución y la unidad de uso pueden diferir. El usuario puede instalar un paquete y utilizar una sola skill. Un hook incluido puede permanecer deshabilitado o requerir confianza adicional. Por eso interesa distinguir qué llega al entorno, qué se descubre, qué se habilita y qué se ejecuta realmente.
Package vs Skill, Profile y Hook
Una skill conserva una capacidad o procedimiento. El paquete puede distribuir varias junto con otros artefactos, sin convertirse él mismo en un procedimiento. Actualizar el paquete puede cambiar una skill y dejar otras intactas. Si solo se informa la versión del bundle, puede faltar detalle para entender qué comportamiento intervino en una tarea concreta.
Un perfil configura un especialista. El paquete puede entregar esa definición cuando el host la admite, pero no inicia automáticamente una ejecución ni asigna un encargo por contenerla. La delegación, el contexto y los permisos de la ejecución resultante conservan contratos propios. El nombre del paquete no identifica necesariamente al actor que realizó el trabajo.
Un hook establece comportamiento asociado a eventos. Su configuración puede venir en un paquete, pero el host debe reconocerla y aplicar sus condiciones de carga. Instalar no demuestra que el handler esté activo ni que sus efectos estén autorizados. A su vez, un hook puede existir sin un paquete de extensión. Distribución y semántica de ejecución siguen separadas.
Package vs MCP y MCP Protocol Extension
MCP es un protocolo de interoperabilidad entre sistemas AI y capacidades o contexto expuestos mediante clientes y servidores. Un paquete puede distribuir configuración para conectar un servidor, pero no es el protocolo ni el servidor. Declarar una conexión tampoco demuestra que el servicio exista, sea accesible o autorice las operaciones solicitadas.
Una MCP Protocol Extension modifica o amplía capacidades dentro del marco de extensiones del protocolo. Una extensión de producto puede agregar funciones del cliente sin constituir esa clase de extensión protocolar. La palabra extension aparece en ambos contextos, pero sus responsabilidades y contratos son distintos. La extensión oficial de skills para MCP sirve como ejemplo de esa frontera, sin desarrollarla aquí.
En particular, incluir configuración MCP en un plugin no crea una MCP Protocol Extension. Incluir una skill que utiliza una herramienta expuesta por MCP tampoco cambia el protocolo. Mantener esos niveles evita convertir cada integración de producto en un nuevo mecanismo de interoperabilidad o atribuir al bundle garantías que pertenecen al cliente, servidor y autorización externa.
| Comparación | Qué separa al paquete |
|---|---|
| Package / Skill | Distribuye artefactos; la skill aporta un procedimiento. |
| Package / Profile | Entrega configuración; el perfil define una especialización. |
| Package / Hook | Puede entregar el handler; el hook relaciona evento y comportamiento. |
| Package / MCP | Packaging frente a protocolo de interoperabilidad. |
| Package / MCP Protocol Extension | Extensión de un host frente a extensión del contrato protocolar. |
La tabla no prohíbe combinar piezas. Ayuda a ubicar dónde investigar un fallo: distribución, configuración, ejecución o interoperabilidad. Cambiar el paquete completo puede resultar innecesario si el problema pertenece únicamente a una conexión o a una instrucción particular.
Especificaciones abiertas y formatos de producto
La especificación Agent Plugins consultada el 2026-10-26 identifica su versión como 1.0.0 y define un núcleo portable para skills y configuración MCP. También contempla extensiones de cliente con namespaces. Ese núcleo no convierte todos los formatos existentes en equivalentes ni incluye automáticamente cualquier categoría de artefacto de un proveedor.
La instalación, la distribución y las decisiones de permisos permanecen bajo contratos de los clientes. La guía de client extensions permite distinguir el núcleo compartido de capacidades particulares. Un paquete reconocible por varios hosts puede depender de una extensión que solo uno comprende. Por tanto, compatibilidad del manifiesto y equivalencia funcional requieren comprobaciones diferentes.
Los siguientes ejemplos de producto se consultaron en la misma fecha. Se conservan como referencias actuales, sin convertir sus directorios o campos en reglas del Atlas.
| Fuente | Ejemplo de extensibilidad | Límite |
|---|---|---|
| Claude Code plugins | Agrupación de capacidades soportadas por Claude Code. | Su contrato no define todo paquete de agentes. |
| Codex plugins | Distribución e integración dentro de Codex. | Carga y confianza dependen del cliente. |
| Gemini CLI extensions | Extensiones para capacidades del CLI. | Reconocer el nombre extension no garantiza compatibilidad con plugins ajenos. |
La existencia de una especificación abierta reduce parte del costo de intercambio, pero no elimina diferencias de modelos, herramientas, contexto o políticas. Tampoco vuelve obligatorio usar ese formato para cualquier integración. El Atlas conserva el concepto de paquete aunque el ecosistema evolucione y requiera revisar los ejemplos técnicos.
Claude Code muestra paquetes con skills, subagents, hooks y configuración MCP; cada componente también puede existir fuera del plugin. Codex documenta que las conexiones externas pueden requerir configuración o autenticación adicional y conservan controles del servicio. Son diferencias de carga y uso que el bundle no elimina. Gemini CLI utiliza el término extensions para su integración propia. No se infiere una equivalencia de componentes, manifiestos o permisos entre los tres a partir de sus nombres: la unidad compartida aquí es el propósito de distribuir extensibilidad, no un contrato idéntico de ejecución.
Instalación, discovery, confianza y activación
Instalar puede significar obtener o registrar archivos. Discovery permite conocer componentes disponibles. Habilitar determina si el host los considera utilizables bajo su configuración. Confiar implica una decisión sobre contenido y efectos permitidos. Activar es usar una capacidad o disparar un comportamiento en una ejecución. Un producto puede combinar algunas acciones en su interfaz sin eliminar sus diferencias conceptuales.
En Commerce, un paquete de revisión podría incorporar una skill y un handler. Cargar el procedimiento para una revisión no demuestra que el handler se ejecutó. Aceptar la instalación tampoco debería interpretarse como aprobación general para que sus scripts modifiquen servicios externos. La autoridad relevante necesita examinarse donde ocurre cada acción.
La configuración de un paquete puede cambiar entre versiones. Una actualización podría incorporar un nuevo handler o destino remoto aun conservando el mismo nombre comercial. Revisar solamente que el paquete siga instalado puede ocultar esa diferencia. La evidencia útil conecta la versión realmente cargada con los componentes y capacidades utilizados en la tarea.
Versioning y compatibilidad
Un paquete versionado permite identificar una unidad de distribución, pero la versión no garantiza compatibilidad semántica. Importan el host y sus funciones admitidas, las dependencias, los recursos y el comportamiento esperado. Incluso una actualización declarada compatible puede alterar instrucciones de una manera relevante para las tareas del equipo.
Conviene separar incompatibilidad de formato, de capacidades y de conducta. Un manifiesto puede no parsearse; un componente puede cargarse pero requerir una herramienta ausente; un procedimiento puede ejecutarse y producir decisiones distintas. Esas fallas necesitan diagnósticos diferentes. «El plugin funciona» resulta demasiado amplio si solo se comprobó que aparece en una lista.
No se prescribe un sistema de dependencias, resolución automática o actualización universal. Cuando un producto admite esos mecanismos, su contrato debe examinarse. Un paquete que declara otro recurso no prueba que el recurso esté disponible ni que su procedencia sea aceptable. YAGNI favorece distribuir lo necesario y comprobar las integraciones reales antes de diseñar un framework de extensiones propio.
Supply Chain y ejecución
Los paquetes son inputs de supply chain porque pueden incorporar instrucciones, scripts, configuraciones y conexiones externas. El riesgo no se limita a código ejecutable: una instrucción puede orientar acciones indebidas si se le atribuye autoridad que no tiene. La procedencia y revisión del contenido importan junto con sus capacidades técnicas.
agent-permissions-and-approval-boundaries conserva autorización; agent-sandboxing limita recursos y consecuencias; agent-execution-environment ubica la ejecución. Ninguno de esos controles se deduce del nombre del paquete. Un handler puede actuar con permisos del proceso y un servidor remoto con otra identidad. La evaluación necesita distinguir esas fronteras.
No todo paquete requiere el mismo tratamiento. Una colección de referencias estáticas y un bundle que ejecuta scripts o conecta servicios tienen superficies distintas. La revisión debe ser proporcional a contenido y uso, sin presentar una firma, catálogo o popularidad como prueba completa de seguridad. AI Security tendrá desarrollo posterior; aquí se conserva el motivo de examinar procedencia y efectos.
Relaciones y fuentes
agent-harness puede implementar carga de extensiones y mediar sus componentes. persistent-instructions sigue siendo guía, aunque se distribuya mediante un paquete. development-context-and-execution-records puede conservar qué versión intervino cuando resulte relevante. ai-assisted-software-engineering conecta estas piezas sin recomendar instalar un bundle ni exigir plugins para trabajar con agentes.
Fuentes primarias consultadas el 2026-10-26. Definición, distinciones y ejemplos son síntesis editorial. Los detalles de especificaciones y productos pueden evolucionar.
- Agent Plugins: Specification y client extensions.
- Anthropic: Plugins.
- OpenAI: Plugins.
- Google: Gemini CLI extensions.
- MCP: Agent Skills extension, para la frontera protocolar.