AWS Builder Center

Kiro Powers ahora soporta Agent Plugins: El estándar abierto que une a AWS, Microsoft, OpenAI y Vercel

Kiro (el IDE agentico de AWS) anuncia soporte nativo para Agent Plugins 1.0.0, una especificación abierta y vendor-neutral que estandariza cómo se empaquetan Agent Skills y servidores MCP para que cualquier cliente compatible pueda descubrirlos y cargarlos consistentemente.

Kiro (el IDE agentico de AWS) anuncia soporte nativo para Agent Plugins 1.0.0, una especificación abierta y vendor-neutral que estandariza cómo se empaquetan Agent Skills y servidores MCP para que cualquier cliente compatible pueda descubrirlos y cargarlos consistentemente.
Lo que cambia hoy: Un plugin publicado bajo este estándar es instalable en Kiro como un Power — sin empaquetado específico de Kiro.
Los fundadores del estándar: AWS, Cursor, Microsoft, OpenAI y Vercel forman el Technical Steering Committee. No es un estándar de una sola empresa; es gobernanza compartida.
¿Qué es Agent Plugins?
Agent Plugins es una especificación v1.0 que define un piso de interoperabilidad para componentes reutilizables que extienden agentes de IA. Estandariza el empaquetado de:
ComponenteQué esEstándar relacionado
Agent SkillsConocimiento estructurado + scripts ejecutables + referenciasagentskills.io
MCP ServersServidores Model Context Protocol (stdio, HTTP, SSE)modelcontextprotocol.io
Un Agent Plugin es esencialmente un directorio con estructura fija:
mi-plugin/
├── plugin.json # Manifiesto: identifica el plugin + versión de Agent Plugins
├── skills/ # Agent Skills en formato estándar
│ └── resumir/
│ ├── SKILL.md # Instrucciones del skill
│ ├── scripts/ # Scripts ejecutables
│ └── references/ # Material de referencia
└── mcp.json # Servidores MCP (stdio, Streamable HTTP, o HTTP+SSE)
¿Por qué colaborar en un estándar?
“Hemos visto este patrón suficientes veces para reconocerlo.”
La analogía histórica:
Antes del estándarDespués del estándar
JavaScript: Descargar scripts a mano, copy-paste dependenciasnpm/yarn/pnpm instalan el mismo package.json
Contenedores: Imagen = artefacto DockerOCI: Mismo build corre en containerd, Podman, Kubernetes
Las extensiones de agentes están en ese mismo punto. Los componentes (skills, MCP) son buenos; el empaquetado es donde se va el tiempo.
¿Cómo llegó Agent Plugins ahí?
Vercel publicó el borrador inicial
Convocó un working group de empresas que resolvían el problema en privado
AWS, Cursor, Microsoft, OpenAI, Vercel refinaron la especificación juntos
Establecieron gobernanza compartida: el Technical Steering Committee tiene maintainers de las 5 empresas
Proceso de contribución y decisiones técnicas son públicos
Garantía práctica para autores: A medida que la especificación evoluciona, tus powers evolucionan con ella. No esperas migraciones propietarias.
Skills: Ahora ciudadanos de primera clase en Kiro Powers
Hasta ahora, un Power en Kiro era:
– Un archivo POWER.md (onboarding + propósito)
– Archivos de steering opcionales
– Un mcp.json para servidores MCP
Lo que cambia con Agent Plugins:
mi-power/
├── POWER.md # Identidad del power + onboarding
├── steering/ # Agent steering (formato estándar)
│ └── resumir.md
├── skills/ # ← NUEVO: Agent Skills nativos
│ ├── deploy-aws/
│ │ ├── SKILL.md
│ │ ├── scripts/
│ │ └── references/
│ └── test-unitarios/
│ ├── SKILL.md
│ ├── scripts/
│ └── references/
└── mcp.json # Servidores MCP
Para desarrolladores, esto significa:
BeneficioDescripción
Expertise que corre, no solo se leeUn skill puede empaquetar scripts ejecutables y referencias que corren como parte del power
Composición vs. un archivo giganteVarios skills viven en un power, cada uno activando su workflow, sin competir por espacio en un solo archivo
Hogar definido para cada concernHerramientas en mcp.json, conocimiento en skills/, comportamiento específico del cliente bajo namespace. Autoría, lectura y extensión se simplifican cuando la estructura es un dado
¿Qué cambia para ti HOY? (Enfoque LatAm)
Si instalas powers:
El catálogo ya no está limitado a lo construido para Kiro.
Un equipo publica un Agent Plugin para su API interna → sus usuarios lo instalan en Kiro sin empaquetado específico de Kiro
Un vendor ya mantiene un plugin para su servicio → usuarios de Kiro lo instalan sin esperar un port
Plugins creados por la comunidad, donde sea que se publicaron primero, se convierten en candidatos para el panel de powers
Si escribes powers:
Escribes contra un formato documentado con esquemas públicos, y lo que publicas llega a desarrolladores en cada cliente compatible, no solo uno.
Tus powers existentes siguen funcionando
Nada de lo que tienes instalado se rompe. Nada de lo que publicaste deja de funcionar.
Los powers construidos “a la antigua” continúan cargando como siempre. Recomendación: Migrar al layout de Agent Plugins cuanto antes, porque:
– Es donde aterriza nueva capacidad primero
– Es lo que hace tu trabajo portable
La visión permanece inalterada
“Los agentes mejoran no sabiéndolo todo de antemano, sino cargando la expertise exacta exactamente cuando se necesita.”
Lo que cambia hoy es de dónde puede venir esa expertise. Las skills y servidores que el ecosistema ya está produciendo ahora son powers que tu agente puede recoger, y la colección crece tan rápido como se extiende el estándar.
Recursos y Próximos Pasos
Acción
📖 Leer la especificación completa agent-plugins.org
🚀 Revisar el lanzamiento original de Powers/blog/introducing-powers/
🔧 Abrir el panel de powers en Kiro Ver qué ya es instalable
📦 Empaquetar algo tuyo y compartirloContribuir al ecosistema
💬 Contexto para equipos en Latam
¿Por qué importa en Latam?
AWS es fundador del estándar → Integración nativa con servicios AWS (Bedrock, Lambda, ECS, etc.) desde el día 1
Ecosistema multi-cloud real → Microsoft (GitHub Copilot, Azure), OpenAI, Vercel en la misma mesa. Tu plugin funciona donde corra tu stack
Costo cero de fragmentación → Equipos en Guadalajara, Bogotá, São Paulo, Buenos Aires comparten la misma librería de powers sin duplicar esfuerzo
Skills ejecutables = automatización real → No solo documentación; scripts que despliegan, testean, validan en tu pipeline
Governance abierta → No estás atado a roadmap de un solo vendor. La especificación evoluciona con input de la comunidad global
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article