Cómo arreglamos los errores de un agente de IA: datos primero, prompt al final

Durante años, una forma de enseñarle a un modelo los casos de un producto fue el ajuste fino: entrenarlo con ejemplos propios. Ese camino se está cerrando. Según su página de deprecaciones, OpenAI no deja crear entrenamientos nuevos a quien nunca los usó desde mayo de 2026, y desde enero de 2027 tampoco a sus clientes actuales.

Si el modelo se alquila, como planteamos en la primera parte, lo que tiene que aprender de los errores es el harness. Así lo hacemos: cada respuesta se puede reportar; un error se arregla primero en los datos, después en el dato que faltaba y solo al final en el prompt; y cada arreglo se prueba con una familia de casos que se corren más de una vez. Es la última parte de la serie.

Que cada error se pueda reportar en el momento

Volvamos a la nota de la segunda parte. En el proyecto hay dos trabajos abiertos de Novak, la instalación de paneles y un presupuesto de baterías, y supongamos que esta vez Werk se equivoca: marca como terminado el presupuesto. La persona contesta "era la instalación", y Werk deshace el cambio y lo hace en la tarjeta correcta. Para ella, el problema terminó ahí.

Para el harness, en cambio, ahí empieza el trabajo. Un error que solo se corrige en el chat se va a repetir con el próximo cliente que tenga dos trabajos abiertos. Por eso, junto a cada respuesta de Werk hay una forma de reportarla: se elige un motivo y, si se quiere, se agrega una nota de voz o un texto que lo explique.

Conviene tenerlo desde el primer día, cuando todavía parece pronto, y decidir también quién lo lee. Lo que alguien cuenta en un reporte es parte del trabajo de su equipo. En Werk, esos reportes los lee un agente, no una persona.

Primero los datos, después las instrucciones

Frente a un error del modelo, la tentación es ir directo al prompt y agregar una línea. Antes conviene leer, completo, lo que el modelo recibió en ese turno: no lo que el código debería haberle mandado, sino el pedido exacto que salió hacia el proveedor, con las instrucciones, la conversación, las tarjetas y el mensaje. Con eso, las preguntas van en orden.

La primera es si los datos estaban bien. Si la conversación llegó incompleta, si la tarjeta correcta no estaba entre las candidatas o si dos partes del contexto se contradecían, el modelo no tenía cómo acertar, y el arreglo va en el harness. En el caso de Novak, los datos estaban bien: el modelo vio las dos tarjetas y dónde coincidía cada una.

La segunda es si faltaba un dato para decidir. Al modelo le faltaba lo que la persona sabía de memoria: que la instalación la llevaba ella y la había empezado esa mañana, y que el presupuesto era de otra persona. Ninguna instrucción reemplaza un dato que el modelo no ve. El arreglo es mostrarle quién lleva cada tarjeta y en qué estado está.

Solo después de esas dos preguntas se miran las instrucciones, cuando el modelo tiene datos correctos y completos y aun así se equivoca. Y lo que se escribe entonces es un principio, nunca una regla para el caso. Una línea como "si dice Novak, es la instalación" arregla esta nota y rompe la de la semana siguiente, cuando lo que se termina es el presupuesto.

De un error a una familia de casos

Un arreglo tiene que quedar probado, y no con un solo caso. Del reporte de Novak sale una clase de error: dos trabajos abiertos del mismo cliente y un mensaje que no dice cuál.

Con esa clase se escribe una familia de casos: la misma situación con otras palabras y en otros idiomas, en una nota de voz, con dos clientes distintos que se llaman igual. Y también el caso opuesto, con un solo trabajo abierto, donde no hay nada que dudar. Si el arreglo solo funciona con "listo lo de Novak", el error sigue ahí.

Conviene que esos casos no los escriba quien hace el arreglo. Quien arregla tiende a probar justo lo que arregló; quien parte de la clase de error prueba lo que la persona necesita. Así, los casos especiales viven en la batería de pruebas, no en el prompt: las instrucciones dicen principios, y los casos comprueban que esos principios alcanzan.

Medir más de una vez

Un modelo no responde siempre igual al mismo mensaje. τ-bench (2024), una prueba de agentes que atienden clientes con herramientas, lo midió: incluso los mejores agentes de ese momento resolvían menos de la mitad de las tareas. Y en el escenario de una tienda, la probabilidad de resolver bien una misma tarea en los ocho intentos caía por debajo del 25%.

Por eso cada caso se corre más de una vez. Un arreglo que pasa una vez y falla en la siguiente vuelta sigue sin estar hecho.

Un caso que falla una de cada diez veces es un error que, tarde o temprano, alguien va a encontrar arriba de un techo.

Y cuando un arreglo entra, conviene correr la batería entera, no solo los casos nuevos. Es la forma de saber que se corrigió un error sin romper otra cosa.

El harness aprende con el uso

Los modelos van a seguir equivocándose a veces, como cualquiera que trabaja con prisa. Lo que sí se puede construir es lo que pasa después: que cada error reportado se vuelva una familia de casos, y que esos casos se comprueben cada vez que algo cambia.

Quien programa y quien trabaja en una oficina ya tienen un harness pensado para su trabajo. Quien instala paneles en un techo ahora también tiene uno, y cada error que alguien reporta lo mejora para todos.