Agent Plugins 1.0: un formato de paquete para todos los agentes de IA

¿Qué es Agent Plugins? Agent Plugins 1.0 es un estándar de empaquetado abierto y neutral respecto al proveedor —publicado el 6 de agosto de 2026— que agrupa Agent Skills y configuraciones de servidores MCP en un directorio portable que cualquier cliente de agente compatible puede cargar. Un plugin es una carpeta con un manifiesto plugin.json obligatorio, una carpeta skills/ opcional con Agent Skills y un mcp.json opcional que declara servidores MCP. ChatGPT, Codex, Cursor, GitHub Copilot, Kiro y VS Code lo admiten desde el lanzamiento.¹²

Seis empresas que compiten entre sí todos los días publicaron una respuesta compartida a un problema que todo usuario de agentes ha sentido: la extensión que construiste para un cliente de agente no funciona en el siguiente. Vercel impulsó la propuesta y desarrolló la especificación junto con Amazon, Anysphere (creadora de Cursor), GitHub, Microsoft y OpenAI;² Google anunció ese mismo día que se suma a los mantenedores principales y que está integrando el soporte en sus propios productos.⁶ El resumen de una línea del sitio oficial: «un formato de paquete portable para componentes reutilizables que extienden agentes de IA».¹

El nombre de la empresa que creó las dos capas que aquí se empaquetan no aparece en la lista de mantenedores. Esa ausencia es la mitad de la historia, y la segunda mitad de este artículo.

TL;DR: Agent Plugins 1.0 estandariza la capa de empaquetado alrededor de dos especificaciones que ya existían —Agent Skills y el Model Context Protocol— y no reemplaza a ninguna: fija dónde vive cada una dentro de un directorio que se puede compartir.¹ Un plugin es una carpeta: plugin.json para la identidad, skills/ para las habilidades, mcp.json para los servidores, más carpetas de espacio de nombres en dominio invertido para los extras propios de cada cliente. La versión 1 es deliberadamente un piso de interoperabilidad: la especificación no define semántica portable para la instalación, los registros, los permisos, la procedencia, los secretos ni OAuth; todo eso queda en manos de cada cliente.¹² Codex lanzó el soporte entre las versiones v0.146.0 y v0.147.0.⁴ Anthropic, que creó Agent Skills y MCP, no está entre los mantenedores: Claude Code conserva su propio formato de plugins.³⁷⁸

Puntos clave

• Desarrolladores independientes: escribe tus habilidades como Agent Skills estándar (una carpeta con un SKILL.md) y ya tendrás el sustrato portable; envolverlas en un plugin es cuestión de un manifiesto. Deja de mantener una copia por cliente.
• Líderes de equipo: el estándar cubre el empaquetado, no la distribución ni las políticas. Tu registro, tu mecanismo de actualización y tu estrategia de listas de permitidos siguen siendo decisiones de cada cliente; presupuéstalo antes de prometer internamente un «escribir una vez, ejecutar en todas partes».
• Ingenieros de seguridad: la versión 1 no define capa de procedencia ni de permisos, y tampoco una capa de firma: la decisión de confianza se traslada por completo a tu revisión en el momento de instalar. La portabilidad amplía el radio de impacto de los ataques por habilidad envenenada.

Qué se lanzó

El 6 de agosto de 2026, Vercel publicó Agent Plugins 1.0.0, una especificación abierta que impulsó y desarrolló junto con Amazon, Anysphere, GitHub, Microsoft y OpenAI.² La especificación normativa vive en un repositorio público cuya lista de mantenedores abarca Amazon, Cursor, Microsoft, OpenAI y Vercel,³ y Google anunció el día del lanzamiento que se suma a ese grupo como mantenedor principal, con soporte que ya está llegando a sus propias herramientas de agentes.⁶

La lista de clientes disponibles desde el primer día abarca las superficies más grandes del ecosistema: VS Code, Cursor, GitHub Copilot, ChatGPT y Codex, además de Kiro.¹² El soporte en la CLI de Codex en realidad se adelantó al anuncio público: la v0.146.0 (29 de julio) agregó los manifiestos de Agent Plugins y la publicación de plugins de espacio de trabajo, y la v0.147.0 (7 de agosto) cerró el círculo con la instalación portable de plugins y la búsqueda en catálogos locales, personales, de espacio de trabajo y remotos.⁴

El alcance queda dicho en la línea inicial de la propia especificación: «define la Especificación canónica de Agent Plugins v1.0.0 para empaquetar componentes reutilizables que extienden agentes de IA en plugins distribuibles».¹ Empaquetado, no un nuevo lenguaje de habilidades ni un reemplazo de MCP. Ambos formatos subyacentes conservan sus propias especificaciones; este estándar fija dónde viven dentro de un directorio que un cliente puede descubrir.

La anatomía de un plugin

Un plugin es un directorio con un archivo obligatorio y tres superficies opcionales:¹

my-plugin/
├── plugin.json              # required: identity + metadata
├── skills/                  # optional: Agent Skills
│   └── release-notes/
│       └── SKILL.md         # one immediate subdirectory = one skill
├── mcp.json                 # optional: MCP server configs
└── com.example.client/      # optional: client-namespace directory

plugin.json es un manifiesto de esquema cerrado. Los campos de primer nivel permitidos son exactamente diez: $schema, name, version, description, author, homepage, repository, license, keywords y extensions, y la especificación es estricta con todo lo demás: «Los clientes DEBEN reportar e ignorar cada campo desconocido y DEBEN continuar cargando el plugin si el manifiesto cumple por lo demás con esta sección».¹ El campo name admite caracteres alfanuméricos en minúscula, guiones y puntos, con el primer y el último carácter alfanuméricos y sin guiones ni puntos consecutivos.¹

skills/ guarda Agent Skills tal como ya existen: «Cada directorio hijo inmediato que contenga una ruta llamada exactamente SKILL.md y que resuelva a un archivo regular se trata como una habilidad».¹ mcp.json declara servidores MCP; un cliente que admita servidores MCP de plugins «DEBE admitir al menos uno de stdio o streamable-http» y DEBERÍA admitir ambos, con sse opcional, y la especificación permite de forma explícita que un cliente que solo maneje habilidades sea conforme sin admitir ningún servidor MCP.¹

Los directorios en dominio invertido como com.example.client/ alojan el comportamiento propio de cada cliente, con la regla de portabilidad escrita en lenguaje normativo: «Un cliente DEBE ignorar las entradas del manifiesto correspondientes a espacios de nombres que no implementa, sin validar el contenido de sus valores».¹

Ese último mecanismo pesa más de lo que parece. Los componentes que más difieren entre clientes quedan cercados fuera del núcleo portable: comandos, hooks, agentes, reglas y servidores LSP son los ejemplos que da la propia especificación de tipos de componentes que «siguen siendo demasiado específicos de cada cliente para un contrato portable estable» y quedan fuera del formato v1 hasta que sus formatos converjan.¹ El núcleo portable son las habilidades más las configuraciones de MCP, y nada más.

Lo que la versión 1 deja fuera a propósito

La especificación estandariza la cosa más pequeña que podría funcionar. No define semántica portable para la instalación, los registros, los permisos, la procedencia, los secretos ni OAuth —cada uno de esos puntos queda en manos del cliente¹²— y tampoco define una capa de firma. La ruta de expansión de los mantenedores es conservadora por diseño: los tipos de componentes ascienden al núcleo portable solo cuando las implementaciones convergen lo suficiente como para definirlos con precisión.¹

Léelo como física de coaliciones, no como timidez. Seis empresas —cinco de ellas con clientes de agentes de formatos de plugins incompatibles— pudieron ponerse de acuerdo en dónde viven los archivos; no pudieron ponerse de acuerdo, todavía, en cómo se disparan los hooks, cómo se registran los comandos o qué modelo de permisos gana. Así que el estándar congeló la capa donde el comportamiento ya había convergido (las habilidades son carpetas de markdown, MCP es un protocolo de comunicación) y encerró en espacios de nombres todo lo que sigue en disputa. Es un piso de interoperabilidad, y los pisos sirven precisamente porque todos pueden pararse sobre ellos.

El costo de ese piso: el «construir una vez, ejecutar en todas partes» aplica al paquete, no a la experiencia. Un plugin se instala en todas partes; lo que puede hacer sigue variando según el cliente, y cómo se instala, se actualiza y se le otorga confianza depende por completo de cada cliente.

El hueco con forma de Anthropic

Aquí viene lo extraño. Agent Skills —el formato de carpetas de instrucciones que el estándar empaqueta— es una creación de Anthropic, anunciada en octubre de 2025.⁸ También lo es el Model Context Protocol, que Anthropic liberó como código abierto en noviembre de 2024.⁷ Las dos capas que sostienen este estándar de empaquetado vienen del único proveedor grande de herramientas de agentes cuyo nombre no aparece en ninguna parte de la lista de mantenedores.³

Claude Code conserva su propio formato de plugins —su manifiesto, sus fuentes de marketplace, su empaquetado de hooks y comandos— y nada de lo anunciado el 6 de agosto cambia eso. El puente, por ahora, va en una sola dirección: Codex incluye una fuente de marketplace de Claude Code (v0.146.0), y su comando /import migra a Codex la configuración de Claude Code, los servidores MCP, los plugins, las sesiones, los comandos y las memorias con alcance de proyecto.⁴

En la práctica, la costura es más angosta de lo que sugiere el organigrama, y la razón es el sustrato: una habilidad es una carpeta con un SKILL.md, en todos los ecosistemas. Las habilidades que escribes para Claude Code son el mismo artefacto que transporta un Agent Plugin. Lo que no viaja es la envoltura —el manifiesto de plugins de Claude Code de un lado, plugin.json del otro— y los componentes propios de cada cliente (los hooks sobre todo) que cada ecosistema mantiene nativos. Si hoy mantienes habilidades, ya estás escribiendo la capa portable; la divergencia está en el empaquetado, no en el contenido.

Si Anthropic termina adoptando el formato, publicando un equivalente o dejando el puente en una sola dirección es la pregunta abierta que plantea este lanzamiento. La composición de la coalición —todos los proveedores grandes de clientes de agentes menos uno— hace que la trayectoria del estándar de empaquetado dependa menos de sus méritos técnicos que de si la autora ausente de sus dos capas subyacentes decide que vale la pena pararse sobre ese piso.

La pregunta de cadena de suministro que nadie estandarizó

Un formato de paquete portable sin capa de procedencia también es un formato de ataque portable. La versión 1 deja la procedencia y los permisos en manos de cada cliente y no define herramientas de firma ni de validación,¹ lo que significa que la decisión de confianza vive por completo en el momento de la instalación, cliente por cliente y usuario por usuario.

Eso importa más este mes que el pasado. La investigación reciente sobre ataques a nivel de habilidad —ElasticBack es el ejemplo más nítido— demuestra puertas traseras condicionales plantadas en un solo documento de habilidad, y describe las habilidades de agente como «una cadena de suministro emergente donde una sola habilidad envenenada puede comprometer de forma persistente a todo agente que la instale».⁵ La portabilidad multiplica eso: el mismo plugin envenenado ahora se instala en seis clientes en lugar de uno, y el alcance del estándar deja la detección a la revisión que haga cada cliente (o cada usuario).

Desarrollé el argumento completo antes de que existiera este estándar en Las habilidades para agentes necesitan gestores de paquetes: el contexto de agente se convirtió en una cadena de suministro de software, e instalarlo con seguridad exige la maquinaria que los ecosistemas de paquetes ya aprendieron a construir: manifiestos, archivos de bloqueo, instalaciones con alcance acotado, controles de revisión y reversión. Agent Plugins 1.0 entrega el manifiesto y se detiene ahí; el resto de esa lista es exactamente lo que la v1 les deja a los clientes. Inspecciona lo que instalas; el formato no lo hará por ti. (Una trampa vecina, tomada de Las habilidades que mi agente no podía ver: los agentes cargan las descripciones de las habilidades con un presupuesto de contexto estricto, y las habilidades que llegan dentro de plugins se suman a ese mismo catálogo; la portabilidad agrega habilidades a una fila que ya trunca en silencio.)

Qué hacer hoy

Si usas Codex: ya tienes el estándar. codex plugin expone la instalación portable de Agent Plugins, y la búsqueda de plugins abarca catálogos locales, personales, de espacio de trabajo y remotos desde la v0.147.0.⁴ Los equipos pueden publicar plugins en su propio espacio de trabajo en lugar de montar un marketplace público.

Si usas Claude Code: nada cambia en tu formato de plugins. Sigue escribiendo tus habilidades como carpetas de habilidades estándar —esa es la capa portable— y trata la envoltura como algo desechable. Si además usas Codex, su fuente de marketplace de Claude Code y su comando /import trasladan tu configuración existente.⁴

Si usas VS Code, Cursor, Copilot, ChatGPT o Kiro: estás en la lista de clientes del lanzamiento; cómo se instalan los plugins es asunto de la experiencia de tu cliente, porque el estándar deliberadamente no lo especifica.¹

Si desarrollas herramientas para desarrolladores: el manifiesto es lo bastante pequeño como para adoptarlo en una tarde, y el repositorio de la especificación es público.³ La decisión interesante no es si leer plugin.json, sino cuáles de tus componentes encierras en tu espacio de nombres de dominio invertido, porque esa frontera es la declaración de facto de lo que consideras portable.

Preguntas frecuentes

¿Agent Plugins reemplaza a MCP o a Agent Skills?

No. El trabajo declarado de la especificación es «empaquetar componentes reutilizables que extienden agentes de IA en plugins distribuibles»:¹ las habilidades conservan su formato SKILL.md, los servidores MCP conservan su protocolo, y el estándar fija dónde viven ambos dentro de un directorio que se puede compartir.

¿Un plugin puede traer hooks, comandos slash o agentes personalizados?

De forma portable no, y no en la v1. La especificación nombra comandos, hooks, agentes, reglas y servidores LSP como ejemplos de tipos de componentes que «siguen siendo demasiado específicos de cada cliente para un contrato portable estable», fuera del formato portable hasta que sus formas converjan. Un cliente puede llevarlos dentro de su directorio de espacio de nombres en dominio invertido, y los clientes DEBEN ignorar los espacios de nombres que no implementan.¹ El núcleo portable son las habilidades más las configuraciones de MCP.

¿Por qué Anthropic no forma parte del estándar?

Ni la especificación ni la coalición lo han dicho. Lo que sí es público: la lista de mantenedores abarca Amazon, Cursor, Microsoft, OpenAI y Vercel, más Google sumándose en el lanzamiento,³⁶ mientras que Anthropic —creadora tanto de Agent Skills como de MCP⁷⁸— está ausente, y Claude Code conserva su propio formato de plugins. El puente práctico hoy está del lado de Codex: su fuente de marketplace de Claude Code y su migración con /import.⁴

¿Es seguro instalar Agent Plugins de terceros?

El formato no te ayuda a decidirlo: la versión 1 deja los permisos y la procedencia en manos de cada cliente y no define herramientas de firma ni de validación.¹ Trata un plugin como cualquier código al que le concedes tus privilegios. La investigación sobre puertas traseras a nivel de habilidad (ElasticBack) muestra que un solo documento de habilidad envenenado puede comprometer de forma condicional a todo agente que lo instale, y la portabilidad multiplica la base instalada.⁵

Referencias