OpenAI y grandes empresas tecnológicas unifican el formato de plugins de agentes de IA

El 6 de agosto de 2026, OpenAI, Microsoft, Amazon, Cursor y Vercel lanzaron conjuntamente Agent Plugins 1.0.0, intentando establecer un formato universal de empaquetado para Agentes de IA entre productos. Los desarrolladores pueden colocar en el mismo directorio las Agent Skills, compuestas por instrucciones de operación, scripts y referencias, junto con servidores MCP que se conectan a bases de datos, servicios en la nube y herramientas de desarrollo; teóricamente, tras un solo empaquetado, podrán utilizarse en clientes compatibles como ChatGPT, Codex, VS Code, Cursor, GitHub Copilot y Kiro. Lo que busca resolver no es la capacidad del modelo, sino la fragmentación de formatos que está surgiendo en el ecosistema de Agentes: actualmente, la misma funcionalidad suele requerir la creación separada de archivos de lista, modificaciones en la estructura de directorios y el mantenimiento de múltiples ramas. Sin embargo, la especificación 1.0.0 aún se etiqueta como "borrador de trabajo" y actualmente solo unifica el método de empaquetado, sin definir tiendas de plugins, protocolos de instalación, modelos de permisos, aislamiento en sandbox ni verificación de origen. Por lo tanto, se asemeja más a un "formato de paquete" para el ecosistema de Agentes que a una tienda de aplicaciones madura donde se pueda instalar con confianza cualquier plugin.

Autor del artículo y fuente: Jonathan Hefner, miembro del equipo técnico de Vercel

Durante el último año, el ecosistema de agentes de IA ha desarrollado dos capacidades de expansión importantes.

La primera categoría son las habilidades de Agent. Normalmente consisten en un archivoSKILL.md, scripts relacionados y referencias que indican al Agente cómo realizar cierto tipo de tarea. Por ejemplo, al implementar un sitio web, analizar documentos financieros o verificar la seguridad del código, las habilidades proporcionan pasos operativos, consideraciones importantes, reglas de validación y programas ejecutables directamente.

La segunda categoría son los servidores MCP. MCP se encarga de permitir que los Agentes se conecten a herramientas y datos externos, como leer bases de datos, operar en GitHub, consultar el estado de plataformas en la nube o invocar sistemas internos de la empresa. Las habilidades se centran en “enseñar al Agente cómo hacerlo”, mientras que MCP se enfoca en “proporcionar al Agente herramientas que pueda invocar realmente”.

El problema es que estos componentes anteriormente carecían de un método de empaquetado unificado. Incluso si una habilidad o el contenido central de un servidor MCP era completamente idéntico, los desarrolladores aún necesitaban modificar por separado los archivos de lista, la estructura de directorios y los campos de configuración al integrarlos en diferentes productos de Agent. Con el tiempo, la misma extensión generaba múltiples versiones específicas para clientes; cuando una versión corregía un error, otros branches no necesariamente se sincronizaban, lo que finalmente daba lugar a lo que Google denomina “fork y desviación”.

Lo que los Agent Plugins deben proporcionar es esta caja externa genérica. Su rol es más parecido al depackage.json en el ecosistema de JavaScript o al formato OCI en el ámbito de contenedores: no reemplaza el código ni los protocolos internos, sino que describe uniformemente cómo deben organizarse, descubrirse y cargarse这些东西.

According toversion 1.0.0 specification, an Agent Plugin is a directory with a fixed structure, and the root directory must containplugin.json. The minimal manifest only needs to declare the adopted specification version and the plugin name.

If the plugin includes skills, they are all placed in theskills/directory, with each skill having its ownSKILL.md, along with accompanying scripts, reference files, and other resources. If the plugin requires connection to external tools, placemcp.jsonin the root directory to declare one or more MCP servers.

MCP actualmente admite tres métodos de conexión: stdio con proceso iniciado localmente, Streamable HTTP (recomendado actualmente) y HTTP+SSE mantenido para compatibilidad con sistemas antiguos. Los clientes no necesitan admitir todos los métodos de transmisión, pero deben admitir al menos uno entre stdio o Streamable HTTP.

La ventaja directa de esta estructura fija es que el cliente no necesita adivinar dónde se encuentra el archivo, ni los autores de los plugins necesitan rediseñar el directorio para cada producto. Un cliente compatible, incluso si solo admite Skills y no MCP, puede seguir leyendo la sección de habilidades; cuando hay un error en la configuración de MCP, la especificación exige que el cliente omita tanto como sea posible los servidores con errores, en lugar de hacer que todo el plugin deje de funcionar por completo.

Los plugins de agente también permiten a los fabricantes conservar funciones exclusivas. Los clientes pueden establecer su propio espacio de nombres extendido utilizando dominios inversos, por ejemplocom.example.client. Otros clientes deben ignorar configuraciones exclusivas que no reconozcan, en lugar de rechazar el plugin completo. Esto permite que los estándares proporcionen una base común sin obligar a todos los productos a tener exactamente las mismas funciones.

La lista oficial de compatibilidad incluye actualmente VS Code, Cursor, GitHub Copilot, ChatGPT y Codex, así como Kiro de Amazon. Vercel inició la propuesta original del estándar, y posteriormente se estableció el comité técnico inicial por AWS, Anysphere (empresa matriz de Cursor), Microsoft, OpenAI y Vercel; GitHub también participó en la finalización del estándar.

Google anunció el día del lanzamiento que se uniría al mantenimiento principal y comenzaría a permitir que sus productos relevantes admitan este formato. Google planea adoptar Agent Plugins en Agents CLI y Data Agent Kit, permitiendo a los desarrolladores combinar capacidades de datos como BigQuery, Spanner y Cloud SQL en plugins portátiles.

Este grupo de participantes merece atención, ya que no pertenecen al mismo bando en términos de modelos y productos. Microsoft posee VS Code y GitHub Copilot y tiene una estrecha relación con OpenAI; Cursor es una herramienta de programación AI independiente; AWS posee Kiro y compite en el mercado en la nube con Microsoft y Google; Vercel busca convertirse en una plataforma de despliegue de aplicaciones AI. Su disposición para colaborar en la creación de estándares de empaquetado indica que la fragmentación de plugins ya está aumentando los costos de mantenimiento para todos los fabricantes.

La norma adopta una licencia abierta, y las discusiones técnicas y decisiones también se planean llevar a cabo en proyectos públicos. Al menos en el diseño institucional, intenta evitar que una sola empresa de modelo controle completamente el formato. Sin embargo, la efectividad final de la gobernanza abierta dependerá del proceso de toma de decisiones en versiones futuras y de si los diversos productos dependerán en gran medida de sus propias extensiones exclusivas.

La parte de los Agent Plugins que más fácilmente puede generar malentendidos es el término “plugins”, que puede hacer pensar en extensiones de navegador o tiendas de aplicaciones móviles. En realidad, la versión actual 1.0.0 solo unifica el formato de empaquetado, sin establecer un sistema completo de distribución y seguridad de plugins.

La interpretación oficial de Google especifica claramente que la primera versión no establece qué protocolo deben utilizar los plugins para instalarse, desde dónde buscar y descargar, ni tampoco requiere permisos unificados, confirmación del usuario, entorno de ejecución en sandbox, verificación de la identidad del publicador o validación del origen. Estas tareas siguen siendo responsabilidad de cada cliente de Agent.

La norma requiere que las rutas de archivo dentro del plugin no puedan escapar del directorio raíz del plugin mediante../o enlaces simbólicos, pero la oficialidad especifica claramente: esta restricción de ruta no equivale a una aislamiento en sandbox del proceso del plugin. Un servidor MCP iniciado a través de stdio aún puede ejecutar programas; qué archivos, variables de entorno, red y datos de usuario puede acceder depende del sistema de permisos del cliente.

Los puntos finales MCP remotos deben utilizar HTTPS en principio, y los plugins no deben escribir contraseñas u otros secretos directamente en encabezados de solicitud o configuraciones de entorno públicos. Sin embargo, la versión 1.0.0 no proporciona una configuración OAuth universal ni un mecanismo de referencia de credenciales portátiles; la descubrimiento de autenticación, el inicio de sesión del usuario y el almacenamiento de credenciales siguen siendo gestionados por el cliente.

Por lo tanto, el formato unificado también podría aumentar la eficiencia de la propagación de extensiones maliciosas. Los desarrolladores pueden “empaquetar una vez, ejecutar en cualquier lugar”, y los atacantes teóricamente también podrían hacerlo. Lo que realmente determinará si este estándar puede adoptarse a gran escala en el futuro no será la estructura de directorios, sino si los mecanismos de firma, advertencias de permisos, revisión de la cadena de suministro, actualizaciones automáticas y revocación pueden mantenerse al día.

Muchos productos de Agent también incluyen comandos, ganchos de eventos, plantillas de Agent secundarios, componentes de interfaz y flujos de trabajo personalizados. Los creadores no impusieron una unificación de estos elementos en la primera versión, sino que solo eligieron dos componentes que ya habían establecido una base transversal: Skills y MCP.

Esta es una opción conservadora pero realista. Si desde el principio se intenta definir todas las capacidades de los Agentes, es fácil que se vuelva demasiado amplia y fije el diseño actual de un producto como una regla a largo plazo para toda la industria. Los Agent Plugins primero abordan los problemas más claros: conectar el conocimiento operativo de los Agentes y las herramientas en un mismo paquete de software portátil.

Google también advierte específicamente que no cada habilidad independiente ni cada servidor MCP necesita ser empaquetado como un plugin. Los plugins son más adecuados para un conjunto de capacidades que requieren instalación conjunta, gestión de versiones conjunta y migración conjunta. Por ejemplo, un conjunto de plugins de desarrollo de base de datos puede incluir simultáneamente habilidades de consulta SQL, conexión MCP de base de datos, guías de solución de problemas y scripts de despliegue; si solo se trata de un archivo de instrucciones simple, puede ser más adecuado distribuirlo directamente como una habilidad.

Si el estándar recibe suficiente soporte de clientes, los desarrolladores no necesitan reconstruir completamente todas sus habilidades y conexiones de herramientas cuando cambian de equipo de Cursor a VS Code, o de Codex a otro agente. Las capacidades de agentes acumuladas a largo plazo por individuos o empresas pueden acompañar al usuario, lo que facilita la sustitución de los modelos subyacentes y los clientes.

Esto cambiará la forma en que compite la plataforma Agent. Los fabricantes no podrán retener a los usuarios solo con formatos de complementos cerrados, sino que deberán competir continuamente en calidad del modelo, confiabilidad de ejecución, control de permisos, experiencia de interfaz y capacidad de descubrimiento de complementos. Para los desarrolladores, los complementos portátiles también significan que una sola inversión puede alcanzar a más usuarios potenciales, sin necesidad de mantener repetidamente proyectos casi idénticos para cada mercado de Agent.

Pero la verdadera portabilidad aún tiene límites. Los clientes pueden implementar solo una parte de la especificación, y los mecanismos de autorización y los entornos de ejecución varían entre productos; aunque los complementos puedan ser reconocidos, no necesariamente exhiben comportamientos idénticos en cada cliente. Los complementos que utilizan ampliamente espacios de nombres exclusivos del fabricante pueden volver a crear bloqueo real bajo una apariencia de compatibilidad formal.

Además, MCP fue inicialmente impulsado por Anthropic, pero Anthropic actualmente no aparece en la lista de mantenedores principales iniciales ni en la lista de primeros clientes oficialmente compatibles publicados por Agent Plugins. Esto no significa que Claude no respalde este formato en el futuro, pero sí indica que el nuevo estándar de encapsulamiento aún no abarca a todos los principales grupos de Agentes.

El valor más grande de los Agent Plugins actualmente no es la complejidad técnica, sino que ha hecho que múltiples fabricantes competidores reconozcan el mismo problema: los modelos pueden invocar una creciente cantidad de herramientas, pero si cada plataforma tiene su propio método de empaquetado de plugins, el ecosistema de Agentes repetirá la historia fragmentada de las primeras aplicaciones móviles y las extensiones de navegador.

La primera versión del estándar es muy pequeña e incluso no aborda cómo los plugins deben encontrar, instalar y confiar. Pero esta contención también podría ser su ventaja: primero unifica la capa más básica y más fácil de consensuar, permitiendo que Skills y servidores MCP compartan un mismo medio de transporte, y deja los permisos, la distribución y otros componentes para versiones futuras.

Se debe tener en cuenta que,la página oficial de especificacionessi bien indica la versión 1.0.0, el estado sigue siendo “Working Draft” y es posible que se realicen ajustes a los detalles posteriores. Actualmente, el soporte proviene principalmente de fabricantes que participaron en la elaboración del estándar, y aún no se ha demostrado que el ecosistema de Agentes en general lo haya adoptado.