Agent Plugins 1.0.0 est un format d'empaquetage neutre pour les extensions d'agents, et Google a rejoint son comité technique comme mainteneur principal le 6 août, aux côtés d'Amazon, Cursor, Microsoft, OpenAI et Vercel. Le problème visé est terne et bien réel : un skill ou un serveur MCP écrit pour un client d'agent devait être réécrit pour être livré dans un autre. La spécification répond par un dossier, un manifeste à deux champs et des emplacements fixes pour les composants. Cinq clients le prenaient en charge au lancement. Ce que la spécification laisse volontairement de côté est aussi intéressant que ce qu'elle définit.
The short answer
Agent Plugins 1.0.0 définit un format de dossier partagé pour empaqueter les Agent Skills et les serveurs MCP, afin qu'un client compatible puisse les découvrir et les charger de la même façon. Un plugin est un répertoire contenant plugin.json, un dossier skills optionnel, un mcp.json optionnel déclarant les serveurs MCP en stdio, Streamable HTTP ou HTTP avec SSE hérité, et des dossiers en domaine inversé pour les données propres à un client. Google a rejoint le comité technique comme mainteneur principal le 6 août 2026, aux côtés d'Amazon, Cursor, Microsoft, OpenAI et Vercel. L'installation, la distribution, les permissions et le bac à sable restent hors périmètre de la version 1.0, ce qui laisse ces décisions à chaque client.
La plupart des annonces de standards se parcourent puis s'oublient. Celle-ci mérite un regard plus attentif pour une raison peu glorieuse : elle fait très peu de choses, volontairement, et ce peu est justement la partie sur laquelle six acteurs concurrents pouvaient s'entendre.
La duplication qu'elle supprime
Les Agent Skills et les serveurs MCP existaient déjà comme spécifications ouvertes avec une adoption réelle. Personne ne manquait de moyens de donner un outil ou une procédure à un agent. Ce qui manquait était une réponse partagée à une question plus petite : où ces choses vivent-elles sur le disque, et comment un client les trouve-t-il.
En pratique, une extension écrite pour un client devait être remodelée pour le suivant. Même texte de skill, même binaire de serveur, emballage différent, champs de manifeste différents, attentes différentes sur les noms de dossiers. Les équipes qui maintenaient quelque chose utilisé à plus d'un endroit finissaient par maintenir des variantes qui ne différaient que par l'empaquetage.
Agent Plugins 1.0.0 remplace cela par une disposition unique. Le client parcourt le dossier au lieu d'interroger un manifeste. S'il y a un dossier skills, les skills se chargent. S'il y a une configuration MCP, les serveurs se connectent. Le manifeste lui-même est presque vide par conception, avec une référence de schéma et un nom pour seules exigences.
À quoi ressemble un plugin
La forme est volontairement ennuyeuse. Une racine de plugin contient plugin.json. Les skills se rangent sous un dossier skills, chacun dans son répertoire avec l'arrangement familier d'un SKILL.md et des scripts ou fichiers de référence dont il a besoin. Les serveurs MCP sont déclarés dans mcp.json, avec le transport nommé explicitement : stdio, Streamable HTTP, ou l'ancienne approche HTTP avec SSE toujours présente sur le terrain.
La soupape de sécurité est l'espace de noms en domaine inversé. Un client qui doit stocker quelque chose qui lui appartient le fait dans un dossier portant son nom, ce qui garde les données propres à un client hors du contrat partagé sans les interdire. C'est le mécanisme qui permet aux clients de continuer à innover sans que chaque ajout devienne une négociation de norme.
Ce qu'elle ne fait pas
C'est la partie à lire attentivement avant de planifier quoi que ce soit autour. La spécification ne couvre pas l'installation. Elle ne couvre pas la distribution. Elle ne couvre ni les permissions, ni le bac à sable, ni la vérification de confiance. Ces absences sont annoncées, pas oubliées.
Ce périmètre est défendable. Faire s'accorder Amazon, Cursor, Microsoft, OpenAI, Vercel et maintenant Google sur une disposition de dossiers est un problème soluble. Faire s'accorder le même groupe sur un modèle de permissions l'est beaucoup moins, et une spécification qui aurait tenté les deux serait probablement encore à l'état de brouillon.
La conséquence pratique pour une équipe s'énonce simplement. Le format vous donne la portabilité de l'écriture : écrire le skill une fois, en garder une copie, le livrer partout où la spécification est implémentée. Il ne vous donne rien du tout sur l'origine des plugins ni sur ce qu'ils peuvent toucher une fois chargés. Ces réponses viennent toujours du client que vous exécutez, selon ses propres règles, et elles différeront d'un client à l'autre pour un moment.
Qui le livre
Cinq clients le prenaient en charge au lancement : ChatGPT et Codex, Cursor, GitHub Copilot, Kiro et VS Code.
C'est du côté des boîtes à outils que l'intention se voit. AWS publie l'AWS Agent Toolkit sous forme de plugins, présenté comme plus de trente skills sélectionnés répartis en plusieurs paquets pour ses services, Kiro consommant des paquets installables via son mécanisme Powers. Google, en rejoignant le comité comme mainteneur principal représenté par Kevin Hou de Google DeepMind, a publié une Agents CLI qui empaquete ses recommandations pour construire, évaluer, déployer et observer des agents, plus un Data Agent Kit qui se connecte à BigQuery, Spanner, Cloud SQL et d'autres services Google Data Cloud.
Google affirme que ces paquets fonctionnent avec n'importe quel agent de codage et pas seulement avec ses propres clients. C'est la bonne chose à dire, et c'est l'affirmation à vérifier sur les prochaines versions plutôt qu'à accepter le jour de l'annonce.
Faut-il bouger maintenant
Si vous maintenez des skills ou des serveurs MCP consommés par plus d'un client, la conversion consiste surtout à déplacer des fichiers et mérite d'être faite cette semaine. Le contenu du skill ne change pas, le serveur ne change pas, et vous gagnez une copie canonique unique.
Si tout ce que vous avez est consommé par exactement un client et que cela ne changera pas, il n'y a aucune urgence, et être en avance sur une 1.0 signifie surtout en découvrir les aspérités vous-même.
Le cas intermédiaire courant, ce sont deux ou trois outils internes, un client aujourd'hui, et un deuxième client plausible dans l'année. Empaqueter selon la spécification y coûte un après-midi et évite une migration, ce qui est à peu près aussi net qu'un arbitrage entre faire maintenant et attendre puisse l'être.
Sources et pour aller plus loin
- Spécification Agent Plugins, agent-plugins.org
- Agent Plugins Specification v1.0.0 sur GitHub
- Introducing Agent Plugins, Vercel, 6 août 2026
- AWS Supports Agent Plugins, AWS Open Source Blog, 6 août 2026
- Agent Plugins package your skills, tools, and more, Google Developers Blog, 6 août 2026
Questions fréquentes
Quel problème Agent Plugins résout-il vraiment ?
La duplication du travail d'empaquetage, pas la capacité. Les Agent Skills et les serveurs MCP avaient déjà des spécifications ouvertes et une adoption réelle avant cela, donc les composants eux-mêmes n'ont jamais été le point de blocage. Le blocage venait de ce que chaque client d'agent attendait ces composants disposés à sa façon, avec ses propres champs de manifeste et ses propres conventions de dossiers, si bien que livrer le même skill à deux clients revenait à maintenir deux paquets qui ne différaient que par leur emballage. Agent Plugins définit une disposition prévisible qu'un client compatible peut parcourir : s'il existe un dossier de skills, il les charge, s'il existe une configuration MCP, il connecte les serveurs. On écrit une fois, on livre partout où la spécification est implémentée. C'est le même mouvement que les formats de paquets et les images de conteneurs à leur époque, appliqué à un écosystème beaucoup plus jeune, et sa valeur vient presque entièrement du nombre de clients qui acceptent de le lire, pas d'une astuce technique du format.
Que contient concrètement un plugin ?
Un dossier. À sa racine se trouve plugin.json, et le contenu obligatoire de ce fichier est étonnamment réduit : une référence de schéma et un nom. Tout le reste s'exprime par la structure de fichiers plutôt que par une déclaration dans le manifeste. Un dossier skills contient les Agent Skills, chacun dans son propre répertoire avec la forme familière d'un fichier SKILL.md accompagné de scripts et de documents de référence optionnels. Un fichier mcp.json déclare les serveurs MCP, avec le transport indiqué explicitement, qui peut être stdio, Streamable HTTP, ou l'ancien dispositif HTTP avec SSE. À côté, un client peut ajouter son propre dossier nommé selon un espace de noms en domaine inversé, où vit sa configuration spécifique sans polluer le contrat partagé. Le choix de conception à noter est que la découverte est structurelle. Un client n'a pas besoin que le manifeste lui dise ce qui est présent, il regarde.
Que la spécification ne couvre-t-elle volontairement pas ?
L'installation, la distribution, les permissions, le bac à sable et la vérification de confiance sont tous hors périmètre en 1.0, et c'est annoncé plutôt qu'accidentel. Le résultat est un format qui dit à un client comment lire un plugin et ne dit rien sur la manière dont ce plugin est arrivé là ni sur ce qu'il a le droit de faire une fois chargé. C'est une décision de périmètre défendable, car se mettre d'accord sur une disposition de dossiers est atteignable entre six acteurs concurrents alors que se mettre d'accord sur un modèle de permissions ne l'est pas, et une spécification qui aurait tenté les deux n'aurait probablement livré ni l'une ni l'autre. Cela signifie que les questions intéressantes remontent d'un cran, vers chaque client. Si vous évaluez cela pour une équipe, le format vous achète la portabilité de l'écriture, et toutes les questions sur l'origine des plugins et sur ce qu'ils peuvent toucher restent tranchées par le client que vous exécutez, selon ses propres règles.
Quels clients et boîtes à outils le prennent en charge aujourd'hui ?
Cinq clients au lancement : ChatGPT et Codex, Cursor, GitHub Copilot, Kiro et VS Code. Côté boîtes à outils, AWS livre l'AWS Agent Toolkit sous forme de plugins, décrit comme plus de trente skills sélectionnés répartis en plusieurs paquets couvrant ses services, et Kiro consomme des paquets installables via son mécanisme Powers. Google, en rejoignant le comité comme mainteneur principal, en a publié deux : une Agents CLI qui empaquete ses recommandations pour construire, évaluer, déployer et observer des agents, et un Data Agent Kit qui se connecte à BigQuery, Spanner, Cloud SQL et d'autres services Google Data Cloud. La formulation de Google mérite d'être citée pour son intention, à savoir que ces paquets sont censés fonctionner avec n'importe quel agent de codage plutôt qu'avec les seuls clients Google. Reste à vérifier que cela tient en pratique sur les prochaines versions.
Faut-il réempaqueter dès maintenant ses skills et serveurs MCP existants ?
Si vous maintenez quelque chose utilisé par plus d'un client, oui, car la conversion consiste surtout à déplacer des fichiers. Le contenu de votre SKILL.md ne change pas, votre serveur MCP ne change pas, et ce que vous ajoutez est un manifeste à deux champs obligatoires et une disposition de dossiers. Si tout ce que vous avez est consommé par exactement un client et que rien ne va changer, la réponse honnête est qu'il n'y a aucune urgence, et adopter tôt une spécification en 1.0 vous achète surtout le droit d'en découvrir les aspérités sur votre temps. Le cas intermédiaire est le plus courant : deux ou trois outils internes, un client aujourd'hui, et une chance sérieuse d'un deuxième client dans l'année. Là, empaqueter selon la spécification maintenant est une assurance bon marché, qui coûte un après-midi plutôt qu'une migration.