Dans le déploiement de MoEngage décrit par AWS et l’entreprise, AgentCore Gateway transforme des opérations d’API REST internes, décrites dans des spécifications OpenAPI, en outils accessibles aux agents selon leurs permissions. Cette approche s’appuie sur des API existantes et évite de présenter tout le catalogue d’outils à chaque agent.

MoEngage indique que ses équipes ont développé environ 400 API REST dans sept régions AWS. La passerelle dessert environ 400 opérations enregistrées auprès de dix agents internes. Les opérations exposées et les API internes sont deux décomptes distincts.

Des spécifications OpenAPI aux outils pour agents

Les équipes ajoutent l’annotation x-moe-mcp aux spécifications OpenAPI des API qu’elles souhaitent exposer. Un pipeline d’intégration continue vérifie l’annotation, enregistre la cible dans la passerelle et applique les règles Cedar. AgentCore Gateway génère alors des outils compatibles avec le Model Context Protocol (MCP), un protocole qui permet aux agents d’identifier et d’appeler des outils. L’exposition est choisie par les équipes, avec des options distinctes pour les usages internes et externes.

Concrètement, les agents de MoEngage peuvent vérifier des campagnes avant leur lancement, surveiller la santé de la diffusion ou créer des segments à partir d’instructions en langage naturel. Ces tâches s’appuient sur des opérations d’API enregistrées comme outils.

IAM et Cedar déterminent les accès

Chaque agent interne utilise son propre rôle AWS Identity and Access Management (IAM), et ses requêtes vers la passerelle sont signées avec SigV4. Les règles Cedar sont évaluées côté serveur pour déterminer quels outils l’agent peut voir et appeler. Dans l’exemple de vérification de campagne, une règle autorise les outils de lecture des campagnes et interdit les actions d’écriture.

Le contexte du compte, de l’utilisateur, du rôle et de la base de données passe dans des en-têtes X-MOE-*, plutôt que dans des arguments d’outil modifiables par le modèle. La liste des outils et la recherche sémantique ne transportent pas l’identité du locataire ; l’appel d’un outil la transmet. L’accès aux outils et le contexte nécessaire à leur exécution suivent ainsi des voies distinctes.

L’authentification dépend aussi du service concerné. Le déploiement interne décrit par AWS utilise SigV4 et les rôles IAM. Le service MCP public distinct de MoEngage utilise, selon le même compte, des jetons JWT conformes à OIDC sur AgentCore Runtime.

Un trajet réseau privé vers les API internes

Les services d’agents envoient leurs requêtes HTTPS à un point de terminaison d’interface VPC doté d’un DNS privé. AgentCore Gateway utilise ensuite une sortie gérée par Amazon VPC Lattice pour joindre les API internes. AWS décrit cette route interne comme ne passant pas par un point de terminaison public.

La recherche évite de charger tout le catalogue

Pour trouver les outils adaptés à une tâche, la bibliothèque cliente de MoEngage propose search_tools, un outil de méta-recherche sémantique. L’agent reçoit des candidats pertinents au lieu de charger l’ensemble du catalogue dans son contexte. C’est utile quand de nombreuses opérations sont disponibles : l’agent cherche selon la tâche à accomplir, puis appelle un outil auquel son rôle donne accès.

Les gains d’intégration restent des estimations de MoEngage

MoEngage estime à environ six mois l’effort d’ingénierie de plateforme économisé et indique que l’intégration d’une nouvelle API prend des heures plutôt que des jours. Ces chiffres portent sur l’intégration et le travail d’ingénierie, pas sur le temps de réponse des agents.