Architecture Développement 2 days

Agent Fabric et gouvernance des réseaux d'agents (Course #agent-fabric)

For architectes solution, ingénieurs plateforme, responsables intégration IA.

S'inscrire à ce cours Toutes les formations
Réf#agent-fabric
Durée2 jours
Formats4 modalités
Certif—
Prérequis1

À la fin, vous saurez

À l'issue de cette formation, vous serez capable d'exploiter un réseau d'agents gouverné sur MuleSoft Agent Fabric — catalogue d'agents référencé, agent-network.yaml versionné, policies d'agents Omni Gateway et traces Agent Visualizer — afin que chaque appel d'agent à agent ait un propriétaire, un budget et une trace.

Cas fil rouge

Solvane Health Group exploite 6 filiales nationales sur 130 API Mule et a laissé s'accumuler 38 agents répartis entre Agentforce, Amazon Bedrock et Microsoft Copilot — aucun référencé, aucun derrière une gateway, et trois d'entre eux déjà enchaînés dans un assistant de triage par du code de liaison artisanal. Les données cliniques ne peuvent pas quitter l'UE, le budget agents est plafonné à 18 k€/mois et l'équipe plateforme doit livrer un réseau d'agents gouverné sous contraintes fermes : 100 % des agents de production derrière Omni Gateway, routage du broker sous 400 ms p95 et traçabilité de chaque tâche déléguée, du broker jusqu'à l'outil.

Programme chaque ligne est quelque chose que vous faites

5 modules · 15 sujets · dans l'ordre du cours

  1. Module 1

    Recenser le parc d'agents

    Objectif. Diagnostiquer le parc d'agents non référencé et produire une fiche Portfolio pour chaque agent, serveur MCP et proxy de modèle concerné.

    • Référencer agents, serveurs MCP et proxys LLM dans le portfolio Anypoint Exchange, chaque fiche portant propriétaire, environnement et niveau de criticité
    • Lancer les agent scanners sur Amazon Bedrock, Google Vertex AI et Microsoft Copilot, puis confronter leurs découvertes à un inventaire déclaré de 38 agents
    • Verrouiller le catalogue avant toute orchestration : ≥ 95 % des fiches de production nomment un propriétaire et précisent une zone de résidence des données
  2. Module 2

    Le réseau d'agents en code

    Objectif. Construire un réseau d'agents à partir d'un agent-network.yaml versionné et le déployer sur CloudHub 2.0 comme un artefact relisible.

    • Déclarer les sections registry et context de agent-network.yaml — agents, agent brokers, LLM, serveurs MCP, policies — dans Anypoint Code Builder
    • Séparer raisonnement et flux de contrôle en Agent Script : nœuds orchestrator et subagent pour le jugement, nœuds executor, router et echo pour le reste (cible : ≥ 60 % de nœuds déterministes)
    • Publier les actifs sur Exchange et déployer dans un private space CloudHub 2.0 via le plugin Anypoint CLI Agent Fabric (cible : reconstruction reproductible en ≤ 15 min)
  3. Module 3

    Parler A2A, exposer MCP

    Objectif. Construire la surface protocolaire du réseau — applications Mule conformes A2A et serveurs MCP — et mesurer le coût en contexte de chaque outil exposé.

    • Rendre les applications Mule conformes A2A avec le connecteur A2A et publier une agent card exacte par agent, alignée sur A2A 1.0
    • Transformer les API existantes en serveurs MCP via le MCP Bridge, en n'exposant que les outils réellement utiles à l'agent (plafond : 12 outils par serveur)
    • Réduire la dépense en contexte avec MCP Tool Mapping et MCP Tools Progressive Disclosure (cible : −30 % de tokens de prompt par tâche face à un listing complet des outils)
  4. Module 4

    Une policy à chaque saut

    Objectif. Concevoir le jeu de policies Omni Gateway pour le trafic d'agents et prouver son application sur les sauts A2A comme MCP.

    • Placer chaque agent A2A et chaque serveur MCP derrière une Agent and Tool Instance dans API Manager (cible : 100 % des agents de production, 0 route directe vers l'amont)
    • Enchaîner A2A PII Detector, A2A Schema Validation et MCP PII Detector, puis les éprouver par tests négatifs porteurs d'identifiants patients semés sur 5 catégories de données personnelles
    • Circonscrire le rayon d'impact avec les règles Allow/Block de MCP Global Access et MCP Attribute-Based Access Control : tout outil d'écriture bloqué par défaut, 3 dérogations maximum par réseau, chacune avec un approbateur nommé
  5. Module 5

    Brider le réseau qui s'emballe

    Objectif. Évaluer le comportement du réseau d'agents au regard de ses modes de défaillance et poser la limite qui neutralise chacun d'eux.

    • Suivre une tâche en échec du broker au subagent puis à l'outil MCP dans Agent Visualizer et Anypoint Monitoring (fenêtre de 30 minutes à 30 jours, 24 heures par défaut)
    • Plafonner l'emballement du raisonnement dans la spécification — max_number_of_loops (25 par défaut), max_consecutive_errors, task_timeout_secs — calibré sur un budget de routage de 400 ms p95
    • Alerter sur ce qu'Agent Visualizer expose vraiment : agents hors couverture de policy et taux de requêtes en échec supérieur à 2 %, avec une entrée de runbook rédigée pour chacun

Références & documentation officielle chaque affirmation ci-dessus a une source

Module 1

Module 2

Module 3

Module 4

Module 5

Dans la filière Architecture

#architecture-fundamentals · Architecture Solution MuleSoft : les fondamentaux#advanced-architecture-c4e · Architecture d'intégration avancée & animation du C4E#eda-mq · Architecture événementielle avec Anypoint MQ#cloud-native-gateway · Praticien des gateways API cloud-native#b2b-edi · Intégration B2B avec Anypoint Partner Manager & X12 EDI#omni-gateway · Omni Gateway & gestion des API multi-protocoles#api-governance · Gouvernance des API à l'échelle & API Experience Hub#ai-capabilities · Capacités IA de MuleSoft

Une formation pour votre équipe ?

Chaque session est adaptée à vos cas d'usage, vos données et votre planning.

Demander un devis