AGNTCY : le standard ouvert qui va structurer l’Internet des agents

Dans mes deux précédents articles, j’ai décrit une économie des agents qui se met en place à grande vitesse : d’abord la tokénomics, cette nouvelle discipline née de l’explosion des coûts en tokens ; puis l’infrastructure de paiement - x402, AP2, ACP - qui permet à des agents autonomes de se régler des services entre eux. À chaque fois, une même conclusion revenait : la capacité technique précède toujours la capacité à la gouverner.

Mais un maillon manquait encore à ma démonstration. Avant de payer un agent tiers, encore faut-il pouvoir le découvrir, vérifier qui il est, lui parler de façon sécurisée, et observer ce qu’il fait. Ces quatre fonctions - découverte, identité, messagerie, observabilité - sont l’infrastructure invisible sans laquelle l’économie des agents reste un ensemble d’îlots incapables de collaborer. C’est exactement le problème qu’entend résoudre AGNTCY.

AGNTCY (prononcez « agency ») est un projet open source qui construit ce que ses promoteurs appellent l’« Internet des agents » : une couche de collaboration ouverte permettant à des agents de se trouver et de travailler ensemble, quels que soient le framework qui les a produits, l’éditeur qui les a conçus, ou l’endroit où ils tournent. Initié par Cisco et confié à la Linux Foundation en juillet 2025, le projet a l’ambition de devenir pour les agents ce que TCP/IP et HTTP ont été pour le web : non pas une application, mais le socle sur lequel tout le reste se construit.

Cet article s’adresse à celles et ceux qui devront concevoir, sécuriser et superviser ces systèmes. Nous allons décortiquer ce qu’est réellement AGNTCY : le problème de fragmentation qu’il attaque, son architecture composant par composant, la façon dont il s’articule avec les protocoles que j’ai déjà décrits, les raisons de penser qu’il peut s’imposer comme standard - et, tout aussi honnêtement, ce qui pourrait l’en empêcher.

Le problème : une prolifération d’agents qui ne se parlent pas

Chaque éditeur construit aujourd’hui ses agents dans son coin, avec son framework (LangGraph, LlamaIndex, CrewAI, l’Agent Development Kit de Google…), son format de description, ses conventions de sécurité. Le résultat est prévisible : des silos. Un agent conçu dans un écosystème ne sait ni découvrir, ni interroger, ni faire confiance à un agent conçu dans un autre. La multiplication des agents, loin de créer un réseau, produit une mosaïque d’îlots.

Le web a connu exactement ce moment. Avant que ne s’imposent une poignée de protocoles ouverts, les réseaux propriétaires - les AOL et Compuserve de l’époque - offraient chacun une expérience riche, mais close. La valeur n’a explosé qu’au moment où une couche commune, neutre et ouverte, a permis à n’importe quelle machine de parler à n’importe quelle autre. L’intuition derrière AGNTCY est que les agents en sont là : la vraie valeur ne naîtra pas d’un super-agent propriétaire, mais d’un tissu d’interopérabilité qui laisse mille agents collaborer.

Ce diagnostic n’est pas propre à AGNTCY. C’est la même logique qui a donné naissance au Model Context Protocol (MCP) d’Anthropic pour l’accès aux outils, et au protocole Agent2Agent (A2A) - lui aussi passé sous l’égide de la Linux Foundation - pour la communication entre agents. AGNTCY ne se pose pas en rival de ces standards. Il se pose en couche d’infrastructure qui les complète et les fait fonctionner à l’échelle.

Ce qu’est AGNTCY, et ce qu’il n’est pas

Commençons par dissiper une confusion fréquente. AGNTCY n’est pas un produit, ni une plateforme commerciale, ni un framework de plus pour écrire des agents. C’est un collectif open source et un ensemble de spécifications et de composants réutilisables, dont la finalité est l’interopérabilité.

La chronologie éclaire l’intention. Cisco, via son incubateur Outshift, ouvre le code d’AGNTCY en mars 2025, en collaboration avec LangChain et Galileo - deux acteurs qui comptent, l’un dans l’orchestration d’agents, l’autre dans leur évaluation. Quelques mois plus tard, le 29 juillet 2025, le projet est donné à la Linux Foundation. Ce geste est le plus important de tous : il place l’infrastructure sous gouvernance neutre, hors du contrôle d’un seul éditeur.

« Construire l’infrastructure fondatrice de l’Internet des agents exige une propriété communautaire, pas un contrôle par un fournisseur », résume Vijoy Pandey, directeur général et vice-président senior d’Outshift by Cisco. La formule dit tout du pari : une entreprise renonce délibérément à posséder la couche qu’elle a créée, pariant que la neutralité générera plus d’adoption - et donc plus de valeur pour tout l’écosystème - que la propriété exclusive.

Les signaux d’adhésion sont là. Aux côtés de Cisco, quatre poids lourds ont rejoint AGNTCY comme membres fondateurs sous la Linux Foundation - Dell Technologies, Google Cloud, Oracle et Red Hat - et le projet revendique aujourd’hui plus de 75 organisations contributrices, contre 65 au moment du passage sous Linux Foundation. Quand des concurrents directs comme Google Cloud, Oracle et Red Hat siègent à la même table pour bâtir une couche commune, on quitte le registre de l’expérimentation pour celui de l’infrastructure en train de se figer - le même mouvement que celui que je décrivais pour la x402 Foundation dans mon article précédent.

L’architecture : quatre fonctions, une pile ouverte

AGNTCY organise son infrastructure autour de quatre grandes fonctions, chacune adressée par un ou plusieurs composants open source. Pour un architecte, c’est la grille de lecture essentielle : découvrir, identifier, communiquer, observer.

Découvrir : OASF et l’Agent Directory

Avant de collaborer, il faut se trouver et se comprendre. AGNTCY répond par deux briques complémentaires.

L’Open Agentic Schema Framework (OASF) est un modèle de données extensible qui décrit un agent de façon lisible par une machine : ses compétences, ses interfaces, ses dépendances, ses contraintes. C’est l’équivalent d’une fiche d’identité fonctionnelle standardisée. Point important, l’OASF ne cherche pas à supplanter les formats existants : il est pensé pour décrire des agents à travers A2A, MCP et d’autres, en s’y intégrant plutôt qu’en les remplaçant.

Au-dessus, l’Agent Directory Service (ADS) joue le rôle d’annuaire. C’est un registre fédéré où publier, vérifier et découvrir des agents et des applications multi-agents. Sa conception est révélatrice de l’exigence de rigueur : l’annuaire s’appuie sur l’infrastructure de registres OCI (la même que celle des images de conteneurs), sur un adressage par contenu et sur la signature cryptographique des enregistrements. Autrement dit, on ne se contente pas de « lister » des agents : on garantit l’intégrité et la provenance de chaque fiche. Fait notable, l’annuaire d’AGNTCY a vocation à interopérer avec d’autres approches de nommage à l’échelle d’Internet, comme l’index NANDA développé au MIT Media Lab sous la direction du professeur Ramesh Raskar - signe qu’on raisonne ici en écosystème et non en silo.

Identifier : DID, Verifiable Credentials et « Agent Badges »

C’est la couche la plus stratégique, et celle qui prolonge le plus directement mes réflexions précédentes sur la confiance entre agents. Dans mon article sur l’économie des agents, je pointais la question laissée ouverte par les protocoles de paiement : sur quoi fonder la confiance entre agents anonymes qui se découvrent à la volée ? AGNTCY apporte une réponse structurée.

Le framework d’identité s’appuie sur des standards ouverts éprouvés : les identifiants décentralisés (DID) du W3C et les Verifiable Credentials (VC), ces objets cryptographiques infalsifiables que j’évoquais déjà à propos des mandats d’AP2. Chaque agent - mais aussi chaque serveur MCP, chaque système multi-agents - se voit attribuer une identité vérifiable et portable, indépendante de la plateforme qui l’héberge.

La notion la plus élégante est celle d’Agent Badge : une Verifiable Credential encapsulée, sous forme d’objet JSON-LD, qui atteste une définition précise d’un agent selon un schéma donné (une définition OASF, ou encore une AgentCard A2A). Un même agent peut porter plusieurs badges - un par version ou par correctif, par exemple - ce qui rend traçable, de façon inaltérable, non seulement « qui » est l’agent mais « quelle version exacte » on s’apprête à invoquer. Le projet a noué des collaborations avec des acteurs de la confiance numérique comme Cisco Duo, Skyfire et Permit.io pour l’onboarding, l’authentification et le contrôle d’accès.

Une nuance de prudence, cependant, que je formulais déjà à propos d’ERC-8004 : une identité vérifiable ne garantit pas un comportement honnête. Elle rend le comportement traçable et attribuable, ce qui est nécessaire mais pas suffisant. La signature prouve qui a agi, pas que l’action était légitime.

Communiquer : SLIM, le transport sécurisé

Une fois l’agent trouvé et identifié, il faut lui parler - de façon fiable, sécurisée et performante. C’est le rôle de SLIM (Secure Low-Latency Interactive Messaging), la couche de transport d’AGNTCY.

SLIM est conçu comme un substrat de messagerie de niveau réseau, sur lequel peuvent s’appuyer les protocoles applicatifs comme A2A, MCP ou l’ACP d’AGNTCY. Il prend en charge le routage sécurisé, la publication/abonnement (pub/sub), le streaming, la messagerie de groupe et le chiffrement de bout en bout via MLS (Messaging Layer Security). Deux caractéristiques méritent l’attention d’un architecte. D’abord, SLIM se veut quantum-safe, c’est-à-dire résistant aux futures capacités de calcul quantique - une anticipation rare et bienvenue pour une infrastructure qu’on espère durable. Ensuite, il intègre nativement le human-in-the-loop : la possibilité d’insérer une validation humaine dans une conversation entre agents, exactement le type de garde-fou que je recommandais face au risque d’agents qui dérapent.

L’intérêt de séparer le transport (SLIM) de la sémantique (A2A, MCP, ACP) est architectural : les protocoles applicatifs se concentrent sur ce que les agents se disent, pendant que SLIM garantit comment le message circule, de façon sûre et efficace.

Observer : télémétrie et évaluation de bout en bout

C’est le composant qui me tient le plus à cœur, et ce n’est pas un hasard s’il figure dans l’ADN du projet dès l’origine - Galileo, cofondateur d’AGNTCY, en a fait sa spécialité. La brique Observability and Evaluation fournit des collecteurs de télémétrie, des SDK et des services pour observer et évaluer des workflows multi-agents complexes, à travers les frameworks et les fournisseurs.

L’enjeu est double : observer (requêtes, latence, tokens consommés, coûts, erreurs) et évaluer (qualité des réponses, hallucinations, dérives). Comme le résume Yash Sheth, cofondateur de Galileo : « des agents fiables ne peuvent pas passer à l’échelle sans un monitoring conçu pour eux ». Cette conviction rejoint exactement le fil que je tire depuis le premier article : sans observabilité, l’IA agentique n’est pas seulement une dette technique, c’est une dette financière et sécuritaire.

À ces quatre fonctions s’ajoute l’Agent Connect Protocol (ACP), une API REST standardisée pour invoquer et interagir avec un agent, quelle que soit son implémentation. Et pour ceux qui veulent voir le tout à l’œuvre, AGNTCY publie CoffeeAGNTCY, une implémentation de référence qui montre comment assembler ces composants dans une application multi-agents réelle.

Comment AGNTCY s’articule avec MCP, A2A et x402

C’est ici que tout ce que j’ai décrit dans mes articles précédents prend sa cohérence. Beaucoup présentent ces standards comme concurrents ; c’est une erreur de lecture. Ils s’empilent.

Reprenons la pile de l’agentic web que je décrivais dans mon article sur l’économie des agents. Tout en bas, MCP régit la façon dont un agent utilise des outils et lit des données. Au-dessus, A2A définit comment deux agents se découvrent et se délèguent des tâches. Puis vient la couche paiement - x402, AP2, ACP au sens « commerce » - qui permet le règlement entre agents. Et tout en haut, une couche d’identité et de confiance.

AGNTCY ne s’insère pas à côté de cette pile : il en fournit le tissu conjonctif. L’OASF et l’Agent Directory rendent les agents A2A et les serveurs MCP découvrables. Le framework d’identité fournit la couche de confiance qui manquait. SLIM offre le transport sécurisé sur lequel A2A, MCP et ACP peuvent circuler. Et l’observabilité couvre l’ensemble. Le projet est d’ailleurs explicitement interopérable avec A2A et MCP : il rend les agents A2A et les serveurs MCP visibles dans ses annuaires, les instrumente via ses SDK, et transporte leurs messages via SLIM.

Quant au paiement, la jonction est naturelle. J’ai décrit comment l’extension A2A x402 relie la communication entre agents au règlement en stablecoin. AGNTCY fournit précisément les couches en amont - trouver l’agent à payer, prouver son identité, sécuriser l’échange, tout observer - sans lesquelles un paiement autonome serait aveugle. Payer un agent qu’on ne sait ni découvrir, ni identifier, ni superviser : voilà exactement le risque que ces standards, ensemble, permettent d’écarter.

Pourquoi AGNTCY peut devenir le standard - et ce qui pourrait l’en empêcher

Trois raisons de fond plaident pour qu’AGNTCY s’impose comme couche de référence.

La première est la gouvernance neutre. L’histoire de l’open source enseigne que les standards durables sont ceux qu’aucun acteur ne possède. En donnant AGNTCY à la Linux Foundation - la maison de Linux, Kubernetes ou PyTorch - Cisco a fait le choix qui maximise l’adoption. Le fait qu’A2A ait suivi le même chemin, sous la même égide, crée un centre de gravité difficile à ignorer.

La deuxième est la coalition. Un standard n’existe que par ceux qui l’implémentent. Réunir dès le départ des fournisseurs d’infrastructure (Dell, Oracle, Red Hat), un hyperscaler (Google Cloud), des spécialistes de l’orchestration et de l’évaluation (LangChain, Galileo) et 75 organisations autour de la table, c’est réunir les conditions d’un effet de réseau.

La troisième est la complémentarité assumée. En refusant la guerre de protocoles et en se rendant interopérable avec MCP et A2A, AGNTCY se donne le rôle le plus défendable : non pas le protocole qui gagne, mais l’infrastructure qui fait gagner les autres. C’est une position moins spectaculaire, mais historiquement plus solide.

Il faut cependant se garder de tout triomphalisme, et je serais malhonnête de ne pas poser les réserves. La standardisation est un champ de bataille encombré : NANDA côté MIT, les initiatives propres aux grands modèles, les approches purement crypto/on-chain… la convergence n’est pas acquise, et plusieurs couches concurrentes peuvent coexister durablement. La maturité reste jeune : annuaires signés, réputation portable et identité décentralisée sont des chantiers actifs, pas des acquis en production à grande échelle. L’adoption par les développeurs - le vrai juge de paix - se mesurera en implémentations réelles, pas en communiqués. Et surtout, un standard ouvert résout l’interopérabilité, pas la maîtrise : savoir qu’un agent peut en découvrir un autre ne dit rien de ce qu’il fait une fois lâché dans la nature.

Le vrai différenciateur reste la gouvernance opérationnelle

C’est le point sur lequel je veux insister, parce qu’il boucle les trois articles. Un standard d’interopérabilité est une condition nécessaire de l’économie des agents ; il n’en est pas la condition suffisante. Le jour où vos agents pourront se découvrir, s’identifier, se parler et se payer à l’échelle d’Internet, la question ne sera plus « peuvent-ils collaborer ? » mais « sais-je, à tout instant, ce que fait chacun d’eux, à qui il parle, ce qu’il dépense, et pour quelle valeur ? ».

C’est précisément l’axe de Splunk. L’observabilité des agents fait partie de l’ADN d’AGNTCY, et ce n’est pas un hasard : Splunk Agent Observability, issu de l’acquisition de Galileo - cofondateur du projet - offre déjà une vue centralisée des agents (requêtes, latence, tokens en entrée et en sortie, coûts) corrélée à la qualité des réponses. Un standard ouvert comme AGNTCY et une plateforme d’observabilité ne s’opposent pas : ils se complètent. Le standard garantit que la télémétrie est produite de façon interopérable, quel que soit le framework de l’agent ; la plateforme la transforme en un plan de contrôle unique - budgets, disjoncteurs, détection d’anomalies, corrélation coût/valeur. C’est aussi tout l’esprit d’Argos AI, l’application Splunk dédiée à l’agentique que je développe : rendre l’action des agents lisible, budgétée et auditable.

Autrement dit, AGNTCY résout le « comment les agents collaborent » ; il revient aux organisations - et à leurs partenaires d’observabilité - de résoudre le « comment je garde la main ». L’un ne va pas sans l’autre.

En pratique : ce qu’un décideur technique devrait faire dès maintenant

Pour qui conçoit des systèmes multi-agents aujourd’hui, quelques principes se dégagent. Raisonner en couches ouvertes : traiter découverte, identité, transport et observabilité comme des couches distinctes et standardisées, plutôt que comme des fonctions enfouies dans chaque agent. Miser sur l’interopérabilité, pas sur un fournisseur : s’appuyer sur les standards qui convergent sous gouvernance neutre (AGNTCY, A2A, MCP) plutôt que sur des formats propriétaires qu’il faudra reconstruire. Instrumenter dès le premier agent : l’observabilité n’est pas une couche qu’on ajoute après coup, c’est une exigence de conception - d’où l’intérêt d’un standard qui la porte nativement. Anticiper l’identité et la confiance : adopter tôt des identités vérifiables et portables (DID, Verifiable Credentials) pour ne pas se retrouver démuni quand les agents franchiront les frontières organisationnelles. Et poser des limites dures : budgets, plafonds, disjoncteurs et validation humaine restent indispensables, standard ou pas.

Conclusion

Le web est né de protocoles ouverts que personne ne possédait : HTTP pour transporter, HTTPS pour sécuriser, DNS pour nommer. L’Internet des agents rejoue ce moment fondateur, et AGNTCY se propose d’en être la couche d’infrastructure - celle qui permet aux agents de se découvrir, de se faire confiance, de se parler et de se laisser observer, indépendamment de qui les a construits. Le geste de le confier à la Linux Foundation, la coalition qui s’y agrège et la logique de complémentarité avec MCP et A2A en font l’un des candidats les plus crédibles au statut de standard.

Mais mes trois articles convergent vers la même leçon. La tokénomics nous a appris que la capacité à consommer précède la capacité à en maîtriser le coût. L’économie des agents nous a appris que la capacité à payer précède la capacité à en gouverner les décisions. L’Internet des agents ajoute un troisième étage à cette leçon : la capacité à interopérer précède la capacité à superviser. AGNTCY est peut-être le standard qui fera tenir cet édifice. Il ne dispensera personne de la seule question qui vaille pour un décideur : « est-ce que je sais, à tout instant, ce que font mes agents, et pour quelle valeur ? ». Les organisations qui gagneront l’ère des agents ne seront pas celles qui adopteront le plus de standards, mais celles qui sauront transformer l’interopérabilité en maîtrise.

Pour aller plus loin : le site du projet AGNTCY et sa documentation technique, l’annonce du passage à la Linux Foundation, le code sur GitHub, l’index NANDA du MIT Media Lab et Splunk Agent Observability. À lire aussi, mes deux articles précédents sur la tokénomics et sur l’économie des agents.