Agent Plugins 1.0 es un estándar abierto y neutral respecto a proveedores que empaqueta las capacidades de un agente de IA (habilidades, servidores MCP, comandos y reglas) en un único plugin instalable, de modo que lo construyes una vez y lo ejecutas en distintas herramientas en lugar de reconstruirlo para cada una. En agosto de 2026, GitHub anunció soporte completo para el estándar en VS Code, Copilot CLI, la app de Copilot y su SDK, en todos los planes de Copilot. El significado directo para el dueño de un negocio: el tiempo y el dinero que inviertes en personalizar las herramientas de IA para tu equipo ya no quedan rehenes de una sola plataforma.

¿Qué problema resuelve realmente?

En los últimos dos años, las herramientas de IA pasaron de ser una caja de chat a ser agentes que leen tus archivos, llaman a tus sistemas y ejecutan pasos reales. Para personalizar esos agentes para tu empresa tienes que darles tres cosas: instrucciones escritas que expliquen cómo funciona tu negocio, una conexión con tus sistemas internos mediante servidores MCP y reglas que les impidan excederse en su autoridad.

El problema era que cada herramienta exigía todo esto en su propio formato. Tu equipo escribe personalizaciones para una herramienta; un año después la empresa decide pasarse a algo más rápido o más barato y descubre que todo ese trabajo no es portable y hay que reescribirlo. No es una simple molestia técnica: es un coste real que se repite con cada cambio de proveedor, y es la razón por la que muchas empresas aplazan una personalización seria por miedo a desperdiciar el esfuerzo.

¿Qué contiene un plugin en la práctica?

Un paquete según el estándar es de forma sencilla y está claramente definido. Se compone de:

  • Un manifiesto plugin.json con el nombre del plugin y su número de versión, que es lo que hace posible actualizarlo y hacerle seguimiento.
  • Una carpeta de habilidades con las instrucciones escritas que le dicen al agente cómo llevar a cabo una tarea recurrente de tu empresa tal como quieres que se haga.
  • Un archivo mcp.json que define los servidores MCP que conectan al agente con tus sistemas reales: inventario, base de datos de clientes, facturación.
  • Extensiones específicas de cada herramienta ubicadas en un espacio de nombres separado, para que las partes compartidas sigan siendo portables incluso cuando un proveedor añade una función propia.

Separar la parte compartida de la parte específica de cada proveedor es lo más inteligente del diseño: no impide que ningún proveedor se diferencie con sus propias funciones y no te obliga a perderlo todo si cambias de opinión más adelante.

¿Por qué debería importarle al dueño de un negocio, y no solo a un desarrollador?

La gobernanza es la verdadera diferencia. El estándar se desarrolla en público bajo una licencia abierta y lo supervisa un comité directivo técnico con representantes de Amazon, Microsoft, OpenAI, Cursor y Vercel. Cuando empresas competidoras se ponen de acuerdo en un formato, es una señal de que ese formato sobrevivirá a un solo ciclo de producto y de que no es el intento de una de las partes de atar a sus clientes.

Esto importa porque el mayor riesgo al adoptar IA hoy no es técnico sino contractual. El proveedor que eliges hoy puede subir precios, discontinuar un servicio del que dependes o cambiar de calidad. Un estándar abierto no elimina esos riesgos, pero reduce tu coste de salida, y un coste de salida bajo es la carta de negociación más fuerte que tienes.

¿Qué significa esto para las empresas en Arabia Saudí?

Con 2026 declarado Año de la Inteligencia Artificial en el Reino, muchas empresas han entrado en una fase de experimentación seria tras años de demostraciones. El patrón recurrente que vemos es una empresa que compra suscripciones para su equipo, luego no personaliza nada y termina con un asistente genérico que lo sabe todo sobre el mundo y nada sobre sus sistemas. El valor real viene de la personalización, no de la suscripción.

Con un estándar portable en marcha, la decisión de personalizar pasó a ser mucho menos arriesgada. Una empresa puede escribir un plugin interno que explique su ciclo de aprobaciones, conectar el agente a su sistema de facturación o de gestión de pedidos y distribuirlo a todo el equipo, con la confianza de que la inversión sigue siendo válida si se cambia a otra herramienta el año que viene.

Pero ten en cuenta un punto esencial: que un paquete sea portable no significa que el acceso a tus datos pase a estar permitido. Cualquier plugin que conecte un agente con tus sistemas internos sigue sujeto a la Ley de Protección de Datos Personales (PDPL), y debes definir con precisión lo que el agente puede y no puede leer, y documentarlo.

Pasos prácticos para empezar esta semana

  • Haz inventario de tus personalizaciones actuales. Anota lo que tu equipo ha construido realmente en instrucciones, conexiones y reglas, e identifica dónde vive hoy cada pieza.
  • Empieza con una tarea recurrente. No lo conviertas todo a la vez; elige un proceso diario que consuma tiempo de forma visible y empaquétalo como un solo plugin.
  • Define los permisos antes de distribuir. Los planes Business y Enterprise incluyen una configuración centralizada que controla qué plugins están permitidos y desde qué fuentes aprobadas. Configúralo antes de que el uso se extienda, no después.
  • Documenta qué es portable y qué no. Las partes compartidas se mueven entre herramientas; las extensiones específicas de cada herramienta puede que no. Conoce los límites de la portabilidad antes de construir una promesa sobre ella.

La conclusión es que la industria está pasando de un caos de formatos en competencia a uno compartido, y esta es la etapa en la que invertir en personalización de IA se convierte en una decisión calculada y no en una apuesta. En Origami construimos estos plugins y las conexiones con los sistemas reales de nuestros clientes, diseñando desde el principio para que la propiedad y la flexibilidad se queden en manos del cliente, no del proveedor.

Fuentes