En la demo el piloto funciona a la perfección, en producción el agente empieza a hacer cosas raras y el equipo sale a buscar un modelo más potente. Un mes después, con el modelo nuevo, se repite lo mismo, solo que más caro.
La tentación de explicarlo por la calidad del modelo es grande, porque esa explicación da un siguiente paso claro. Pero en agosto de 2026 salió un benchmark que midió un factor muy distinto.
El experimento que midió el precio de una regla no escrita
DiG-bench (Discovery in Games) se publicó el 12 de agosto de 2026. El trabajo estuvo a cargo del grupo de investigación Thinking About Thinking, en colaboración con Oxford, Princeton, el MIT, Inria y KAUST; entre los coautores están Jürgen Schmidhuber, Joshua Tenenbaum, Thomas Griffiths y Tri Dao.
El diseño es este: 70 juegos de texto, cada uno con sus propias reglas de transformación. El jugador no conoce ni las reglas ni la condición de victoria: la única forma de averiguarlas es interactuar, es decir, hacer una jugada, ver qué ha cambiado y corregir la hipótesis. Los juegos se reparten en siete niveles de dificultad; los autores hicieron públicos 21 y mantuvieron 49 cerrados para garantizar mediciones justas. Además, señalan que estos juegos no existen en ningún otro lugar de internet, así que el modelo no pudo verlos durante el entrenamiento: la cuestión de la contaminación de datos aquí simplemente no se plantea.
Los autores hicieron una ablación directa: tomaron Gemini 3.1 Pro y le dieron los mismos 70 juegos, pero esta vez con el texto de las reglas en la mano.
Giving Gemini access to the ground-truth rules of the game, specified in concise natural language, raises the win rate from 18/70 to 69/70 games.
— DiG-bench: Discovery in Games, arXiv:2608.12593
La diferencia entre esas dos cifras fue un texto breve que, en el primer caso, simplemente no existía. Los autores formulan la conclusión sin suavizarla: la dificultad principal de su benchmark está precisamente en averiguar las reglas.
Qué le dieron exactamente al modelo y qué no había en esa descripción
Los autores caracterizan con mucha precisión la descripción que subió el resultado al 99%: resumía la dinámica del juego y la condición de victoria, pero no contenía nada relacionado con la política de comportamiento: ni estrategias, ni tácticas, ni secuencias de jugadas.
These rules summarized the dynamics of the game and the win condition; but they excluded any policy-related information like strategies, tactics or move sequences.
— DiG-bench: Discovery in Games, arXiv:2608.12593
Al modelo no le explicaron cómo jugar. Le explicaron a qué está jugando y qué se considera ganar aquí.
Cuando a una empresa le dicen «describid el proceso», suele escribir justo la parte que en el experimento se quitó. El resultado son unas instrucciones: primero llama, luego crea la oportunidad, después envía la propuesta comercial, a los tres días haz un recordatorio. Eso es una secuencia de jugadas. En cambio, la mecánica —qué objetos existen, en qué estados pueden estar, qué transiciones están permitidas y cuáles no— queda sin decir, porque dentro del equipo parece una obviedad que da vergüenza decir en voz alta.
La mecánica del proceso son las respuestas a preguntas que en las reuniones no se hacen:
- qué entidades existen (solicitud, cliente, oportunidad, devolución, reclamación) y qué distingue a una de otra
- en qué estados puede estar cada una y qué transiciones entre estados están permitidas
- qué no se debe hacer nunca, por muy razonable que parezca en un caso concreto
- qué excepciones existen y por qué señal se reconocen: no «a veces es distinto», sino «si el cliente está en la lista de cuentas clave, la regla es otra»
- de dónde sale la información que no está en el sistema y quién está autorizado a confirmarla
La condición de éxito es un bloque aparte, y casi nunca se escribe:
- qué resultado observable muestra que el paso se hizo correctamente
- quién o qué lo verifica y en qué plazo
- en qué se diferencia «se hizo mal» de «se hizo lo incorrecto», porque son eventos distintos con un coste distinto
La diferencia no es cosmética. Las instrucciones describen una sola ruta y no dicen nada de lo que queda fuera, por eso el agente que se sale de la ruta se queda sin referencias. La descripción de la mecánica, en cambio, marca los límites del campo: dentro de ellos el agente puede elegir su propio camino y, por definición, no puede salirse.
Una herramienta mejor no lo compensa
La reacción natural ante un piloto fallido es buscar un harness más potente: otro framework, una plataforma con memoria, un agente con planificador. Los autores del benchmark también pusieron a prueba esa hipótesis.
Tomaron Prime Agent (Opus 5 dentro del producto Prime Agent), que poco antes había logrado un 95,5% en los juegos públicos de ARC-AGI-3, y lo probaron en los dos niveles más difíciles de DiG-bench. No hubo mejora frente al harness básico con el mismo Opus 5. La conclusión general está formulada con cautela, pero sin ambigüedad: los harness existentes aportan una mejora limitada justamente en la capacidad de descubrimiento.
No conviene estirar este resultado: algo sí descubre el agente por su cuenta. Sin reglas, Gemini aun así ganó 18 juegos, y el modelo más fuerte del conjunto, Opus 5, 50 de 70. Si para cada juego se cuenta el mejor de todos los modelos evaluados, entre todos cubren 57 de 70, pero en los dos niveles superiores solo 9 de 20. Es decir, las reglas implícitas sí se descubren, solo que de forma poco fiable, y los fallos caen justo en los casos difíciles.
Para la implantación, de aquí sale algo muy práctico. Donde las reglas no están escritas, el precio no es la licencia, sino la dispersión de los resultados: el agente resolverá diez solicitudes como corresponde y en la undécima hará algo que nadie esperaba. Y resultará que la regla que rompió de verdad no estaba registrada en ninguna parte, así que, formalmente, tampoco la rompió.
Dónde termina la analogía
El benchmark mide el descubrimiento de reglas mediante la experimentación activa en juegos de texto. Allí el jugador tiene un entorno de pruebas: una jugada fallida no cuesta nada y se pueden hacer cientos de intentos. Los autores, a propósito, no evalúan la eficiencia de los pasos para no penalizar la exploración.
Un proceso de negocio funciona de otra manera. Aquí el experimento del agente es una llamada real a un cliente real, un descuento real y una factura real. No hay entorno de pruebas, y el coste de una hipótesis fallida no es cero.
Por eso las cifras no se pueden trasladar literalmente: el 26% y el 99% son resultados de juegos de texto, no indicadores de la automatización de un equipo de ventas. La analogía funciona en un solo sentido y precisamente como analogía: si un modelo con un número ilimitado de intentos gratuitos ganó por su cuenta 18 juegos de 70, en un entorno donde cada intento cuesta dinero y la relación con el cliente hay todavía menos motivos para contar con que descubra las reglas solo.
Cómo pasar la mecánica de la cabeza al texto
La pregunta «cuéntame cómo lo haces» da como resultado unas instrucciones, es decir, esa misma secuencia de jugadas. La mecánica no se obtiene así de ninguna manera: quien lleva diez años ejecutando un proceso no ve sus propias reglas, porque para esa persona no son reglas, sino la forma en que funciona el mundo.
Lo que funciona es otro tipo de preguntas, sobre los límites y las excepciones:
- «¿Qué pasa si se hace al revés?»: la respuesta «bueno, es que nadie lo hace así» casi siempre esconde una regla no dicha
- «¿Cuándo fue la última vez que te apartaste de las instrucciones y por qué?»: aquí aparecen tanto la excepción como la señal por la que se reconoció
- «¿Qué error comete alguien nuevo en su primera semana?»: es una transición prohibida que no figura en ningún documento
- «¿Cómo sabes que ha quedado bien hecho antes de que llegue el resultado?»: un criterio de éxito que normalmente solo existe como sensación
- «¿Qué revisas antes de pulsar el botón?»: una condición previa oculta sin la cual el paso no tiene sentido
El documento que resulta de una conversación así tiene tres partes: la lista de entidades y sus estados, la lista de transiciones prohibidas con sus motivos y el criterio de éxito con la descripción de quién lo verifica y cómo. Las estrategias, los trucos y los consejos de «cómo hacerlo mejor» no entran aquí: se escriben aparte y para las personas.
Hay una forma sencilla de comprobar si la descripción está completa: dásela a una persona que no conozca el proceso y pídele que nombre una situación en la que el documento no indique qué hacer. Cada situación de esas es exactamente el punto donde el agente se pondrá a adivinar.
Adónde va realmente el presupuesto de implantación
El presupuesto de un piloto suele componerse de integraciones, prompts, pruebas y la suscripción al modelo. El trabajo de sacar a la luz las reglas implícitas no figura en él: o se omite con un «tenemos todo descrito», o se descubre después del lanzamiento, cuando ya cuesta un proyecto detenido.
El volumen de este trabajo se mide en días o semanas, según cuántas excepciones haya acumulado el proceso, y es más honesto incluirlo en el plan que explicar después por qué el piloto no salió del entorno de pruebas. Auspex lo pone primero justamente porque es portable: la mecánica descrita se queda contigo sin importar qué modelo elijas dentro de un año ni si el modelo con el que empezaste sigue siquiera en el mercado.
Este trabajo enlaza con la parte anterior del análisis. En el artículo «El negocio que se actualiza solo» se hablaba de por qué crecer sin contratar choca con la descripción del negocio que vive en la cabeza de los empleados. DiG-bench le pone precio a ese panorama: muestra cuánto cuesta esa misma brecha cuando en el proceso no se pone a una persona, sino a un agente, y por qué no sirve comprar un harness en lugar de la descripción.
Por dónde empezar esta semana
- abre el procedimiento del proceso que piensas darle al agente y busca en él la lista de acciones prohibidas: si solo hay una secuencia de pasos, no tienes una descripción de la mecánica
- encuentra en ese mismo documento la frase que responde a la pregunta «¿en qué se nota que el paso se hizo correctamente?»
- pregúntale a la persona que lleva el proceso cuándo fue la última vez que se apartó de las instrucciones y anota la señal por la que lo decidió
Si después de esta revisión resulta que el proceso se sostiene en la memoria de dos empleados, el problema no es el modelo, y no tiene sentido cambiarlo.
Con esa lista de discrepancias puedes venir a la auditoría de CRM y automatizaciones. En una sola reunión, Auspex revisa cuál de tus procesos está descrito lo suficiente como para dárselo a un agente y cuál hay que pasar primero a texto. La página del servicio está en los enlaces de abajo.
Y un detalle que por lo general no se nota hasta el segundo proyecto: la descripción de la mecánica tiene que vivir en el lugar desde donde la lee el agente, no en una presentación para la dirección. Un documento que está aparte del sistema se desfasa de la realidad en más o menos un trimestre, y entonces tienes dos fuentes de verdad en lugar de una.