Elegir métricas para evaluar agentes B2B antes del piloto

Una empresa anuncia que va a pilotear agentes de IA y, en la misma semana, cuatro personas abren la discusión sobre qué modelo usar, qué framework de orquestación, qué runtime. Nadie formula ni una sola vez la pregunta que importa: ¿qué significa, para esta operación, un agente "funcionando"? Esa pregunta decide el piloto. Y es la que casi nunca se hace.

La primera decisión del piloto no es técnica

La primera decisión de un piloto de agentes B2B es elegir qué medir, no qué framework ni qué modelo. Quien salta directo a la elección de tecnología está respondiendo una pregunta que todavía no fue formulada, y lo descubre al final del trimestre, con un agente corriendo y sin ninguna regla para decir si valió la pena. El costo del piloto no es el token. Es la prueba que termina sin un número con el cual estar de acuerdo o en desacuerdo.

Quienes sienten ese costo primero son tres personas: el líder de operaciones, que debe justificar la cabeza sumada o la cabeza que nunca se sumó; el responsable de RevOps, que hereda el agente sin saber contra qué meta corre; y el líder de tecnología, que se vuelve dueño de un sistema cuyo "éxito" nadie definió. Los tres juntos son la razón por la que la mitad de los pilotos mueren en silencio. No porque el agente falló. Porque no existía un acuerdo previo sobre qué contaría como éxito.

Hay un número que ilustra la asimetría: los benchmarks públicos de agentes abundan, pero el informe que le importa al CFO, el que conecta el agente con el resultado del negocio, es una regla que la propia operación tiene que producir. No llega hecha de ningún proveedor. Esa brecha es todo el asunto de este post, y el lector que la ignora pilotea a ciegas.

La trampa más elegante es la siguiente. El equipo técnico elige métricas que sabe medir bien: latencia, costo por token, tasa de tareas completadas. El equipo de negocio elige métricas que suenan bien en reunión: "más eficiencia", "menos retrabajo". Los dos conjuntos no dialogan entre sí, y el piloto termina con una lista de números que todos reconocen como verdaderos y ninguno reconoce como decisivos. Ese es el punto donde el proyecto empieza a pudrirse sin arrojar ningún error.

Qué prueba realmente un benchmark de dominio

Un benchmark de dominio prueba que un agente puede transformar una tarea real y privada en un entregable correcto dentro de un entorno controlado, corregido criterio por criterio por un juez LLM. Esa es una prueba importante, y es todo lo que es. No dice nada sobre lo que pasa cuando ese agente toca la operación real, con dato sucio, excepción no documentada y plazo real.

La clase de evaluación tiene una forma específica. El agente lee documentos de caso en un entorno sandbox, ejecuta una tarea de múltiples pasos y produce un entregable real: un memorando, un disclosure schedule, un resumen de declaración. No es respuesta de trivia, no es un solo turno de chat. Es trabajo compuesto, evaluado de punta a punta.

Cita el ejemplo concreto. El Harvey LAB-AA, la implementación que Artificial Analysis hace del Legal Agent Benchmark de Harvey, corre agentes contra 120 tareas privadas de práctica jurídica distribuidas en 24 áreas. Cada tarea se corrige criterio por criterio por un único juez LLM, una rúbrica que califica cada criterio por separado en lugar de dar una nota única y compasiva. Lo que se mide allí es capacidad: la distancia entre el entregable producido y el estándar esperado para ese criterio específico.

Lo que reúne la lista de evaluaciones de Artificial Analysis es exactamente esa familia: LAB-AA, AA-Briefcase, AA-Analyst, GDPval-AA v2, Terminal-Bench. Benchmarks de dominio que prueban que los agentes producen entregables reales, de múltiples pasos, en sandbox. Y se detienen allí, en el borde del sandbox.

Aquí está la confusión que cuesta caro. Una organización lee "el agente ganó un benchmark de dominio" y lo traduce como "el agente va a entregar valor en mi flujo". La traducción es incorrecta. El benchmark mide si la tarea se completó dentro de un criterio acordado. Deliberadamente no mide si completar esa tarea de esa manera vale dinero para alguien. Dos cosas distintas, y la segunda es la que paga el proyecto.

Por qué tarea completada no es valor entregado

Tarea completada y valor entregado no son lo mismo, y la distancia entre ambas tiene un nombre: la brecha benchmark-to-production. Un benchmark mantiene el dato limpio, el entorno controlado y el criterio de corrección fijado por un juez. La producción arroja dato sucio, sistema parcialmente integrado y un criterio de éxito que cambia según la semana. La brecha no es un detalle de implementación. Es el agujero donde caen los pilotos.

El benchmark asume tres condiciones que la operación real rompe una a una. Primera, input limpio: el documento que el agente lee en el benchmark está completo y bien etiquetado. En producción, el mismo documento llega a medias, en veinte formatos, con un adjunto que nadie pidió. Segunda, alcance conocido: cada tarea del benchmark tiene inicio y fin definidos. En producción, el trabajo llega enredado, con dependencias que nadie listó. Tercera, criterio estable: el juez LLM usa la misma rúbrica en todas las tareas. En producción, lo que es "bueno" cambia cuando cambia la meta del trimestre.

El ejemplo lo vuelve concreto. Un agente jurídico evaluado y validado para redactar memorandos puede puntuar alto en LAB-AA porque el benchmark le entrega un conjunto de documentos limpios y un pedido bien delimitado. En un estudio real, el mismo agente recibe un correo con diez adjuntos, un cliente que cambió de idea a mitad de camino y un socio que quiere la respuesta "con más contexto". La capacidad está ahí, probada por el benchmark. El valor, no. Depende de factores que el benchmark nunca prometió cubrir.

Hay un segundo costo escondido en esa confusión, y es de naturaleza contable. Cuando la regla del piloto hereda la regla del benchmark, se mide el promedio de acierto de la tarea y se lo llama retorno. Lo que queda afuera es la parte de la operación que el agente no tocó, la que necesitó arreglo humano, la que generó retrabajo silencioso. Exactamente la parte que decide si el agente ahorra una cabeza o apenas la mueve de lugar.

Por eso la primera regla sola, la de capacidad, produce un número que todos elogian y nadie usa para decidir nada. Responde "¿el agente sabe hacerlo?". La pregunta que hace el CFO es otra: "¿cuánto gana la empresa por semana con el agente haciéndolo?". Las dos exigen instrumentos distintos, armados en momentos distintos, y casi nadie separa los dos.

Cómo armar la regla antes del piloto

Armar la regla antes del piloto significa apilar dos capas distintas de medición y, a continuación, medir la distancia entre ellas. La primera capa es la capacidad del dominio, verificada por un benchmark del tipo que documenta Artificial Analysis. La segunda es el valor de negocio de la propia operación, definido por la métrica que importa para esa rutina específica. El piloto solo empieza cuando ambas existen y la brecha entre ellas es conocida.

El orden importa más que el contenido de cada capa. Quien arma la regla de valor después de correr el agente está midiendo lo que ya pasó, sin haber establecido antes contra qué. Es como elegir la meta de ventas al final del mes: toda conclusión será retrospectiva y ninguna decisión habrá quedado más fácil. La regla debe existir antes, y quedar escrita en algún lugar que el equipo pueda disputar.

La tabla de abajo dibuja la separación entre los dos tipos de métrica, porque es la frontera que decide casi todo:

La secuencia de armado tiene cuatro pasos, y ninguno es opcional. Primero, establece la línea base de capacidad usando un benchmark de dominio relevante para el área. Segundo, escribe la regla de valor de negocio de tu propia operación: tiempo de ciclo, retrabajo, costo por entrega, tiempo hasta respuesta. Tercero, mide la brecha entre las dos capas: donde el agente es capaz pero el flujo real lo derriba, allí es donde vive el proyecto de integración. Cuarto, fija los criterios de aceptación del piloto sobre esa brecha, con número, dueño y fecha.

El tercer paso es el que separa un piloto maduro de una prueba de curiosidad. Capacidad alta y valor bajo, en el mismo agente, indican que el problema está en la integración y no en la tecnología: el agente sabe, solo no llega al lugar donde sabe. Capacidad baja y valor alto indican que el problema está en el agente, y ningún ajuste de proceso lo va a salvar. Sin medir las dos capas, el equipo confunde los dos diagnósticos y arregla el lado equivocado.

Es en ese dibujo, y no en ningún número de leaderboard, donde entra Nexforce Agents. La regla del piloto se define antes de cualquier ejecución, y la ejecución sucede de forma sandbox y rastreable, vía Nexforce Work y Nexforce Code. Lo que el benchmark documenta como capacidad, Nexforce Agents lo deja correr dentro de la operación con un registro de lo que pasó en cada etapa, para que la brecha entre las dos capas aparezca como dato y no como sospecha.

El contraargumento más fuerte

El contrapunto más fuerte es simple: alcanzan los benchmarks, porque el valor de negocio es demasiado complicado de medir con rigor, así que el mejor uso del tiempo es correr el agente y ver qué pasa. Es un argumento honesto, defendido por gente seria, y tiene un atractivo real cuando el trimestre está ajustado y nadie quiere frenar el proyecto para dibujar una regla. Se cae en una cuenta que la propia propuesta esconde.

El razonamiento detrás es: medir capacidad es barato, medir valor es caro, luego medir solo capacidad es el camino racional. La falla está en la premisa de que no medir valor cuesta cero. No medir valor posterga el costo al final del piloto, cuando la decisión de escalar, mantener o matar el agente debe tomarse en base a un número que no existe. El costo no desapareció. Fue empujado al punto donde más duele.

Hay una segunda capa en el contraargumento, y es la más seductora. "Las grandes empresas decidieron en base al benchmark y funcionó." Eso confunde correlación con quema de capital. Una organización con presupuesto holgado puede pilotear a ciegas y sobrevivir, porque el error se amortiza con el resto de la operación. La empresa promedio que corre agentes B2B no tiene ese colchón, y es para ella que la regla importa. Para quien tiene dinero de sobra, cualquier metodología de evaluación parece burocracia; para quien no, es lo que evita que la prueba se vuelva pérdida.

La respuesta definitiva al contraargumento es empírica, y ya se dijo aquí: la brecha entre capacidad y valor no describe una dificultad de medición, describe el propio trabajo de integrar el agente a la operación. Quien se niega a medir la brecha no está ahorrándose el esfuerzo de evaluar. Está eligiendo no saber dónde va a fallar el agente, y descubrirlo de la peor forma, con el sistema en producción y el resultado en el resultado del trimestre.

Qué cambia para quien adopta agentes hoy

La creencia que debe cambiar es una sola: dejar de pilotear a ciegas. Quien adopta agentes hoy, o planea adoptarlos, debe dejar de empezar la conversación por la tecnología y empezar por la regla. El framework y el modelo vienen después, y su elección se vuelve obviamente más fácil cuando existe un criterio de éxito ya escrito que ambos deben satisfacer. Un agente solo es una decisión de producto cuando hay una métrica de valor junto a él; sin ella, es experimento.

El cambio tiene una consecuencia organizacional concreta e incómoda. Alguien del lado del negocio necesita sentarse con el lado técnico antes del primer token del piloto. No después. Y debe salir de esa reunión con la regla de valor escrita, con dueño y plazo. La mayoría de los pilotos se salta esa reunión porque es la parte aburrida, la que exige decir, en números, qué significa "funcionó". Es justamente la parte que el benchmark no puede hacer por nadie.

Mirando lo que ya está publicado por aquí, la frontera se vuelve más nítida. El gateway de modelos en escala y el costo operativo de un gateway de IA en producción tratan de la infraestructura sobre la que corren los agentes; la economía por ruteo de modelos trata del costo por token. Ninguno es la regla de calidad y valor de un agente de trabajo. Esa regla es otra capa, y es el territorio que ocupa este post.

El punto de aterrizaje es honesto. El benchmark de dominio responde si el agente sabe hacerlo; la regla de negocio responde si eso vale dinero en tu operación. Las dos deben existir antes del piloto, y la distancia entre ellas es el mapa del trabajo de integración. Un equipo que arma las dos capas y mide la brecha está piloteando con los ojos abiertos. El resto está apostando, y llamando estrategia a la apuesta.

FAQ

¿Cuál es la diferencia entre benchmark de dominio y métrica de valor de negocio?

El benchmark de dominio mide si el agente completó una tarea real contra un criterio acordado, en entorno sandbox y con dato limpio. La métrica de valor de negocio mide si tener ese trabajo hecho generó resultado medible en la operación real, como menos tiempo de ciclo o menos retrabajo.

¿Necesito medir la brecha benchmark-to-production en mi piloto?

Sí. La brecha entre la capacidad probada por el benchmark y el valor medido en la operación es el propio mapa del trabajo de integración. Sin ella, el equipo no distingue un problema de integración de un problema de agente.

¿Los benchmarks de agente como LAB-AA sirven para elegir mi agente?

Sirven para calibrar la capacidad técnica antes de que el agente toque la operación. Lo que no hacen es decir cuánto valor entrega ese agente en tu flujo específico, que es la pregunta que decide el piloto.

¿Cuándo debo definir la regla, antes o después de correr el agente?

Antes. Definir la regla de valor después de correr el agente convierte toda conclusión en retrospectiva, sin un criterio previo contra el cual decidir. La regla escrita con dueño y plazo debe existir antes del primer token del piloto.

¿Nexforce Agents ayuda a medir valor o solo a ejecutar?

Nexforce Agents es donde la regla definida antes del piloto se ejecuta de forma sandbox y rastreable, vía Nexforce Work y Nexforce Code. La medición de valor sigue siendo una regla que la propia operación debe producir.

Referências e Leitura Complementar

• Artificial Analysis: evaluaciones de agentes: reúne benchmarks de dominio de múltiples pasos, incluido el Harvey LAB-AA (Legal Agent Benchmark), con tareas privadas corregidas criterio por criterio por un juez LLM.
• Nexforce Agents: la unidad de agentes de IA para operaciones B2B, con Nexforce Work y Nexforce Code.
• Model Router en escala: la infraestructura de modelos sobre la que corren los agentes.
• El costo operativo de un gateway de IA en producción: el costo y la latencia de la capa de gateway en producción.
• Un modelo más barato no es un modelo más barato: la economía por ruteo de modelos.

La regla es el piloto

La pregunta que abre este post, "¿qué significa un agente funcionando?", no tiene respuesta técnica. Tiene respuesta de negocio, y debe escribirse antes de cualquier framework. La decisión de medir capacidad y valor en dos capas, y de mirar la distancia entre ambas, es la primera decisión de cualquier piloto serio. Quien la toma temprano gana un piloto que termina con un número con el cual estar de acuerdo o en desacuerdo. Quien no la toma termina con un agente corriendo y una pregunta sin respuesta, y entonces el proyecto muere despacio, sin arrojar nunca un error.