Agentgateway pour les LLM, MCP et A2A : Lorsque un plan de données IA unifié est utile
En quoi Agentgateway diffère des proxies basés uniquement sur des LLM : découverte MCP, suivi A2A, routage, sécurité, OpenTelemetry et gouvernance des coûts – ainsi que les moments où il convient de l’adopter ou de l’éviter.
Les équipes travaillant sur des plateformes qui dépassent le cadre d’un seul point de terminaison de modèle se retrouvent souvent confrontées à une multitude d’éléments : des fournisseurs de modèles LLM, des serveurs d’outils et des agents autonomes, chacun ayant son propre schéma d’accès. Les proxies spécifiques aux modèles LLM tels que Bifrost ou LiteLLM aident à compléter les conversations, mais ils laissent le trafic entre agents ainsi que les interfaces des outils MCP en tant que problèmes distincts.
Agentgateway vise à combler cette lacune : un gateway haute performance pour le trafic propre aux systèmes d’intelligence artificielle, et pas seulement un proxy HTTP classique pour les modèles LLM. Les sections suivantes résument ce qui le rend différent, l’expérience de démarrage rapide, les paramètres de gouvernance importants, ainsi que les cas où il convient de l’adopter et ceux où il est préférable de s’en abstenir.
Ce qui rend Agentgateway différent : au-delà du proxy LLM
Le principal avantage réside dans la connaissance native des protocoles orientés agents, en plus des routes HTTP classiques des LLM. Il peut toujours faire face aux points de terminaison compatibles avec OpenAI, mais il traite également les serveurs d’outils MCP comme des microservices – avec un mécanisme de découverte permettant aux agents de trouver les outils – et il peut gérer l’identité et le suivi au cours des échanges A2A, afin que les appels entre frameworks d’agents restent observables.
Dans un système agentiel complexe, les agents effectuent des appels à des outils qui peuvent aboutir sur un serveur MCP. En l’absence d’un plan de données partagé, chaque équipe invente des mécanismes d’authentification, de limitation des débits et de télémétrie adaptés à ces appels. Agentgateway centralise ces aspects, tout comme un API gateway le fait pour les microservices REST, en tenant compte des particularités du routage des LLM telles que le choix basé sur la latence, les coûts et le modèle utilisé.
Pour le trafic A2A, l’identité à chaque saut et le suivi sont essentiels : les opérateurs de plateforme doivent savoir quel agent a appelé quel pair, avec quelles identifiants et quel budget de latence. En traitant cela comme une tâche prioritaire pour les passerelles, on réduit la tentation d’ajouter des composants temporaires à côté de chaque processus d’agent.
Se mettre au travail : une expérience de démarrage rapide
Une évaluation typique commence localement. L’installation ressemble à celle d’autres outils de passerelle orientés CLI :
# This is a conceptual installation command, similar to what you might find for many CLI tools
curl -sL <some_install_script_url> | bash
Après l’installation, mettre en place un proxy LLM de base ne prend que quelques minutes : il suffit de configurer une route vers un backend compatible OpenAI et d’envoyer une demande de complétion de test. Un manifeste de route simplifié pourrait ressembler à ceci :
# llm-route.yaml
apiVersion: gateway.agentgateway.io/v1alpha1
kind: LLMGateway
metadata:
name: my-llm-proxy
spec:
listener:
port: 8080
routes:
- match:
prefix: /v1/chat/completions
destinations:
- ref:
name: openai-backend
namespace: default
backends:
- name: openai-backend
llm:
provider: openai
credentials:
secretRef:
name: openai-api-key
namespace: default
Cet extrait montre un écouteur, une route entrante et un fournisseur de backend. L’avantage réside dans le faible nombre de modifications personnalisées nécessaires pour faire fonctionner une première route avant d’ajouter des politiques.
Le pouvoir de la gouvernance : routage, sécurité, observation, gestion, coûts
Au-delà du routage, c’est l’interface de contrôle qui fait la valeur du produit pour les entreprises.
Routage. Pas seulement HTTP/gRPC : les routes LLM peuvent privilégier des modèles moins chers ou plus rapides, basculer en cas de panne vers d’autres fournisseurs, et maintenir le trafic des agents au même niveau que les appels API ordinaires.
Sécurité et politiques. Au-delà des vérifications JWT et OIDC, les opérateurs peuvent appliquer des limites de fréquence et des politiques plus complexes aux routes LLM. Exemple :
# Example: Applying a rate limit policy to an LLM route
apiVersion: gateway.agentgateway.io/v1alpha1
kind: RateLimitPolicy
metadata:
name: llm-rate-limit
spec:
targetRef:
group: gateway.agentgateway.io
kind: LLMGateway
name: my-llm-proxy
rateLimits:
- local:
requestsPerUnit: 100
unit: MINUTE
key:
header: "x-api-key" # Rate limit per API key
Observabilité. Les hooks OpenTelemetry sont utiles par défaut pour les équipes qui standardisent déjà les traces et les métriques. Les spans du gateway incluant l’identité du modèle, de la route et de l’agent réduisent les points aveugles lors du débogage des appels lents ou coûteux.
Gouvernance et coûts. Les politiques d’accès aux outils pour les cibles MCP, les quotas ainsi que le routage tenant compte des coûts permettent à l’équipe de plateforme de définir les budgets une seule fois, plutôt que de négocier des limites dans chaque répertoire d’agent. Cette séparation des rôles — les équipes d’applications développent les agents, tandis que les équipes de plateforme gèrent le plan de données — constitue l’argument opérationnel principal.
Quand le déployer, et quand s’en abstenir
Déployez-le lorsque l’organisation développe des systèmes multi-agents utilisant plusieurs fournisseurs de LLM, des outils MCP, et a besoin d’une authentification partagée, de traçage et de contrôle des dépenses. Si le trafic A2A augmente et que chaque équipe réinvente les passerelles, la consolidation s’avère avantageuse.
S’abstenir pour l’instant lorsque la seule nécessité est un proxy simple vers un seul fournisseur avec des politiques minimales. Un proxy LLM plus léger peut suffire tant que les protocoles d’agent et la gouvernance multi-locataires ne deviennent pas un véritable problème.
Les démonstrations en environnement neuf avec un seul chatbot justifient rarement l’existence d’un autre plan de contrôle. En revanche, les agents en production qui doivent respecter des exigences réglementaires le justifient souvent.
Leçons pratiques
Agentgateway vise une lacune infrastructurelle émergente : un routage et des politiques unifiés pour les LLM, MCP et A2A, plutôt qu’un ensemble de proxies adaptés à des cas spécifiques. Les équipes de plateforme disposent ainsi d’un endroit pour définir des politiques, observer les interactions et limiter les coûts, sans avoir à réécrire chaque agent. Les équipes d’applications obtiennent quant à elles un contrat stable définissant la manière dont les outils et les modèles sont accessibles.
L’adoption doit reposer sur des preuves concrètes : mesurez le nombre de chemins d’accès personnalisés existants aujourd’hui, celui qui ne disposent pas de suivi partagé, ainsi que la fréquence à laquelle des dépenses inattendues apparaissent. Si ces chiffres sont élevés, un plan de données AI unifié mérite une étude approfondie. S’ils sont faibles, maintenez une architecture légère et réexaminez la situation lorsque l’expansion des agents deviendra un problème.
Détails de routage méritant des tests sous pression
Le routage tenant compte de la latence et des coûts n’est utile que lorsque les signaux d’état sont fiables. Lors d’une augmentation soudaine de la charge, il convient de vérifier que les backends en mauvais état quittent rapidement le pool et que, le cas échéant, les sessions persistantes n’orientent pas le trafic vers une réplique en défaillance. Le routage tenant compte du modèle devrait indiquer dans les traces quel modèle a traité une requête ; sinon, les services financiers et les équipes SRE analysent des tableaux de bord différents.
Testez également le basculement en cas de panne en introduisant délibérément des défauts : révoquez une clé de fournisseur, baissez la limite de vitesse, et assurez-vous que les agents affichent une erreur contrôlée plutôt que de continuer à tenter des requêtes en boucle. Les tentatives de réessai au niveau du gateway doivent être coordonnées avec celles du client afin d’éviter l’amplification des problèmes.
Détails de sécurité pour les examens d’entreprise
La validation JWT et OIDC constitue une exigence de base. Demandez comment les ACL des outils correspondent aux cibles MCP, comment sont stockés les secrets liés aux clés fournisseurs, et si les modifications de politique nécessitent un redémarrage complet ou un chargement en temps réel. Les clusters multi-locataires exigent une isolation claire afin que l’agent d’une équipe ne puisse pas invoquer les outils d’une autre équipe.
Les politiques de limitation de débit doivent distinguer les conversations interactives des tâches d’incorporation par lots. Une seule limite globale de QPS est insuffisante ; des budgets par route et par utilisateur correspondent à la manière dont les plateformes facturent réellement leurs clients internes.
Attentes en matière d’observabilité
OpenTelemetry par défaut est nécessaire mais insuffisant. Vérifiez que la propagation des données depuis les frameworks d’agent se fasse dans les spans du gateway, et que les attributs incluent le nom de la route, l’ID du modèle, le nombre de tokens lorsque c’est disponible, ainsi que les noms des outils MCP. Sans cela, les traces permettent d’expliquer la latence mais pas le coût.
Les stratégies d’échantillonnage des journaux sont également importantes : l’enregistrement complet des requêtes peut être interdit ; une métadonnée structurée accompagnée de politiques de censure constitue généralement le compromis. Il convient de se conformer aux exigences de sécurité avant d’autoriser des enregistrements détaillés dans un environnement non de production.
Gouvernance des coûts en pratique
Un routage tenant compte des coûts peut privilégier des modèles moins chers pour un trafic à faible enjeu, mais les responsables de produit doivent indiquer quels chemins peuvent être dégradés. Il faut associer des budgets pour les passerelles à des alertes lorsque un chemin approche de son plafond mensuel. Les politiques d’accès aux outils qui limitent les actions coûteuses du MCP (balayages volumineux, écritures en masse) empêchent qu’un seul cycle d’agent ne consomme toutes les crédits du mois en une nuit.
Esquisse de déploiement
- Déployer la passerelle dans un espace de noms de type sandbox avec une seule route LLM.
- Associer l’export OTel au collecteur existant ; vérifier un chemin de référence.
- Ajouter une seule cible MCP derrière des mécanismes d’autorisation et une limite de fréquence.
Cette séquence limite l’impact des changements tout en mettant à l’épreuve les fonctionnalités qui distinguent Agentgateway d’un simple proxy LLM.
Adéquation organisationnelle
Les groupes de plateforme qui utilisent déjà des API gateways reconnaîtront ce modèle opérationnel : création de tickets pour les nouvelles routes, politique définie par du code, tableaux de bord partagés. Les équipes d’agents qui possédaient auparavant leurs propres sidecars LiteLLM pourraient résister tant que le gateway ne démontrera pas clairement qu’il réduit les tâches manuelles — clés partagées, quotas partagés, traces partagées. Prévoyez une période de migration durant laquelle les deux approches coexisteront, avec des délais bien définis.
La documentation destinée aux auteurs d’agents doit indiquer comment pointer les SDK vers l’URL de base du gateway, comment transmettre les informations d’identité et comment interpréter les codes d’erreur du gateway. Sans ces indications, les équipes continueront à contourner le plan de traitement pour « juste cette expérience ».
Points clés
- Plan de données unifié : regrouper la redirection du trafic, l’autorisation, la télémétrie, les politiques et les limites de consommation en un seul niveau qui comprend HTTP/gRPC ainsi que les protocoles de modèles et d’agents.
- MCP en tant que services : découvrir et protéger les serveurs d’outils comme n’importe quels autres microservices, et non en tant que solutions ajoutées ultérieurement à côté du proxy LLM.
- Visibilité A2A : l’identification et le suivi des étapes effectuées par les agents transforment des réseaux de type boîte noire en systèmes exploitables.
- Politiques au niveau périphérique : les limites de débit, l’authentification et les ACL des outils doivent être gérées par le gateway afin que le code des agents reste concentré sur la logique de raisonnement.
Les équipes soucieuses de développer des applications natives d’IA scalables, sécurisées et observables — en particulier celles qui combinent des agents autonomes avec divers fournisseurs de modèles — devraient évaluer si leur couche proxy actuelle couvre déjà les protocoles d’agents ou uniquement les complétions de chat. Le premier est une condition indispensable pour la prochaine vague de systèmes d’agents en production ; le second n’est qu’une commodité temporaire.
D’un point de vue opérationnel, commencez par une route LLM et une cible MCP dans un cluster non de production, assurez-vous que les tableaux de bord OpenTelemetry s’affichent correctement, puis étendez progressivement les politiques. Évitez d’activer toutes les fonctionnalités dès le premier jour ; un chemin restreint et bien observé vaut mieux qu’un gateway entièrement configuré mais en qui personne ne fait encore confiance.