A2A : comment des agents de fournisseurs différents se découvrent et se parlent

Votre agent fonctionne sur votre plateforme. Le problème commence quand il doit parler à un agent qui vit dans le système d'un autre fournisseur : il n'y a pas de forme standard pour qu'ils se découvrent, se saluent ou se transmettent une tâche. Le protocole Agent-to-Agent (A2A) existe pour ça. Il standardise comment des agents de fournisseurs différents se découvrent, communiquent et exécutent des tâches entre eux. Le module Microsoft Learn « Discover Azure AI agents with A2A » le parcourt de bout en bout. Ce post fait pareil : ce que résout le protocole, ce qu'un agent déclare avant de participer, de quoi se compose son serveur et comment l'appelle un client.

Ce que A2A résout

La limite est concrète : des agents qui vivent dans des systèmes distincts n'ont aucun moyen uniforme de se coordonner. La question à résoudre est simple : comment un agent sait-il qui est disponible dans son système, ce qu'il peut faire et comment l'appeler ? A2A répond avec un cadre standardisé pour la découverte, la communication et l'exécution coordonnée de tâches, même entre agents de fournisseurs différents. C'est le cas de toute équipe qui résout ça à la main aujourd'hui : intégration par intégration, accord par accord, entre l'agent de tickets et l'agent de documentation qui vit dans un autre cloud.

Et il ne s'arrête pas à la collaboration. Il apporte une sélection de modèle flexible par agent, chacun choisissant le modèle qui lui convient, et une authentification intégrée dans le protocole lui-même, au lieu d'un mécanisme à part par intégration. C'est ce qui fait d'A2A un protocole et non un accord bilatéral : une seule façon de faire, valable pour n'importe quelle paire de fournisseurs. Le résultat est d'orchestrer sans migrer : votre agent reste où il est et parle à qui que ce soit de l'autre côté. Et il ferme le chemin des agents sur Azure : si vous suivez les précédents, ce protocole est la dernière pièce du puzzle.

Avant de participer : les compétences

Avant d'entrer, l'exigence : un agent ne se présente pas en disant « je suis un agent ». Il déclare ce qu'il peut faire. Chaque compétence décrit une fonctionnalité concrète, avec id, nom, description, étiquettes, exemples et modes d'entrée et de sortie. Ce sont six champs, et les six définissent le contrat : avec cela, un autre agent peut l'invoquer en sachant ce qu'il reçoit, ce qu'il renvoie et à quoi ça sert. Une compétence bien écrite se teste comme se teste une API : avec un exemple d'entrée et un exemple de sortie. L'information de la compétence est ce qui permet au routage de bien la choisir ; une compétence mal décrite est une porte sans enseigne.

La carte d'agent

La carte d'agent est la fiche structurée qui rassemble ces compétences avec trois choses de plus : l'identité, l'URL du point de terminaison (l'adresse où l'agent écoute les demandes) et les fonctionnalités A2A prises en charge (streaming, notifications push). Elle porte aussi les modes de médias et indique si l'authentification est requise. Elle est publiée pour que les clients et les agents de routage détectent l'agent automatiquement et routent chaque demande vers la compétence adéquate.

Un détail à expliciter : la carte donne des métadonnées et des fonctionnalités ; elle ne stocke pas de clés d'API. Ce qui ne va pas dans la carte compte aussi : identifiants ni clés d'aucune espèce. C'est de l'information publique par conception, publiée sur un point de terminaison que n'importe qui peut demander. C'est une lettre de présentation, pas un coffre-fort. C'est la même chose que publierait n'importe quel service voulu être consommé : identité, adresse et menu. En clair : c'est le profil public de l'agent ; on le publie une fois et quiconque sait lire A2A le trouve et le comprend. Et l'ordre compte : quand un client veut utiliser un agent distant, sa première requête n'est pas une tâche. C'est la carte.

Le serveur : trois composants

Héberger un agent A2A demande trois pièces :

La carte publiée sur un point de terminaison standard, normalement /.well-known/agent-card.json.
Un contrôleur de demandes qui route vers l'exécutant et administre le cycle de vie des tâches avec un magasin de tâches.
L'application de serveur, construite sur un framework web (Starlette en Python) avec un serveur ASGI comme Uvicorn (la paire standard pour faire tourner des applications Python sur le réseau). Cette application écoute sur le réseau et expose les points de terminaison.

Le rôle du serveur mérite une définition parce qu'il se confond : il fait le pont. Il reçoit les demandes A2A, les route via le contrôleur vers l'exécutant de l'agent et administre le cycle de vie des tâches. Si vous avez déjà monté un serveur web, le schéma vous parlera : l'application écoute, le contrôleur répartit et l'exécutant travaille. La logique métier, c'est l'agent qui l'exécute à travers l'exécutant, et le serveur ne stocke pas de réponses statiques. Et le magasin de tâches n'est pas un luxe des agents complexes : même un agent simple a un cycle de vie à administrer, car sa demande a aussi un état. Le magasin est ce qui donne de la mémoire au serveur entre les demandes ; sans lui, chaque requête serait un monde.

L'exécutant

L'exécutant est le pont entre le protocole et la logique métier. L'interface AgentExecutor reçoit les demandes entrantes avec un RequestContext, les traite selon les fonctionnalités de l'agent et renvoie les résultats par une file d'événements (eventQueue : la rangée où le serveur dépose les morceaux de la réponse). Il a deux opérations : Execute fait le travail ; Cancel permet d'aborter une tâche en vol quand l'agent l'admet. Un agent simple peut indiquer qu'il n'admet pas la cancellation. C'est la pièce qui connecte le protocole à votre logique réelle : ce que l'exécutant répond est ce que voit le client distant, avec tous les états intermédiaires au milieu. Ce que l'exécutant ne fait pas : gérer le réseau ni offrir d'interface graphique.

Le client

Du côté client, le flux a trois moments, et le client n'a besoin de rien savoir de plus de l'agent distant : la carte suffit. D'abord il découvre : il la récupère, et de là sort l'URL du point de terminaison de l'agent. Ensuite il initialise la connexion. Et alors il envoie des demandes de deux types :

Sans streaming, quand une réponse complète suffit.
Avec streaming, pour les tâches longues qu'il vaut garder visibles en temps réel. Les réponses arrivent incrémentales, au lieu d'attendre le bloc final. Avec streaming l'utilisateur voit le travail avancer ; sans streaming il voit une réponse unique. Le choix dépend de la tâche, pas du goût.

sequenceDiagram
    participant C as Votre client
    participant S as Le serveur A2A de l'agent distant
    participant K as Le contrôleur de demandes
    participant E as L'exécutant de l'agent
    C->>S: Découvre : demande la carte sur /.well-known/agent-card.json
    S-->>C: Renvoie identité, compétences et point de terminaison
    C->>K: Envoie la tâche
    K->>E: La route vers l'exécutant avec son RequestContext
    E-->>C: Réponses ou événements par la file, avec ou sans streaming

Le client frappe d'abord à la porte (la carte), apprend ce que sait faire l'agent, et seulement ensuite lui envoie du travail. Le serveur ne réfléchit pas : il route ; l'exécutant est celui qui travaille. Et la découverte par carte est ce qui élimine l'accord bilatéral : personne ne s'inscrit à la main sur la plateforme de l'autre.

Les réponses peuvent être des messages directs ou des objets de tâche. La différence est de fond : le message est la réponse en soi ; la tâche est un travail qui reste vivant du côté du serveur. Cette tâche a un état à consulter et, si l'agent l'admet, une cancellation possible. Le suivi est la différence entre un chat et un travail : la tâche reste vivante sur le serveur jusqu'à ce que vous la consultiez ou l'annuliez. C'est pourquoi les tâches exigent des requêtes de suivi.

L'exemple du rédacteur technique

Un cas propre illustre le chaînage. Un agent déclare une compétence de titres ; un autre, une compétence de schémas. L'agent de routage récupère la carte de chacun, envoie la demande de l'utilisateur à l'agent de titres, passe le titre généré à l'agent de schémas et renvoie le schéma final. Tout automatique, sans que l'utilisateur sache que trois agents ont participé. Trois agents, deux chaînages et aucune configuration spéciale : le routeur a seulement lu des cartes. Sans accords bilatéraux au milieu ; seulement des compétences décrites et des cartes lues. Le motif est le même que celui que vous verrez dans tout flux A2A : découvrir par carte, invoquer, chaîner.

Le hello world hébergé

Le démarrage le plus simple possible : un agent qui renvoie « hello world », hébergé et visible à son point de terminaison, prêt à être trouvé par n'importe quel client. Les étapes :

Définir les compétences et la carte. C'est le contrat de découverte : sans ça, personne ne trouve l'agent.
Créer l'exécutant : Execute renvoie une chaîne comme événement dans la file ; Cancel peut indiquer que ce n'est pas supporté.
Initialiser le contrôleur de demandes avec le magasin de tâches. C'est là qu'il commence à suivre le cycle de vie de ce qu'on lui demande.
Démarrer l'application avec Uvicorn : l'app reste à l'écoute et l'agent visible à son URL pour tout client qui demande la carte.

C'est le même schéma que vous utiliseriez pour n'importe quel agent A2A : seules changent les compétences et la logique à l'intérieur de l'exécutant. C'est le point de départ naturel de tout serveur A2A.

Votre serveur dans la rue

Ce qui n'a pas été exécuté est l'exercice « Connect to remote Azure AI agents with the A2A protocol » : il exige d'héberger le serveur de l'agent en local et de lancer le client contre lui. Le post a couvert le protocole, la carte, le serveur et le client. C'est l'étape qui met tout ce qui précède à l'épreuve : quand vous le lancerez, le premier résultat que vous vouliez voir est que le client trouve la carte et lui passe une tâche.

Quand vous l'appliquerez à votre projet, l'ordre du hello world est le chemin : compétences et carte d'abord (sans ça, personne ne vous trouve), ensuite l'exécutant, ensuite le contrôleur avec son magasin de tâches, et seulement ensuite le serveur à l'écoute sur le réseau. Et la première chose à tester avec un vrai client est la découverte par carte : si ça échoue, rien d'autre n'a d'importance.

Mon avis

La pièce dont tout dépend, c'est la carte. C'est ce qui transforme n'importe quel service en agent que d'autres peuvent découvrir, et sa qualité décide si le routage fonctionne : des compétences mal décrite signifient des demandes au mauvais agent. Le reste du schéma (carte, contrôleur, exécutant, client) implémente ce contrat, pièce par pièce. Si vous allez en publier un, écrivez la carte comme ce qu'elle est : la documentation publique de votre agent, pour les machines.

---

*Source : le module « Discover Azure AI agents with A2A » de Microsoft Learn.*