Nuestro agente musical dijo que cambió una clave que no tocó

¿Qué pasó?

En una partitura de piano, el pentagrama inferior pasaba a clave de sol durante un compás, el 4, donde el arpegio queda agudo, y volvía a clave de fa después. La persona le pidió a Starling, junto a la partitura, que pusiera la mano izquierda del compás 4 en clave de fa. Starling llamó a la herramienta de edición, recibió un éxito y dijo que ya estaba. La página seguía mostrando clave de sol en el compás 4. Cuando la persona dijo que no había cambiado nada, el modelo se quedó con la versión que parecía más probable y no volvió a leer el compás.

Lo encontramos leyendo el chat guardado y el historial de versiones de la partitura en nuestro servidor de pruebas (staging), ese mismo día.

¿Por qué creyó el asistente que la edición había funcionado?

Porque todas las fuentes que tenía decían que sí, o no decían nada. Cada causa por sí sola se habría podido salvar.

• La edición no cambió nada y aun así tuvo éxito. Nuestras herramientas trataban cualquier petición válida como una versión nueva. Poner en un pentagrama la clave que ya tenía era válido, así que el servidor guardó una partitura idéntica y respondió “Applied” con un número de versión nuevo. El modelo no tenía motivos para dudar.
• La lectura ocultaba lo importante. La lectura en texto de una partitura enumeraba la clave inicial y la tonalidad de cada parte, no los cambios dentro de la pieza. Una clave que cambiaba en el compás 4 era invisible en texto. Peor aún, una clave de precaución al final de un compás, impresa para avisar de la clave del compás siguiente, se contaba como la clave propia de ese compás.
• El modelo se fió de la imagen. Cuando el texto y una página renderizada no coincidían, o el texto no decía nada, el modelo juzgaba por la imagen, donde las claves pequeñas dentro de un sistema se leen mal con facilidad.

¿Qué cambiamos?

Cuatro cambios, todos hechos el 10 de octubre de 2026, en el servidor que comparten Starling y el conector MCP.

1. Se rechaza una edición que deja la partitura como estaba. La herramienta devuelve un error, “Nothing changed” (nada cambió: esta edición deja la partitura como estaba, así que no se guardó ninguna versión nueva), y el número de versión no cambia. Deshacer y rehacer quedan exentos.
2. Cada edición enumera lo que escribió. El resultado ahora incluye líneas como bar 4: lower staff clef treble -> bass o bars 1-4: key C major -> F major, de modo que el modelo informa de lo que hay en la partitura después de la edición.
3. Las lecturas muestran los cambios dentro de la pieza. La lectura de la partitura indica, en cada compás donde cambian, las claves, la tonalidad y la indicación de compás; el texto de revisión marca “treble clef from here” (clave de sol a partir de aquí) y los cambios de tonalidad en su sitio, y una clave de precaución ahora cuenta para el compás al que avisa.
4. Una regla compartida para todas las vías. Las instrucciones de Starling, del servidor MCP y de las skills de nuestro plugin dicen ahora: di solo lo que muestran los resultados de las herramientas; un error o “Nothing changed” significa que la edición no se hizo, así que dilo; juzga las claves, las tonalidades y las notas por la lectura en texto, no por una imagen; y si la persona lo discute, vuelve a leer esos compases.

El orden importa. Los dos primeros ponen los hechos en el resultado que lee el modelo, algo que ninguna redacción de un prompt puede lograr. La especificación de MCP describe la misma división: los errores al ejecutar una herramienta van en el resultado de la herramienta, marcados con isError, para que el modelo los vea y se corrija. Nuestro “Applied” fue un éxito donde debía haber un error.

¿Cómo lo probamos?

De dos maneras: una terminada y otra pendiente.

• Una comprobación de nuestra suite de pruebas abre una partitura cuyo pentagrama inferior cambia de clave dentro de un compás y cuya tonalidad cambia más adelante, y confirma que todas las lecturas muestran los dos cambios, que una edición enumera la clave y la tonalidad que escribió y que una edición que no cambia nada se rechaza sin crear una versión nueva. Se ejecuta con nuestras otras comprobaciones rápidas en cada pull request.
• Una evaluación envía a Starling seis peticiones sobre una pieza de piano de doce compases construida como la que salió mal: una corrección de clave real, la misma corrección en un compás que ya estaba en clave de fa, una pregunta sobre la tonalidad después del cambio, una edición de altura que no cambia nada, una edición de pedal y un recuento de compases. Otro modelo enumera cada afirmación de la respuesta y la contrasta con la partitura tal como quedó guardada después del turno, nunca con las palabras del propio asistente. Todavía no la hemos ejecutado antes y después del cambio, así que no tenemos una tasa de alucinaciones que comunicar.

Las reglas reducen la tasa de afirmaciones falsas; no la dejan en cero. Un modelo todavía puede leer mal un compás solo con la imagen, y por eso la regla lo envía al texto y por eso las ediciones que hace quedan marcadas y se pueden deshacer.

¿Qué le diríamos a quien construye un agente con herramientas?

• Una herramienta nunca debe informar de éxito cuando no ha cambiado nada. Si una llamada no puede cambiar el estado, devuelve un error que el modelo pueda leer.
• Devuelve lo que se escribió, en los términos propios del dominio. Repetir la petición como un eco no demuestra nada.
• Pon en texto todos los hechos que el modelo necesita para comprobar su trabajo. Si los hechos solo están en una imagen, el modelo juzgará por la imagen.
• Lee las conversaciones. Esto lo descubrimos a partir de un solo chat guardado, no de una métrica.