Notre agent musical a dit avoir changé une clé sans y toucher

Que s’est-il passé ?

Dans une partition de piano, la portée du bas passait en clé de sol pendant une mesure, la mesure 4, là où l’arpège monte dans l’aigu, puis revenait en clé de fa. La personne a demandé à Starling, à côté de la partition, de mettre la main gauche de la mesure 4 en clé de fa. Starling a appelé l’outil de modification, a reçu un succès en retour et a dit que c’était fait. La page montrait toujours la clé de sol à la mesure 4. Quand la personne a dit que rien n’avait changé, le modèle a suivi la version qui lui paraissait la plus probable et n’a pas relu la mesure.

Nous l’avons trouvé le jour même, en lisant la conversation enregistrée et l’historique des versions de la partition sur notre serveur de préproduction.

Pourquoi l’assistant a-t-il cru que la modification avait fonctionné ?

Parce que toutes les sources dont il disposait le disaient, ou ne disaient rien. Chaque cause, prise seule, aurait été supportable.

• La modification n’a rien changé et a pourtant réussi. Nos outils traitaient toute demande valide comme une nouvelle version. Donner à une portée la clé qu’elle avait déjà était valide : le serveur a donc enregistré une partition identique et répondu « Applied » avec un nouveau numéro de version. Le modèle n’avait aucune raison d’en douter.
• La lecture cachait l’essentiel. La lecture textuelle d’une partition indiquait la clé et l’armure d’ouverture de chaque partie, pas les changements en cours de morceau. Une clé qui changeait à la mesure 4 était invisible dans le texte. Pire, une clé de précaution, imprimée en fin de mesure pour annoncer la clé de la mesure suivante, était comptée comme la clé de cette mesure elle-même.
• Le modèle s’est fié à l’image. Quand le texte et la page affichée se contredisaient, ou que le texte ne disait rien, le modèle jugeait d’après l’image, où les petites clés à l’intérieur d’un système se lisent facilement de travers.

Qu’avons-nous changé ?

Quatre changements, tous faits le 10 octobre 2026, dans le serveur que Starling et le connecteur MCP partagent.

1. Une modification qui laisse la partition telle quelle est refusée. L’outil renvoie une erreur, « Nothing changed » (rien n’a changé : cette modification laisse la partition telle quelle, donc aucune nouvelle version n’a été enregistrée), et le numéro de version ne bouge pas. Annuler et rétablir en sont exemptés.
2. Chaque modification énumère ce qu’elle a écrit. Le résultat contient désormais des lignes comme bar 4 : lower staff clef treble -> bass ou bars 1-4 : key C major -> F major, si bien que le modèle rapporte ce que la partition contient après la modification.
3. Les lectures montrent les changements en cours de morceau. La lecture de la partition indique, pour chaque mesure où ils changent, les clés, la tonalité et le chiffrage, le texte de contrôle marque sur place « clé de sol à partir d’ici » et les changements de tonalité, et une clé de précaution compte désormais pour la mesure qu’elle annonce.
4. Une seule règle pour toutes les voies d’accès. Les instructions de Starling, du serveur MCP et des compétences de notre plug-in disent désormais : ne dire que ce que montrent les résultats d’outil ; une erreur ou « Nothing changed » signifie que la modification n’a pas été faite, donc le dire ; juger les clés, les tonalités et les notes d’après la lecture textuelle, pas d’après une image ; et si la personne conteste, relire ces mesures.

L’ordre compte. Les deux premiers changements mettent les faits dans le résultat que le modèle lit, ce qu’aucune formulation de prompt ne peut faire. La spécification de MCP décrit la même séparation : les erreurs survenues à l’exécution d’un outil vont dans le résultat de l’outil, marquées isError, pour que le modèle les voie et se corrige. Notre « Applied » était un succès là où il aurait fallu une erreur.

Comment le testons-nous ?

De deux façons : l’une est faite, l’autre attend.

• Une vérification de notre suite de tests ouvre une partition dont la portée du bas change de clé à l’intérieur d’une mesure et dont la tonalité change plus loin, puis confirme que chaque lecture montre les deux changements, qu’une modification énumère la clé et la tonalité qu’elle a écrites, et qu’une modification qui ne change rien est refusée sans nouvelle version. Elle s’exécute avec nos autres vérifications rapides à chaque pull request.
• Une évaluation envoie à Starling six demandes sur un morceau de piano de douze mesures construit comme celui qui a mal tourné : une vraie correction de clé, la même correction sur une mesure déjà en clé de fa, une question sur la tonalité après le changement, une modification de hauteur qui ne change rien, une modification de pédale et un décompte des mesures. Un autre modèle énumère chaque affirmation de la réponse et la confronte à la partition telle qu’elle est enregistrée après le tour, jamais aux propres mots de l’assistant. Nous ne l’avons pas encore lancée avant et après le changement : nous n’avons donc aucun taux d’hallucination à communiquer.

Les règles réduisent le taux de fausses affirmations ; elles ne le ramènent pas à zéro. Un modèle peut encore mal lire une mesure à partir de la seule image, c’est pourquoi la règle le renvoie au texte et pourquoi les modifications qu’il fait sont marquées et annulables.

Que dirions-nous à quelqu’un qui construit un agent avec des outils ?

• Un outil ne devrait jamais annoncer un succès pour rien. Si un appel ne peut pas changer l’état, renvoyez une erreur que le modèle peut lire.
• Renvoyez ce qui a été écrit, dans les termes propres au domaine. Répéter la demande en écho ne prouve rien.
• Mettez en texte tous les faits dont le modèle a besoin pour vérifier son travail. Si les faits ne sont que dans une image, le modèle jugera d’après l’image.
• Lisez les conversations. Nous avons trouvé ce problème grâce à une seule conversation enregistrée, pas grâce à un indicateur.