Agent Plugins: el nuevo estándar abierto para extensiones de agentes de IA

Lo que realmente es Agent Plugins

Me dedico a construir integraciones, así que mi primera reacción ante cualquier estándar nuevo es comprobar cuánto es especificación real y cuánto es nota de prensa. Este, en su mayor parte, es especificación.

Agent Plugins se describe a sí mismo como un estándar abierto y neutral respecto a los proveedores para empaquetar componentes reutilizables que extienden a los agentes de IA. En la práctica estandariza una sola cosa: la forma de la carpeta. Dónde vive el manifiesto, qué campos puede contener, dónde debe buscar un cliente las skills y dónde debe buscar la configuración del servidor MCP. Todo lo demás, incluida la instalación, los marketplaces, los permisos y toda la experiencia de usuario, queda en manos de cada cliente.

El plugin más pequeño que hace algo consta de tres archivos:

hello-plugin/
├── plugin.json
└── skills/
    └── greet/
        └── SKILL.md

Y el manifiesto puede tener dos líneas:

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
  "name": "hello-plugin"
}

Eso es todo. $schema y name son los únicos campos obligatorios. Todo lo demás, version, description, author, homepage, repository, license, keywords, extensions, es opcional.

El problema que resuelve es aburrido y real. Cada cliente de agente hizo crecer su propio formato de plugin, así que la misma skill había que reorganizarla para cada cliente, y un paquete construido para uno necesitaba adaptarse antes de que otro pudiera cargarlo. Si alguna vez has mantenido el mismo SKILL.md en cuatro estructuras de repositorio distintas, ya conoces la forma de ese dolor. Es la misma fragmentación que hacía incómodo razonar sobre los plugins de ChatGPT y los GPTs y Actions hace un par de años, solo que ahora hay más clientes.

Qué entra en un plugin y qué no

La versión 1 define exactamente dos tipos de componentes. Skills y servidores MCP. Es un número deliberadamente pequeño, y es la decisión de diseño más interesante de todo el documento.

Ambos viven en ubicaciones fijas que el manifiesto no puede sobrescribir. Las skills van en skills/, un subdirectorio por cada una, que contiene un SKILL.md. La configuración de MCP va en mcp.json, en la raíz. La especificación es explícita: un cliente no debe recorrer más profundo buscando skills adicionales, ni debe aceptar configuración MCP declarada en línea dentro de plugin.json.

En cuanto al formato de SKILL.md en sí, la especificación delega por completo: las skills deben ajustarse a la especificación de Agent Skills, que sigue siendo la fuente de verdad para el frontmatter y la estructura de scripts/, references/ y assets/. Agent Plugins solo dice dónde encontrarlas.

Esto es lo que viaja y lo que no:

Cualquier cosa que un cliente quiera añadir por su cuenta va en un espacio de nombres de dominio inverso, ya sea como una clave bajo extensions en el manifiesto o como un directorio de nivel superior llamado com.example.client/. Los demás clientes están obligados a ignorar los espacios de nombres que no implementan, sin ni siquiera validar lo que contienen. Es una regla pequeña con una consecuencia grande: un plugin puede llevar extras específicos de cliente y seguir cargando limpiamente en todos los demás.

El lado de MCP tiene más contundencia de la que esperaba. Se reconocen tres transportes, stdio, streamable-http y el obsoleto sse, y un cliente conforme debe admitir al menos uno de los dos primeros. Los endpoints remotos deben usar HTTPS a menos que el host sea loopback. Cada subproceso stdio recibe las variables de entorno PLUGIN_ROOT y PLUGIN_DATA, y ${PLUGIN_ROOT} y ${PLUGIN_DATA} se expanden dentro de args, env y cwd, pero en ningún otro sitio. La contención de rutas se aplica en todo momento, así que un command como ../bin/server es inválido, no simplemente desaconsejado.

El aislamiento de fallos es la parte con la que realmente contaría en producción. Una entrada MCP rota desactiva ese servidor, no el plugin. Un SKILL.md mal formado omite esa skill, no la carpeta. Sin embargo, un plugin que falla en la validación del esquema del manifiesto es rechazado por completo y ninguno de sus componentes se ejecuta. Esos límites están detallados uno por uno, lo cual es una buena señal de que lo escribió gente que ya ha lanzado este tipo de cosas antes. Cualquiera que haya depurado una integración MCP a medio cargar apreciará esa precisión.

Qué partes de tu extensión realmente viajan

En lugar de describir otra vez la división, aquí tienes la misma información para que la explores tú mismo. Elige un componente y comprueba si sobrevive a un cambio entre clientes.

Quién está realmente detrás

Los estándares viven o mueren por su gobernanza, así que esta es la sección que leo primero.

El Technical Steering Committee son cinco personas, cada una identificada como individuo con una afiliación adjunta en lugar de como una empresa con un puesto:

El anuncio de Vercel reconoce a un grupo algo más amplio, citando a Amazon Web Services, Anysphere, GitHub, Microsoft, OpenAI y Vercel como responsables de haber desarrollado juntos el estándar.

El estatuto tiene tres cláusulas que merece la pena leer dos veces. Ningún proveedor puede controlar la mayoría de los puestos de Core Maintainer. Todos los roles de gobernanza los ocupan individuos, y no hay puestos reservados para empresas. Y el nombre, los logotipos, los dominios y las organizaciones de GitHub están en fideicomiso de una entidad neutral designada por el comité, sin que ningún proveedor pueda reclamar el control exclusivo de la identidad del proyecto.

El rastro documental respalda todo esto. El repositorio se incubó en vercel-labs/open-plugin-spec y ahora está bajo una organización separada, agentplugins, con el texto de la especificación bajo CC-BY-4.0 y el código bajo Apache 2.0. Si la afirmación de neutralidad alguna vez deja de cumplirse, el licenciamiento significa que el proyecto es bifurcable en lugar de capturable. Es más o menos el mismo manual que siguió la industria con el trabajo del agentic commerce protocol, y es una señal mejor que un comunicado de un consorcio sin repositorio detrás.

La ausencia con forma de Anthropic

Anthropic no aparece en la lista de mantenedores, y Claude Code no está entre los clientes de lanzamiento que nombra Vercel. Vale la pena detenerse en esto, porque Claude Code es donde ocurre actualmente una parte muy grande de la creación real de plugins, y porque Agent Skills empezó ahí.

Los formatos son parecidos pero no compatibles. La estructura de plugin documentada de Anthropic coloca el manifiesto en .claude-plugin/plugin.json y la configuración de MCP en .mcp.json, ambas rutas ocultas, mientras que Agent Plugins usa plugin.json y mcp.json visibles en la raíz. Claude Code también incluye tipos de componente que el estándar no cubre en absoluto, y la misma forma vuelve a aparecer en el formato del plugin de Cowork y en los plugins de IDE.

Son diferencias de ruta de archivo, que es el tipo de incompatibilidad más fácil de arreglar que existe. Un plugin podría llevar hoy mismo ambos manifiestos sin mucho drama. Pero hasta que alguien haga ese trabajo, un autor que apunte a ambos ecosistemas sigue manteniendo dos estructuras, que es precisamente el problema que el estándar se proponía eliminar. Yo no leería esta ausencia como un rechazo, y no hay declaración pública en ningún sentido. Yo lo leería como algo inacabado.

Vale la pena señalar que el mismo patrón se repite en otros sitios. Atlassian ofrece skills de agente de Rovo, ServiceNow ofrece sus propias skills de agente, y Freshworks ofrece una biblioteca de skills preconstruidas. Ninguna de ellas entra en el alcance de una especificación pensada para agentes de codificación, pero son la misma idea empaquetada de cinco formas distintas, lo cual dice mucho de lo temprano que está todo esto.

Lo que la versión 1.0.0 deja fuera deliberadamente

Esta es la sección que querría que leyera un revisor de seguridad antes de que nadie instale nada.

Los mantenedores son refrescantemente directos sobre las carencias. Un documento dedicado de future considerations enumera, como cosas que la v1.0.0 no define:

• Un modelo de confianza, sistema de permisos o sandboxing. Sin declaraciones de capacidades, sin flujos de consentimiento, sin niveles de confianza graduados.
• Verificación de procedencia. Sin comprobación de firmas, sin certificación que vincule un plugin publicado con su repositorio de origen.
• Gestión de secretos. La especificación prohíbe las credenciales en env y en las headers HTTP, y no ofrece ninguna alternativa portable.
• Controles empresariales. Sin listas de permitidos, sin listas de bloqueados, sin registros con alcance de organización, sin anulaciones centralizadas de políticas.
• Rastros de auditoría. Sin un esquema de eventos estándar para instalar, activar, actualizar o desinstalar.
• Resolución de dependencias. Los plugins no pueden declarar dependencias de otros plugins.

La especificación sí incorpora reglas de seguridad reales allí donde puede: las rutas deben permanecer dentro de la raíz del plugin, los endpoints MCP no loopback deben usar HTTPS, las cabeceras configuradas no deben reenviarse a través de una redirección a un origen distinto sin autorización explícita del usuario, y los clientes no deben obtener un esquema por red mientras cargan un plugin. Todo eso es sensato. Pero también trata en su totalidad sobre el paquete, no sobre lo que ese paquete puede luego hacer.

Así que la lectura honesta es esta. Agent Plugins resuelve la distribución. No resuelve la confianza. Un servidor MCP dentro de un plugin puede lanzar un proceso arbitrario con tu entorno, y el estándar no dice nada sobre si debería permitirse. Que eso esté bien o no depende por completo de en qué cliente lo instales y de los controles de permisos que ese cliente ofrezca. En el lado de Claude Code eso significa controles de administrador y settings.json; en cualquier otro sitio, significa lo que ese proveedor haya decidido.

Qué significa esto si compras agentes de IA en lugar de construirlos

La mayoría de quienes leen sobre una especificación de plugins son desarrolladores. Pero el efecto de segundo orden recae sobre cualquiera que esté evaluando agentes de IA para una función de negocio, y el soporte es el caso más claro.

El argumento de venta de un formato de plugin portable es que tu extensión no queda como rehén de un solo proveedor. Eso es real, y es una buena razón para preferir clientes que lo adopten. También es más limitado de lo que parece, porque la portabilidad del paquete no es portabilidad del resultado. Que tu SKILL.md se mueva sin problemas entre dos clientes no significa que el agente se comporte igual en ambos, que tenga los mismos permisos de herramientas, ni que resuelva la misma proporción de tickets. Ese último número es el que paga el proyecto, y es lo que realmente se juzga en un agente de IA para atención al cliente.

Veo el mismo razonamiento repetirse constantemente en conversaciones de construir versus comprar. Un responsable de ingeniería con el que trabajamos planteó el cálculo mejor de lo que yo podría:

"We could try to write our own LLM application but we didn't want to invest our time into that. We wanted something that we would not have to maintain."

Karel, GENERAL BYTES

Se trata de un responsable de ingeniería que gestiona una base de conocimiento de más de 300 artículos en Confluence y Telegram, y que eligió comprar en lugar de construir. Un estándar reduce el coste de ensamblar piezas. No hace nada respecto al coste continuo de ser propietario del resultado, y ahí es donde estos proyectos realmente se encarecen.

Las tres preguntas que le haría a cualquier proveedor, haya estándar o no:

1. ¿Puedo exportar lo que le he enseñado? Prompts, reglas, lógica de escalado. Si la respuesta es no, un formato de plugin portable no cambia nada respecto a tu lock-in.
2. ¿Quién decide qué puede tocar? Como la v1 no define ningún modelo de permisos, esta es una respuesta que depende de cada cliente, y deberías conseguirla por escrito antes de que nada llegue a una cola en producción. Para equipos regulados, esto se integra directamente en tu revisión de privacidad de datos.
3. ¿Puedo probarlo contra mi propio historial antes de que salga a producción? Simular contra escenarios que alguien ha escrito no es lo mismo que un ensayo real sobre tus propios tickets pasados.

Esa tercera pregunta es la que no negociaría. Hemos visto a un bot que suena seguro de sí mismo dar respuestas incorrectas en silencio, que es exactamente por lo que cada implantación en eesel se simula primero contra tickets históricos, en lugar de activarse y observarse sin más.

Prueba eesel para un soporte que se conecta a lo que ya usas

eesel toma la misma idea que persigue Agent Plugins, encontrarte donde ya trabajas, y la aplica al helpdesk. Se conecta con Zendesk, Freshdesk y Gorgias, además de Slack, Confluence y el resto de tu base de conocimiento interna, y luego redacta o resuelve a partir de lo que aprende ahí.

El diferenciador es la tercera pregunta de arriba. Antes de que eesel responda a un solo ticket en producción, lo ejecutas sobre tu propio historial de tickets y ves qué habría dicho, en qué tickets y con qué nivel de confianza. Después eliges qué tipos de ticket puede tocar. Es gratis probarlo, y la configuración se hace en minutos, no en un trimestre.

Hacia dónde va esto

Mi lectura tras un día con la especificación: el formato es lo bastante pequeño como para adoptarse rápido, la gobernanza es más sólida que la de la mayoría de estándares en su primera versión, y la historia de seguridad es un hueco deliberado con una hoja de ruta adjunta. Una especificación mínima que se lanza gana a una exhaustiva que se discute, y Agent Plugins es claramente la primera.

Las dos cosas que vigilaría. Si Anthropic converge, ya que la brecha es básicamente dos rutas de archivo y el equivalente a los tipos de componente extra de todo un ecosistema. Y si la v1.1 trae un modelo de permisos antes de que alguien lance un plugin que haga que todo el mundo desee que ya lo tuviera.

Si ahora mismo estás eligiendo herramientas de agente de IA, ya sea un agente de codificación como Cursor o una CLI agéntica, trata el soporte de Agent Plugins como una señal ligeramente positiva sobre la postura de un proveedor frente al lock-in. Y luego trata sus respuestas sobre permisos y pruebas como lo que realmente lo decide.