Les Kiro powers prennent désormais en charge Agent Plugins

Vous avez créé quelque chose de bien. Un Skill qui encode la façon dont votre équipe déploie réellement, ainsi qu'un serveur MCP qui communique avec votre service interne. Ça fonctionne. Alors vous l'empaquetez pour le client que votre équipe utilise, puis vous l'empaquetez encore pour le client que l'équipe voisine utilise, et encore une fois pour celui que vos contributeurs open source préfèrent. Même connaissance, mêmes outils, trois jeux de documentation, trois paquets à garder synchronisés.

Les auteurs d'extensions paient cette taxe depuis que les agents ont commencé à accepter des extensions. Les développeurs paient l'autre moitié : vous trouvez un plugin qui fait exactement ce dont vous avez besoin, et il ne se charge pas dans l'outil que vous utilisez.

Quand nous avons présenté les Kiro powers, l'idée était que les agents ne devraient pas avoir à tout savoir dès le départ. Regroupez un serveur MCP avec l'expertise nécessaire pour l'utiliser correctement, chargez-le seulement quand il est pertinent, et votre coût de contexte de base reste minimal.

Ce modèle fonctionne. La limite était l'offre, car un Power devait être créé pour Kiro afin de s'exécuter dans Kiro.

Aujourd'hui, Kiro powers déploie la prise en charge d'Agent Plugins 1.0.0, une spécification ouverte et neutre en matière de fournisseur pour l'empaquetage des extensions d'agent. AWS est un membre fondateur du comité de direction technique d'Agent Plugins, aux côtés de Cursor, Microsoft, OpenAI et Vercel. En pratique, cela signifie qu'un plugin publié selon la norme peut être installé dans Kiro en tant que Power.

Agent Plugins est une spécification ouverte et neutre en matière de fournisseur (v1.0) qui définit un seuil d'interopérabilité pour les composants réutilisables qui étendent les agents d'IA. Elle normalise la façon dont les Agent Skills et les serveurs MCP sont empaquetés afin que tout client compatible puisse les découvrir et les charger de façon cohérente.

Un Agent Plugin est essentiellement un répertoire avec un manifeste et des composants dans des emplacements fixes :

Nous avons observé ce schéma se répéter assez de fois pour le reconnaître. Avant package.json, installer une bibliothèque JavaScript signifiait télécharger des scripts à la main et gérer les dépendances par copier-coller. Une fois le format uniformisé, npm, yarn et pnpm ont tous pu installer le même paquet. Avant Open Container Initiative (OCI), une image de conteneur était un artefact Docker; après, la même build s'exécute sous containerd, Podman, ou tout autre outil conforme.

Les extensions d'agent sont à ce même point. Les composants sont bons, et c'est l'empaquetage qui prend du temps.

Agent Plugins y est arrivé comme le font les normes durables. Vercel a publié la première ébauche, puis a réuni un groupe de travail d'entreprises qui avaient chacune résolu le problème de leur côté. AWS, Cursor, Microsoft, OpenAI et Vercel ont raffiné la spécification ensemble et mis en place une gouvernance pour qu'aucune feuille de route d'une seule entreprise ne dirige le format. Le comité de direction technique regroupe des mainteneurs principaux des cinq entreprises, et le processus de contribution ainsi que les décisions techniques sont publics. Pour toute personne qui crée un Power, c'est la garantie pratique : à mesure que la spécification évolue, les Powers évoluent avec elle, et vous n'avez pas à attendre une migration propriétaire.

L'adoption de la norme élargit aussi ce qu'est un Power. Kiro prend en charge les Skills depuis un certain temps, mais il n'y avait pas de façon de les livrer à l'intérieur d'un Power. Jusqu'à maintenant, un Power était un fichier POWER.md, des fichiers de steering optionnels empaquetés pour un but précis, plus un mcp.json. Agent Plugins intègre les Agent Skills comme composant natif : un Power peut désormais contenir un ou plusieurs Skills structurés sous skills/, chacun avec son propre SKILL.md, ses scripts/ de soutien et ses references/.

Pour les développeurs, cela signifie :

• Une expertise qui s'exécute, pas seulement qui se lit. Un Skill peut regrouper des scripts exécutables et du matériel de référence en plus de ses instructions, et ceux-ci s'exécutent dans le cadre du Power.
• La composition plutôt qu'un long fichier unique. Plusieurs Skills peuvent coexister dans un même Power, chacun s'activant pour son propre flux de travail, plutôt que tout se disputer la place dans un seul fichier.
• Un emplacement défini pour chaque aspect. Les outils se trouvent dans mcp.json, les connaissances se trouvent dans skills/, le comportement spécifique au client se trouve sous un espace de noms. Créer, lire et étendre un Power deviennent tous plus faciles quand la structure est établie d'emblée.

Si vous installez des Powers, le catalogue n'est plus limité à ce qui a été créé pour Kiro :

• Une équipe publie un Agent Plugin pour son API interne. Les utilisateurs de cette équipe l'installent dans Kiro sans empaquetage spécifique à Kiro.
• Un fournisseur maintient déjà un plugin pour son service. Les utilisateurs de Kiro l'installent sans attendre un portage.
• Les plugins créés par la communauté, où qu'ils aient été publiés en premier, deviennent des candidats pour le panneau des Powers.

Si vous créez des Powers, vous écrivez selon un seul format documenté avec des schémas publics, et ce que vous livrez rejoint les développeurs sur tous les clients compatibles plutôt que sur un seul.

Rien de ce que vous avez installé ne cesse de fonctionner, et rien de ce que vous avez publié ne s'arrête. Les Powers créés selon l'ancienne méthode continuent de se charger comme toujours. Nous recommandons de migrer vers la disposition d'Agent Plugins plus tôt que tard, car c'est là que les nouvelles fonctionnalités arrivent d'abord, et parce que c'est ce qui rend votre travail portable.

Les Powers restent l'expérience Kiro autour des plugins, et c'est la partie sur laquelle nous continuons de bâtir : la curation, l'installation en un clic depuis l'IDE ou kiro.dev, les invites d'identifiants à la première utilisation, et l'activation basée sur des mots-clés afin que plusieurs Powers installés ne vous coûtent pratiquement rien en utilisation jusqu'à ce que certains d'entre eux ne soient activés que lorsque nécessaire pour une tâche particulière.

La thèse originale tient toujours. Les agents s'améliorent non pas en sachant tout dès le départ, mais en chargeant la bonne expertise exactement au moment où elle est nécessaire. Ce qui change aujourd'hui, c'est d'où peut provenir cette expertise. Les Skills et les serveurs que l'écosystème produit déjà sont maintenant des Powers que votre agent peut adopter, et la collection grandit aussi vite que la norme se répand.

Lisez la spécification sur agent-plugins.org, revisitez le lancement initial des powers, et ouvrez le panneau des Powers pour voir ce qui est déjà installable. Ensuite, empaquetez quelque chose de votre cru et dites-nous ce que vous avez créé.