Evaluación de agentes de IA: medir más allá de la respuesta final

Un manual de evaluación diría que hay que revisar la nota del examen, y todo agente sacaría diez. La pregunta que ningún evaluador de respuestas finales hace es cómo llegó el agente hasta ahí: si verificó el pedido antes de reembolsar, si llamó a la herramienta que tenía derecho a llamar. El desenlace correcto disfraza el camino equivocado, y el comprador sénior de agentes B2B, el CTO o el director de producto que pone el sistema en producción necesita una regla que mida lo que pasó en el medio del camino, no solo lo que llegó al final.

Un agente puede acertar la respuesta y equivocarse en el camino

Un agente acierta la respuesta final y sigue la operación por un camino que ningún evaluador de desenlaces ve: llamar a la herramienta equivocada, omitir la llamada que validaría el paso, insistir en un error que nunca iba a corregir. La industria ya señala hacia dónde va la evaluación. En agosto de 2026, una de las principales capas de agregación de modelos publicó una metodología que pide evaluar al agente por los prompts que recibe, por las herramientas que llama y por la respuesta que entrega en cada etapa, convirtiendo la evaluación en una verificación de recorrido y no en un boletín de desenlace. La nota de diez no es un agente seguro.

Quien siente el costo de la regla ciega no es el equipo que escribe el prompt. Es el dueño del proceso que descubre, en un lunes de pico, que el agente de soporte venía autorizando lo que nunca debía autorizar, sin que la nota de respuesta final bajara ni una milésima por eso. Para el CTO y el director de producto que lanzan al agente contra la operación real, lo que está en juego no es el promedio de acierto. Es el incidente que una evaluación solo de respuestas no evita porque ni siquiera llega a mirarlo.

Qué se arriesga al poner la nota solo en la respuesta

Poner la nota solo en la respuesta final arriesga el tipo de falla que no aparece como respuesta equivocada: la violación de permisos, la llamada indebida a una herramienta con acceso sensible, la ejecución costosa que nadie autorizó. Una evaluación de respuesta final captura el desenlace erróneo y es estructuralmente ciega a la falla que es robada o peligrosa. Cuando un agente emitía reembolsos sin verificar si ese pedido tenía derecho a ellos, el desenlace, el correo de confirmación de la reversión, salía correcto y legítimo; fue la clase de falla, el proceso de autorización de un agente de soporte que emitía un reembolso sin revisar el pedido, lo que ninguna nota de respuesta podía ver. En un entorno B2B, el mismo patrón se repite con el acceso a datos del cliente, con una orden de compra, con un pago. El número ciego cuesta caro.

Lo que la regla ciega no ve es caro por una razón contable simple. El costo de revisar el camino antes de la producción es una línea pequeña y medible, en horas de quien diseña la evaluación. El costo del camino no inspeccionado es un incidente de producción, una violación de guardrails, un retrabajo sobre una ejecución que nadie autorizó, y aparece en el momento en que el agente ya corre a escala, con el flujo dependiendo de él. Es por ese costo diferido que la decisión de escalar o abortar un piloto, la que la lectura de ROI antes de escalar el piloto resuelve con la regla financiera, encuentra al proceso antes de tocar la planilla. Aplazar la medición del camino no borra el costo. Lo transfiere al trimestre en que duele más, cuando la salida es apagar el agente o pagar la cuenta del incidente.

Claim 1: la ruta de herramientas es donde la respuesta correcta esconde la falla

La ruta de herramientas, la secuencia de llamadas de herramienta que el agente hizo y, con la misma importancia, las que evitó al no hacerlas, es el primer lugar donde la respuesta final miente. Una evaluación honesta de un agente debe registrar la llamada hecha y la llamada que debería haberse hecho, porque la falla de proceso suele estar no en lo que el agente ejecutó mal, sino en la llamada que omitió por completo.

Una evaluación que solo puntúa la respuesta final pasa por alto el ejemplo real más barato: el agente de soporte que emite un reembolso sin verificar el pedido. La respuesta final, la reversión confirmada, es correcta, y el evaluador de respuestas le da un diez. Solo una aserción que exija la llamada lookup_order antes de la llamada de reembolso prueba la falla, porque es la ausencia de la llamada lookup_order en la ruta de herramientas, no la presencia de una respuesta equivocada, lo que revela que el agente autorizó lo que no debía.

La llamada evitada tiene peso propio y suele ser la más difícil de evaluar, porque exige especificar lo que el agente no debería hacer. No basta saber que llamó a la herramienta correcta. El comprador debe declarar qué herramientas están fuera del alcance de ese agente y verificar, ejecución por ejecución, que no las tocó. El vocabulario del perímetro está hoy estandarizado por los protocolos de conexión; el protocolo MCP y el Gateway de Agentes describen lo que conecta al agente con las herramientas externas y lo que tiene derecho a llamar, que es la frontera donde la llamada evitada se vuelve observable y auditable. Es sobre ese derecho, y no sobre el precio de un token, sobre lo que la ruta de herramientas debe hablar. La llamada omitida es la falla.

Claim 2: un cambio de puntaje debe ser atribuible, o el KPI miente

Sin fijar la prueba, un cambio de puntaje no dice qué cambió. Si el agente mejoró del 10% en una ejecución al 11% en la siguiente, el responsable debe poder decir a qué se atribuye la diferencia, si al modelo que subió, al turno de prompt previo a la respuesta, al harness que empezó a tolerar un formato nuevo o al orden de la llamada de herramienta. Un KPI sin atribución es un número que todos elogian y nadie puede reproducir ni explicar al día siguiente. Reproducir es la prueba del número.

El harness es el aparato de prueba que sostiene al agente mientras corre, y su estabilidad es una condición previa de cualquier lectura. Cuando el harness cambia junto con la ejecución, el evaluador no sabe si el mérito es del agente o de la plantilla de corrección. La frase que separa una evaluación de ingeniería de un dashboard decorativo es corta: fija el harness antes de fijar al agente. Primero se congela el entorno, la versión del harness, el conjunto de casos, el punto de corte, y solo entonces la variación del puntaje pasa a ser atribuible a lo que se cambió a propósito.

Las dos ambiciones de la evaluación, lo que verifica hoy y lo que pasaría a verificar, quedan claras en un contraste directo del alcance:

Mientras la evaluación de respuestas entrega un veredicto sobre el desenlace, la evaluación de recorrido entrega una atribución. Es la diferencia entre saber que la nota subió y saber por qué subió, y solo la segunda le permite a un equipo decidir con confianza qué sube a producción.

Claim 3: la falla, la autocorrección y la recuperación son señal

El comportamiento de falla de un agente dice más de él que la tasa de acierto. Un agente que llama a la herramienta equivocada, percibe el error, corrige el paso y sigue la ejecución es un agente de una naturaleza. Un agente que erra la llamada y repite el mismo camino hasta generar retrabajo o chocar con un límite es otro, y los dos pueden entregar la misma respuesta final al terminar. Evaluar solo el acierto borra exactamente la diferencia entre ellos, que es la diferencia entre un sistema que se recupera y otro que exige socorro constante.

Dos agentes de procesamiento de pedidos yerran la llamada que actualizaría el estado de un artículo el mismo día. Uno detecta la desviación, revierte el paso, llama a la herramienta correcta y cierra la tarea con el registro correcto. El otro insiste, repite la llamada equivocada tres veces, revienta un límite de intentos y deja la tarea a medias. La evaluación de respuesta final ve a los dos como éxito, porque ambos terminaron con el mensaje de cierre. La evaluación que mide la falla, la autocorrección y la recuperación separa a los dos con precisión: la firma de cada ejecución está en los turnos intermedios, no en la última línea.

El costo de esa separación aparece en la operación real, no en la prueba. El agente que se autocorrige consume casi cero horas de retrabajo y sobrevive a excepciones no documentadas. El que insiste en el error se vuelve un generador silencioso de trabajo humano de reparación, exactamente el retrabajo que la regla de autonomía y decisión de agentes en la empresa necesita considerar cuando define el límite en que la autonomía exige supervisión verificable. Un agente que solo acierta cuando está supervisado no es autónomo, es un prompt con una aprobación humana pegada, y el comportamiento de falla es lo que revela en cuál de los dos apostó la empresa. Supervisión no es autonomía.

Claim 4: la evaluación es una prueba de regresión en CI, no un benchmark descartable

La regla de la respuesta final tiene el ADN de un benchmark de investigador: se corre una vez, se registra un número, se archiva. La evaluación que funciona en producción tiene el ADN de una prueba de regresión: cada bug se convierte en una aserción cubierta, entra en la suite y pasa a correr en cada versión nueva del agente, bloqueando la regresión antes de que llegue a la operación. Es la diferencia entre medir y vigilar, y es la segunda la que protege una carga de producción con el tiempo. Medir una vez no vigila nada.

Un bug documentado se vuelve un test porcentual igual que un bug de código común se vuelve un test unitario. Después de que el agente de soporte emite un reembolso sin verificar, la corrección real no es solo cambiar el prompt y esperar. Es escribir la aserción que exija la llamada lookup_order en la ruta de herramientas y dejarla para siempre en la suite. Desde allí, cualquier release que reintroduzca el camino sin verificación falla en la puerta, antes de tocar al cliente, y el mismo test vuelve a correr automáticamente cuando un modelo nuevo sube a la base del agente, porque un modelo mejor puede traer un peor camino.

Contra la intuición de que evaluar así cuesta demasiado para el día a día: correr la suite de regresión toma minutos, corre sin un humano en el flujo y converge al costo de una suite de tests tradicional después de unas semanas de bugs que se vuelven cobertura. El costo real del benchmark descartable no está en el momento en que corre, sino en el hueco que deja en el medio, cada release entre el correr-y-archivar esconde cuántas regresiones atravesaron al agente sin un test que las atrapara. Para el equipo que pone al agente en producción, la evaluación como prueba de regresión deja de ser una campaña y se vuelve parte del costo normal de mantener software, y es también donde se conecta con un runtime agéntico que los desarrolladores ya usan en CI, con Nexforce Code dando la contraparte de ejecución headless para correr la suite en cada release.

El contraargumento más fuerte contra evaluar el camino

El contrapunto más fuerte es que los benchmarks y los puntajes de respuesta bastan, porque evaluar el camino es demasiado caro y es un detalle de ingeniería que no cambia la decisión del negocio. Es un argumento serio, defendido por gente experimentada, y tiene un atractivo real cuando el trimestre aprieta. Cae en una premisa que la propia propuesta esconde: la de que no evaluar el camino cuesta cero.

El razonamiento detrás es de escala y de simplicidad. El benchmark es barato y corre en horas, y el puntaje de respuesta responde en línea lo que el líder quiere oír. Evaluar la ruta de herramientas, los permisos, la recuperación y la regresión parece un proyecto que atrasa el piloto. La falla está en confundir lo que es caro de implementar con lo que es caro de ignorar. Confundir los dos cuesta producción. El costo del camino no inspeccionado no aparece en la línea del presupuesto de la evaluación; aparece como incidente de producción, como violación de permisos, como ejecución no autorizada que sale del workspace del agente, exactamente el peor momento para descubrirlo, cuando la operación ya depende del sistema.

Lo que el argumento del "detalle de ingeniería" olvida es que la frontera de permisos no es una sutileza técnica, es la definición operacional de la confianza. Definir qué herramientas puede llamar un agente, quién aprueba cada ejecución y cómo se recupera de un error es decidir cuánto de la operación toca sin un humano. Es sobre ese límite, y sobre cómo una guardia verificable impide que el agente cruce el perímetro que se le da, que trata la discusión de contención de agentes en runtime. Llamarlo un detalle es decir que la cadena de autorización de la empresa es un detalle, y ningún CTO lo repetiría en voz alta sobre un pago.

Qué cambia y dónde se vuelve observable el camino

Lo que cambia cuando la evaluación mira el camino es que el cumplimiento deja de ser una esperanza y se vuelve una propiedad verificada de la ejecución. El test de respuesta pregunta si la respuesta está bien. La evaluación de recorrido pregunta si el agente tenía derecho a transitar ese camino, si tocó solo las herramientas permitidas, si se recuperó de los errores y si el cambio de comportamiento entre versiones fue intencional. La tabla de abajo separa qué cubre cada regla antes de la producción, porque esa frontera es lo que decide el riesgo que asume la empresa:

La lectura honesta de la tabla es que la evaluación de respuesta no es inútil, es incompleta en la dimensión exacta donde la operación corre peligro. Completar esa dimensión es una responsabilidad del comprador antes de la producción, no una cortesía del proveedor del agente, y tres pasos la hacen ejecutable. Solo el camino aporta esa prueba.

1. Declarar el permiso de cada agente por escrito, diciendo qué herramientas puede llamar y quién aprueba qué.
2. Convertir cada falla documentada en una aserción cubierta que permanezca en la suite de regresión.
3. Correr esa suite en cada release y siempre que un modelo nuevo suba a la base, tratando el camino violado como un bloqueo y no como una alerta.

Es en ese diseño, y no en ningún número de leaderboard, donde la tarea de evaluar el camino aterriza en Nexforce Agents. La capa de ejecución del agente en el workspace, donde las aprobaciones y los permisos son capas delimitadas, es el lugar donde la frase "toda llamada de herramienta es observable y aprobable" deja de ser retórica y se vuelve cumplimiento de permisos antes de actuar, con ejecución sandboxed contenida, como trae Nexforce Work. El costo por éxito de un agente y la lectura de cuál camino cuesta más dependen de rastrear el consumo del agente en la capa de modelos donde corre, la capa Router de Nexforce como infraestructura, aunque el sujeto de estas líneas siga siendo el agente y la ejecución, no la tabla de precio por token. El comprador que diseña la evaluación como prueba de regresión compra, al final, un sistema cuyo costo y cuyo cumplimiento pueden nombrarse antes de la producción, y solo así son decidibles.

Preguntas frecuentes sobre la evaluación de agentes más allá de la respuesta

¿Por qué una evaluación de respuesta final no basta para un agente en producción? Porque solo verifica el desenlace y es ciega al proceso. Un agente puede acertar la respuesta final y haber transitado un camino equivocado, llamando a herramientas que no debía u omitiendo la llamada que validaría el paso. La nota queda perfecta en el momento exacto en que la operación debería haberse interrumpido. Correcto en la letra, peligroso en el recorrido.

¿Qué es la ruta de herramientas y por qué importa evaluarla? Es la secuencia de llamadas de herramienta que el agente hizo y las que evitó. Importa porque la falla de proceso suele estar en la llamada omitida, no en la respuesta equivocada. Un agente de soporte que emite un reembolso sin verificar el pedido recibe un diez en el desenlace y solo se lo atrapa con una aserción que exige la llamada lookup_order.

¿Cómo se convierte un bug de agente en una prueba de regresión? Guardando la falla documentada como una aserción cubierta en la suite. El bug se vuelve un test, entra en la suite y pasa a correr en cada release del agente y siempre que un modelo nuevo suba. Cualquier release que reintroduzca el camino violado falla en la puerta, antes de tocar la operación.

¿Qué significa fijar el harness en la evaluación de agentes? Significa congelar el entorno de prueba, la versión del harness, el conjunto de casos y el punto de corte antes de medir al agente. Solo con el harness fijado un cambio de puntaje se vuelve atribuible a lo que se cambió a propósito, el modelo, el prompt o la llamada, y el KPI deja de ser un número sin dueño.

¿Dónde se vuelve observable el cumplimiento de permisos de un agente? En la capa de ejecución del agente en el workspace, donde las aprobaciones y los permisos son capas delimitadas y cada llamada de herramienta es aprobable antes de actuar, con ejecución contenida en modo sandboxed. Es donde el camino que una evaluación de respuesta no ve se vuelve dato verificable antes de la producción. Solo ahí el permiso tiene prueba.

Referencias y lecturas complementarias

• Lectura acompañante de Nexforce sobre la regla de escala: el ROI antes de escalar el piloto y, en la frontera del clúster, los criterios técnicos de evaluación de agentes B2B antes del piloto.
• Nexforce Agents, la unidad de desarrollo e implementación de agentes de IA en operaciones B2B: nexforce.ai/agents.

La regla no la pone la última línea

El comprador de agentes B2B que saca la nota solo de la respuesta final está midiendo la exhibición que el agente eligió mostrar, no la operación que transitó. La regla del recorrido, con la ruta de herramientas llamada y evitada, el harness fijado, la recuperación de errores y la regresión en CI, es lo que convierte el cumplimiento de permisos en una propiedad verificada y el bug en un test que nunca deja de correr. Antes de poner al próximo agente en producción, el CTO debería responder una pregunta que ningún puntaje de respuesta resuelve: si la operación solo descubriera el camino que este agente transitó después del primer incidente, en qué versión de él estaría apostando hoy la empresa. Nombrar el camino antes, en la ruta declarada y en la suite de regresión, es la diferencia entre descubrir la falla como un test y descubrirla como un incidente.