Unser Agent „änderte“ einen Notenschlüssel, den er nie anfasste

Was ist passiert?

In einer Klavierpartitur wechselte das untere Notensystem für einen Takt, Takt 4, in den Violinschlüssel, wo der gebrochene Akkord hoch liegt, und danach wieder in den Bassschlüssel. Die Person bat Starling neben der Partitur, die linke Hand in Takt 4 in den Bassschlüssel zu setzen. Starling rief das Bearbeitungs-Tool auf, bekam einen Erfolg zurück und sagte, es sei erledigt. Die Seite zeigte in Takt 4 weiter den Violinschlüssel. Als die Person sagte, es habe sich nichts geändert, folgte das Modell der Darstellung, die wahrscheinlicher klang, und las den Takt nicht noch einmal.

Gefunden haben wir das am selben Tag, indem wir den gespeicherten Chat und den Versionsverlauf der Partitur auf unserem Staging-Server gelesen haben.

Warum glaubte der Assistent, die Bearbeitung habe funktioniert?

Weil jede Quelle, die er hatte, es bestätigte oder schwieg. Jede Ursache für sich wäre verkraftbar gewesen.

• Die Bearbeitung änderte nichts und war trotzdem erfolgreich. Unsere Tools behandelten jede gültige Anfrage als neue Version. Ein Notensystem auf den Schlüssel zu setzen, den es schon hatte, war gültig, also speicherte der Server eine identische Partitur und antwortete „Applied“ mit einer neuen Versionsnummer. Das Modell hatte keinen Grund, daran zu zweifeln.
• Die Textdarstellung verbarg, worauf es ankam. Sie nannte für jede Stimme den Anfangsschlüssel und die Tonart, nicht die Änderungen mitten im Stück. Ein Schlüssel, der in Takt 4 wechselte, war im Text unsichtbar. Schlimmer noch: Ein Warnschlüssel am Ende eines Takts, der den Schlüssel des nächsten Takts ankündigt, wurde als eigener Schlüssel dieses Takts gezählt.
• Das Modell vertraute dem Bild. Wenn Text und gerenderte Seite einander widersprachen oder der Text nichts sagte, beurteilte das Modell die Sache nach dem Bild, auf dem sich kleine Schlüssel innerhalb einer Zeile leicht falsch lesen lassen.

Was haben wir geändert?

Vier Änderungen, alle am 10. Oktober 2026, in dem Server, den Starling und der MCP-Konnektor gemeinsam nutzen.

1. Eine Bearbeitung, die die Partitur so lässt, wie sie war, wird abgelehnt. Das Tool gibt einen Fehler zurück, „Nothing changed“ (Nichts hat sich geändert: Diese Bearbeitung lässt die Partitur, wie sie war, deshalb wurde keine neue Version gespeichert), und die Versionsnummer bleibt, wie sie ist. Rückgängigmachen und Wiederherstellen sind ausgenommen.
2. Jede Bearbeitung listet auf, was sie geschrieben hat. Das Ergebnis enthält jetzt Zeilen wie bar 4: lower staff clef treble -> bass oder bars 1-4: key C major -> F major, damit das Modell meldet, was nach der Bearbeitung in der Partitur steht.
3. Lesezugriffe zeigen Änderungen mitten im Stück. Die Textdarstellung der Partitur nennt Schlüssel, Tonart und Taktart jedes Takts dort, wo sie wechseln, der Prüftext markiert „treble clef from here“ (Violinschlüssel ab hier) und Tonartwechsel an Ort und Stelle, und ein Warnschlüssel zählt jetzt zu dem Takt, den er ankündigt.
4. Eine gemeinsame Regel für jeden Zugang. Die Anweisungen für Starling, den MCP-Server und die Skills unseres Plug-ins sagen jetzt: Sag nur, was die Tool-Ergebnisse zeigen; ein Fehler oder „Nothing changed“ heißt, dass die Bearbeitung nicht gemacht wurde, also sag das; beurteile Schlüssel, Tonarten und Noten nach der Textdarstellung, nicht nach einem Bild; und wenn die Person widerspricht, lies diese Takte noch einmal.

Die Reihenfolge ist wichtig. Die ersten beiden bringen die Fakten in das Ergebnis, das das Modell liest, und das kann keine Formulierung in einem Prompt leisten. Die Spezifikation von MCP beschreibt dieselbe Aufteilung: Fehler beim Ausführen eines Tools gehören in das Tool-Ergebnis, markiert mit isError, damit das Modell sie sehen und sich selbst korrigieren kann. Unser „Applied“ war ein Erfolg, wo ein Fehler hätte stehen müssen.

Wie testen wir das?

Auf zwei Arten, eine fertig und eine noch offen.

• Eine Prüfung in unserer Testsuite öffnet eine Partitur, deren unteres Notensystem mitten in einem Takt den Schlüssel wechselt und deren Tonart später wechselt, und bestätigt dann, dass jeder Lesezugriff beide Änderungen zeigt, dass eine Bearbeitung den Schlüssel und die Tonart auflistet, die sie geschrieben hat, und dass eine Bearbeitung, die nichts ändert, ohne neue Version abgelehnt wird. Sie läuft bei jedem Pull-Request zusammen mit unseren anderen schnellen Prüfungen.
• Eine Evaluation schickt Starling sechs Anfragen zu einem Klavierstück mit zwölf Takten, das so gebaut ist wie das, bei dem es schiefging: eine echte Schlüsselkorrektur, dieselbe Korrektur an einem Takt, der schon im Bassschlüssel steht, eine Frage zur Tonart nach der Änderung, eine Tonhöhenänderung, die nichts ändert, eine Pedaländerung und eine Frage nach der Taktanzahl. Ein separates Modell listet jede Behauptung der Antwort auf und gleicht sie mit der Partitur ab, wie sie nach der jeweiligen Runde gespeichert war, nie mit den eigenen Worten des Assistenten. Wir haben sie noch nicht vor und nach der Änderung laufen lassen, deshalb können wir keine Halluzinationsrate nennen.

Regeln senken die Rate falscher Behauptungen, aber sie bringen sie nicht auf null. Ein Modell kann einen Takt allein anhand des Bildes noch immer falsch lesen. Deshalb schickt die Regel es zum Text, und deshalb sind seine Bearbeitungen markiert und lassen sich rückgängig machen.

Was würden wir jemandem raten, der einen Agenten mit Tools baut?

• Ein Tool sollte nie Erfolg für nichts melden. Wenn ein Aufruf den Zustand nicht ändern kann, gib einen Fehler zurück, den das Modell lesen kann.
• Gib zurück, was geschrieben wurde, in den Begriffen des Fachgebiets. Ein Echo der Anfrage beweist nichts.
• Stell jede Tatsache, die das Modell zum Prüfen seiner Arbeit braucht, als Text bereit. Stehen die Fakten nur in einem Bild, urteilt das Modell nach dem Bild.
• Lies die Gespräche. Wir haben das an einem gespeicherten Chat gefunden, nicht an einer Kennzahl.