¿El benchmark de agentes de IA muestra que el harness cambia el costo?

Cuando el modelo es el mismo y el resultado cambia, la variable está fuera del modelo

Un benchmark publicado por la Ora en agosto de 2026 ejecutó la misma tarea, con los mismos modelos, en dos harnesses de agente y midió diferencias de 7% en pasos, 2x en éxito nativo y 9% en endpoints válidos. Inmediatamente después, la corrección de un defecto de cache de prompt redujo el costo total en cerca de 15%. El benchmark de agentes de IA que opera la Ora existe para responder exactamente esta pregunta: cuánto del costo y del éxito de tu agente depende del ambiente que ejecuta el modelo, y no del modelo en sí. La cuenta cambia. Para las empresas que pagan por inferencia, la respuesta cambia lo que vale la pena medir.

Contexto: la Ora mide si la web está lista para agentes

La Ora es una plataforma que ejecuta agentes contra sitios reales de clientes con la tarea de registrarse en un producto, integrarse con él y pagarlo, y registra el costo, la latencia y el número de pasos de cada jornada. La estimación de la propia empresa es que 99% de la web no está lista para este tipo de agente, un número que la Ora afirma, no una medición independiente.

Para la empresa que compra inferencia, el efecto es directo. Dos equipos pueden elegir el mismo modelo, en el mismo proveedor, con el mismo precio de token publicado, y terminar el mes con costos por tarea muy diferentes, porque la ejecución alrededor del modelo no es igual. La factura no discrimina esa diferencia: muestra tokens consumidos y nada más. Es el mismo patrón ya discutido cuando el costo real de una aplicación de IA va más allá del precio del token, y el caso de la Ora le da números atribuibles.

El detalle que le interesa al comprador B2B es el diseño de la prueba. Un agente tiene dos partes: el modelo, que razona, y el harness, el software que proporciona las herramientas al modelo y lo conduce de etapa en etapa. Cuando un agente falla en un flujo de registro, la diferencia puede estar en el modelo, en el harness o en el sitio, y sin instrumentación el resultado es una nota sin causa atribuida. Por eso la Ora ejecuta un runtime separado para cada harness y registra el trazo de cada etapa. Sin trazo, no hay causa.

Cómo funciona el benchmark de agentes de IA de la Ora

El caso documentado comparó dos harnesses en cientos de jornadas reales, en múltiples dominios, con una tarea idéntica para ambos: integrarse con un producto. Los dos lados ejecutaron los mismos modelos. Este benchmark de harness mantiene el modelo fijo, y eso es lo que le da valor a la prueba: cualquier diferencia observada proviene del harness y de la infraestructura a su alrededor, no de un cambio de modelo.

Cada jornada registra tres dimensiones que la Ora publica: pasos hasta concluir la tarea, éxito nativo en el sitio del cliente y calidad de los endpoints encontrados. La instrumentación es lo suficientemente granular para mostrar, cuando un agente se atasca en un flujo de registro, qué etapa se atascó y qué intentó el agente.

Resultados: el harness cambia la cuenta con el modelo fijo

Los números publicados por la Ora, siempre atribuidos a su prueba:

Ninguno de estos números describe un modelo mejor. Los modelos eran los mismos. Los números describen ejecución.

El último número de la tabla merece atención separada. Durante las pruebas, una ronda expuso un problema de cache de prompt. El equipo del harness corrigió el defecto y la ronda siguiente midió cerca de 15% menos costo total. La fuente no publica los controles de esa ronda posterior: lo que documenta es la secuencia de defecto expuesto por la prueba, corrección aplicada y costo total menor en la medición siguiente.

Hay un límite honesto que el propio caso impone: los números comparan dos harnesses en jornadas de integración en sitios de clientes. Los modelos eran los mismos. Los números describen ejecución: cuántos pasos gastó el harness para llegar al objetivo, con qué frecuencia resolvía la tarea en el sitio del cliente sin recurrir a la búsqueda web y qué tan aprovechables eran los endpoints que encontraba en el camino. No dicen que un harness sea universalmente mejor que otro, ni que la diferencia observada se replicaría en otros tipos de tarea. Lo que los números transfieren es el método, no el marcador. En un presupuesto de inferencia, cada una de estas dimensiones se convierte en dinero: los pasos son llamadas, el fallback es latencia y costo extra, el endpoint inválido es retry facturado.

Lo que el caso enseña sobre medir agentes

1. Compara con el modelo fijo. Las diferencias de pasos, éxito y costo entre configuraciones solo significan algo cuando el modelo es el mismo en ambos lados. Cambiar modelo y harness al mismo tiempo deja el resultado sin causa.
2. Mide por jornada, no por token. El costo relevante de los agentes de IA es el de concluir la tarea, que incluye retries facturados, fallbacks y etapas desperdiciadas, no el precio del token multiplicado por el volumen.
3. Instrumenta antes de optimizar. La ganancia de 15% de costo solo apareció después de que el trazo de ejecución expuso el problema de cache de prompt. Sin trazo, el desperdicio sigue embebido en la factura.
4. El cache de prompt es un ítem de auditoría, no una configuración. Se degrada silenciosamente y el síntoma aparece como costo, no como error.
5. El éxito tiene capas. Concluir la tarea en el sitio del cliente sin caer en la búsqueda web es un resultado cualitativamente mejor que concluir con fallback, y ambos suman "éxito" en dashboards ingenuos.

Cómo aplicar esto en tu operación

Para quien enruta modelos en producción, el caso refuerza una disciplina que ya aplicamos en el costo por tarea en el enrutamiento de modelos: la unidad de decisión es la tarea concluida, con el trazo que muestra dónde ocurrió el costo. El mismo razonamiento vale para medir el rendimiento de los proveedores de LLM, porque la variación entre endpoints con el mismo modelo ya fue documentada en el mismo modelo varía por endpoint.

Tres pasos transferibles, en el orden del caso:

1. Fija el modelo y varía un factor a la vez: harness, endpoint o política de cache.
2. Registra el trazo de cada jornada. Pasos, latencia, costo y tipo de éxito, en el formato que el trazo de llamada LLM permite auditar. El trazo va primero.
3. Audita el cache de prompt antes de negociar precio o cambiar de modelo, porque es una corrección directa y fácil de ignorar.

Vale registrar también la diferencia entre éxito nativo y fallback, porque aparece en producción de forma silenciosa. Un agente que termina la tarea buscando en la web concluyó, en el reporte. Falló en lo que el cliente contrató: ejecutar en su propio sistema. El trazo que separa ambos resultados es el mismo trazo de llamada LLM que permite auditar request por request, y sin él el éxito agregado del dashboard esconde la mitad de la historia.

Quien ya calcula el costo real de una aplicación de IA más allá del precio del token reconoce el patrón: el costo que derriba el margen rara vez está en el número de marketing del modelo.

Preguntas frecuentes

¿Qué es el harness de un agente de IA? Es el software que proporciona herramientas al modelo y lo conduce de etapa en etapa hasta concluir la tarea. En el benchmark de la Ora, cada harness ejecutó con el mismo modelo, lo que aisló la diferencia de resultado en el harness y en la infraestructura.

¿El benchmark de agentes de IA de la Ora es independiente? Es una plataforma comercial de la Ora, que vende justamente esa medición, y los números citados aquí provienen del caso publicado por la empresa el 2026-08-21. La estimación de 99% de la web no preparada para agentes es de la propia Ora, no una medición independiente.

¿Cómo el cache de prompt redujo el costo en 15%? Una ronda de pruebas expuso un problema de cache de prompt. Tras la corrección por el equipo del harness, la ronda siguiente midió cerca de 15% menos costo total, según la Ora. La fuente no detalla el mecanismo interno del defecto ni los controles de la ronda de medición.

¿Qué debo medir primero en el costo de mi agente? Comienza por el trazo por jornada: pasos, latencia, costo y si la tarea concluyó en el objetivo o con fallback. Con el trazo en mano, audita el cache de prompt, de corrección directa, y solo después considera cambiar de modelo.

¿Cambiar de modelo resuelve un problema de ejecución? No necesariamente. El caso de la Ora muestra diferencias de pasos, éxito y costo con el modelo fijo, lo que significa que parte del costo puede estar en el harness, en el cache o en la infraestructura. Cambiar de modelo sin instrumentación mueve la variable sin identificarla.

Referencias

• Cómo la Ora evalúa agentes de IA, caso publicado el 2026-08-21

Por dónde empezar

El trazo va antes de la decisión de proveedor. Antes de cualquier cambio de modelo o renegociación de contrato, produce el trazo por jornada del tráfico actual: pasos, latencia, costo y tipo de éxito, con el cache de prompt auditado. El caso de la Ora sugiere el orden. Primero la instrumentación, después la corrección de ejecución, y solo entonces la decisión de proveedor. El Nexforce Router actúa en esa capa con enrutamiento, logs y rastreo por llamada, manteniendo la medición consistente cuando los modelos y endpoints cambian por detrás de la aplicación.