La respuesta directa: una demostración exitosa no prueba nada sobre la fiabilidad de un agente de IA, porque la pregunta correcta no es si completó la tarea una vez, sino si la completa correctamente cada vez. En un estudio que Microsoft publicó el 20 de agosto de 2026, el modelo más potente obtuvo un 65,36% cuando cada tarea se ejecutó una sola vez, pero superó los veinte intentos solo en el 25,25% de las tareas. Esa brecha es exactamente la distancia entre un agente que te impresiona en una reunión y un agente al que puedes confiar los datos de tus clientes.

Lo que Microsoft construyó realmente

La herramienta se llama Thinkingbox, un entorno de pruebas de código abierto publicado bajo la licencia MIT en GitHub. La idea es sencilla e ingeniosa: en lugar de conectar las herramientas directamente al agente, las defines como servidores compatibles con MCP, ejecutas el agente dentro de una sesión aislada con su propia base de datos de respaldo y registras la traza completa de ejecución.

Lo esencial está en cómo evalúa. El marco no lee lo que el agente dijo que hizo; inspecciona lo que realmente cambió en la base de datos una vez terminada la tarea. Esa distinción no es un detalle técnico. Los agentes son muy buenos redactando un resumen convincente de un trabajo que nunca ocurrió, y cualquier evaluación basada en la transcripción de la conversación mide la calidad de la prosa, no la calidad de la ejecución.

Sobre ese entorno, el equipo construyó un benchmark llamado Thinkingbox-bench que contiene 507 flujos de trabajo condicionados por políticas en cinco dominios: comercio minorista y comercio electrónico, viajes y hostelería, seguros de automóvil, soporte de TI interno en un neobanco, y soporte de TI y recursos humanos en una consultora. Cada tarea se ejecutó veinte veces con doce modelos, tanto propietarios como de pesos abiertos.

Por qué esa cifra importa al dueño de un negocio

Imagina que encargas a un agente procesar las solicitudes de devolución de tu tienda. Una tasa de éxito del 65% parece aceptable sobre el papel. En la operación significa que un tercio de las solicitudes termina con un resultado erróneo: un reembolso emitido dos veces, un pedido cerrado sin reponer el inventario o una excepción concedida a un cliente al que tu política no se la permite.

Peor aún, los fallos de este estudio no fueron bloqueos evidentes. El artículo describe explícitamente que muchos fallos terminaron limpiamente y siguieron pasos que parecían válidos, mientras que el estado final del sistema seguía siendo incorrecto. Ningún mensaje de error, ninguna interrupción, nada que se encienda en un panel de monitorización. Solo un registro que se lee con normalidad y unos datos que, en silencio, se volvieron incorrectos.

Un fallo que detiene el sistema es molesto, pero visible. Un fallo que completa el flujo y deja tus datos mal es el que realmente te cuesta dinero, porque lo descubres un mes después durante la conciliación.

Esto también explica una fuente habitual de decepción. El piloto se aprueba porque ejecutó la tarea una sola vez con datos limpios. La operación real es la misma tarea miles de veces sobre un estado acumulado y desordenado, y ahí es exactamente donde aparece la diferencia entre el 65% y el 25%.

Qué hacer antes de adoptar cualquier agente

  • Exige ejecuciones repetidas, no una sola demostración. Que tu criterio de aceptación sea veinte ejecuciones consecutivas de la misma tarea con los mismos datos. Un proveedor que se niega te está diciendo algo.
  • Mide el estado de los datos, no el texto de la respuesta. Define de antemano cómo debe quedar el registro en tu base de datos después de la tarea y compara la realidad con eso. No te conformes con leer el propio resumen del agente.
  • Prueba políticas, no solo tareas fáciles. La mayor parte de tu trabajo no es abierto; está sujeto a reglas: plazos de devolución, límites de crédito, excepciones para clientes prioritarios. Un agente que tiene éxito sin restricciones puede derrumbarse ante la primera condición real.
  • Construye el conjunto de pruebas con tus propios casos. Toma veinte casos reales de los últimos meses, incluidos los raros que confundieron a tu personal, y conviértelos en una batería fija que ejecutes con cualquier modelo antes de adoptarlo y después de cada actualización.
  • Concede autoridad por etapas. Empieza con un agente que propone pero no ejecuta, luego déjale realizar operaciones de bajo impacto y después amplía su alcance a medida que se acumule un historial real de mediciones. La autoridad debe ganarse con datos, no con impresiones.

Cómo lo abordamos en Origami

Cuando construimos un sistema que incluye un agente de IA, tratamos al agente como cualquier otro componente de software: recibe una batería de pruebas automatizadas, comprobaciones de verificación que inspeccionan el estado de la base de datos después de cada operación y un punto claro de traspaso a una persona cuando se cruza un umbral de confianza. El modelo en sí sigue siendo un ajuste intercambiable y no algo soldado al código, porque el mejor modelo de hoy puede no ser el mejor dentro de tres meses.

La conclusión que vale la pena extraer de este estudio no es que los agentes sean inservibles. Es que la vara con la que los medíamos era la equivocada. Los agentes actuales son herramientas potentes dentro de un alcance bien definido y medido de forma continua, y muy débiles cuando se les entrega un proceso sensible por la fuerza de una demostración convincente. La diferencia no está en el modelo; está en la disciplina de ingeniería que lo rodea.

Fuentes