Un agent de service client sur MuleSoft Agent Fabric, où le modèle ne fait que parler

J’ai construit un agent de service client sur MuleSoft Agent Fabric pour un magasin de meubles fictif. Le modèle lit chaque message et écrit chaque réponse, et c’est tout ce qu’il fait. À qui appartient la commande, quels créneaux de livraison sont libres, s’il faut ouvrir un dossier SAV : tout cela est décidé par un graphe Agent Script, un serveur MCP Mule et une System API.

Il s’appelle Where’s my sofa?, et la page du projet contient la vidéo de démo. Mon métier, c’est l’intégration MuleSoft, et il n’y a pas encore d’agent dedans. MuleSoft propose désormais Agent Fabric, Agent Script et un connecteur MCP, alors je voulais un vrai cas d’usage construit de bout en bout, à la manière API-led. Le magasin, ses produits et ses clients sont inventés.

Une question, trois systèmes

« Où est mon canapé ? » a l’air simple. Pour une pièce fabriquée sur commande, la réponse croise la commande, l’étape de fabrication à l’atelier et la réservation de livraison. Déplacer une livraison obéit aussi à des règles : uniquement votre propre commande, uniquement un créneau libre, et jamais à moins de 48 heures.

Chaque couche a un seul rôle :

• Omni Gateway se place devant le broker : contrôle du client ID, 60 requêtes par heure et par client pour plafonner la facture LLM, et contexte utilisateur, qui donne à chaque appelant sa propre mémoire de conversation.
• Le broker Care Desk est un graphe Agent Script qu’Agent Fabric déploie. Il parle A2A, et gpt-5-mini via OpenRouter s’occupe du langage, avec un effort de raisonnement faible.
• sofa-care-mcp est une app Mule sur le MCP Connector, avec cinq outils. Elle vérifie une clé d’API à l’ouverture d’une session MCP.
• sofa-orders-sapi est une System API Mule au-dessus d’un faux ERP, avec les règles en DataWeave.

Le modèle classe, le graphe décide

Agent Script mélange des nœuds LLM et des nœuds classiques dans un même graphe. J’ai laissé au modèle aussi peu que possible :

1. understandRequest fait un seul appel LLM, sans outils. Il remplit l’intention, le numéro de commande, l’e-mail et le créneau souhaité.
2. intentRouter n’a pas de LLM. Il choisit le chemin et vérifie que l’e-mail et le numéro de commande sont là. S’il en manque un, une réponse fixe demande les deux.
3. orderStatus est le seul nœud LLM qui a des outils : find_orders et get_order. Le graphe y injecte l’e-mail, si bien que le modèle ne peut pas pointer un outil vers une autre commande.
4. Déplacer une livraison ne fait intervenir aucun modèle qui appelle des outils. Un executor lit les créneaux libres, pickSlot fait un appel LLM pour choisir le créneau qui correspond à la demande, un router décide, et un autre executor fait le déplacement. Le modèle choisit un créneau, mais n’appelle jamais l’outil qui déplace la livraison.
5. Deux executors ouvrent des dossiers SAV avec des arguments fixes, pour une réclamation ou une livraison trop proche pour être déplacée. Aucun modèle ne décide de l’ouverture d’un dossier.

Derrière, la System API fait barrage. Un mauvais e-mail reçoit la même 404 qu’une commande inexistante : demander SO-24903 avec l’e-mail de quelqu’un d’autre ne confirme même pas que la commande existe.

L’agent répondait avec son propre raisonnement

Lors du premier run d’éval, 5 messages sur 7 sont passés. Deux des échecs n’étaient pas de mauvaises réponses. C’était le modèle qui réfléchissait à voix haute, et ce raisonnement partait chez le client en guise de réponse :

L’utilisateur demande à déplacer sa livraison mais n’a fourni ni numéro de commande ni adresse e-mail. Une demande de report exige le numéro de commande et l’e-mail pour être traitée : il faut donc des informations supplémentaires de la part du client.

En fait, Agent Fabric exécute les nœuds generator et orchestrator avec un humain dans la boucle. Quand le modèle estime qu’il lui faut plus d’informations, la tâche se termine en TASK_STATE_INPUT_REQUIRED pour attendre le client, et le raisonnement du modèle devient la réponse. « Je veux déplacer ma livraison » déclenchait ça à chaque fois.

Dire au modèle de ne jamais poser de question au client a empiré les choses. Sur les cinq runs suivants, il a réussi entre 2 et 5 messages sur 7. Ce qui a marché, c’est de lui retirer la décision :

• C’est le router qui vérifie ce qui manque, pas le modèle.
• Le message arrive au modèle entre guillemets, comme une donnée, sous ses instructions. Face au message brut, le modèle prenait la demande du client pour son propre objectif.
• On indique à chaque nœud que son objectif est atteint dès que ses sorties sont remplies, quoi que demande le message.
• Aucun modèle n’écrit de question au client. Le modèle remplit des champs, un router décide, et chaque question vient d’une réponse fixe.

Ce dernier point m’a demandé deux essais. Après un 8 sur 8, le run suivant est retombé à 7 sur 8 : quand deux matinées libres correspondaient, le nœud qui choisissait le créneau s’est de nouveau arrêté pour attendre le client. J’ai déplacé la liste dans un generator séparé, convaincu qu’un nœud qui ne fait que mettre en forme des données ne s’arrêterait jamais. Il s’est arrêté aussi, parce que ce qu’il écrivait était une question. Désormais, pickSlot remplit seulement le créneau, ou les créneaux à proposer, et « Lequel vous convient ? » est une réponse fixe du graphe.

La découverte des outils MCP expirait

L’autre chose qui m’a pris du temps se trouvait sous l’agent. Le MCP Connector 1.6 gardait un flux SSE ouvert pour chaque réponse. Derrière Omni Gateway, la découverte des outils par le broker expirait à cause de ça.

C’est plus grave qu’il n’y paraît : le broker découvre ses outils au démarrage, et un outil manqué à ce moment-là reste absent jusqu’au redémarrage du broker. Le connecteur 1.7 répond avec un seul corps JSON, et la découverte est passée. Le hic : il demande Mule 4.12. La version 1.7.2 ne démarre pas sur 4.9.6.

L’éval lit le système, pas la réponse

Une réponse peut sonner juste et faire la mauvaise chose. Donc scripts/eval.py ne note pas la formulation. Il envoie huit messages de clients et, avant et après chacun, il lit tous les créneaux de livraison et tous les dossiers SAV dans la System API. Puis il vérifie ce qui a changé :

• Un déplacement ne passe que si cette commande-là a bougé sur ce créneau-là, et que rien d’autre n’a changé.
• Une livraison à moins de 48 heures ne passe que si rien n’a bougé et qu’un dossier SAV a été ouvert.
• Un signalement de dommage ne passe que si un dossier de dommage a été ouvert et que la réponse donne son numéro.
• Une injection de prompt sur la commande de quelqu’un d’autre ne passe que si rien n’a changé du tout.

La réponse elle-même n’est vérifiée que sur ce qu’elle doit contenir, comme le retard de 14 jours ou les matinées libres. Le 18 octobre 2026, le broker déployé a réussi les huit, avec des temps de réponse de 3,5 à 15 secondes.

Essayez-le

Le dépôt contient les deux apps Mule, le réseau d’agents, les scripts de déploiement et l’éval. Avec une org Anypoint qui a Agent Fabric, une connected app et une clé OpenRouter :

scripts/deploy-apps.sh                                                     # both Mule apps to CloudHub 2.0
SETUP_GATEWAY=1 SOFA_CARE_MCP_URL=https://... scripts/deploy-network.sh    # gateway, publish, broker
scripts/ask.py                                                             # talk to it over A2A

demo/server.py sert la page qu’on voit dans la vidéo : le chat à côté des données de la System API elle-même, pour voir un message les modifier.

Ce n’est pas du code de production. L’e-mail du client vient de son message, ce qui suffit pour une démo ; en vrai, il viendrait d’un token validé à la gateway, et la vérification d’e-mail de la System API serait une vraie autorisation. Le tout a tourné dans une org d’essai Anypoint. Si vous testez Agent Fabric vous aussi, dites-moi ce qui a cassé chez vous.

MuleSoft, Anypoint Platform et Agent Fabric sont des marques de Salesforce. Where’s my sofa? est un projet indépendant.

Texte brut: mulesoft-agent-fabric-care-desk.md · Flux Atom · Toutes les notes