Cómo evaluar acciones de agentes, no solo respuestas

Un agente puede escribir una respuesta impecable y no haber hecho el trabajo. Dice que actualizó el pedido, que creó el reembolso o que cerró el ticket, y el texto suena bien, pero el sistema sigue igual o, peor, cambió algo que no debía. Si solo lees lo que el agente dice, no puedes saber si funcionó.

Este artículo explica cómo evaluar lo que el agente hace en el producto: qué medir, qué guardar de cada ejecución, cómo armar un conjunto de casos reales y cómo comprobar que un cambio de modelo o de instrucciones no rompe lo que ya funcionaba.

Si buscas cómo reconstruir una tarea después de que ocurrió, está en trazabilidad de agentes. Si buscas el programa que rodea al modelo y ejecuta las acciones, en el harness del agente. Aquí el foco es la medición: cómo saber, con números, si el agente hizo bien su trabajo.

Respuesta correcta frente a trabajo hecho

Evaluar un chat y evaluar un agente son dos problemas distintos. En un chat, el resultado es el texto: si la respuesta es correcta, útil y clara, cumplió. En un agente, el texto es solo el final de una cadena de pasos, y lo que importa es qué cambió en tu producto por el camino.

Piensa en un copiloto de soporte al que un cliente pide un reembolso parcial. La respuesta final puede decir "Reembolso de 25 euros procesado". Para saber si eso es verdad hay que comprobar cuatro cosas que el texto no demuestra:

• Que eligió la acción correcta (crear un reembolso, no solo consultar el pedido).

• Que envió los datos correctos (el importe y el pedido de ese cliente, no de otro).

• Que el sistema aceptó la acción y el reembolso existe de verdad.

• Que lo hizo sin pasos de más: sin repetir la misma llamada tres veces ni leer datos que no necesitaba.

Una respuesta que se lee bien con un reembolso que no existe es peor que una respuesta torpe con el reembolso hecho. Por eso la pregunta de fondo cambia: de "¿suena bien?" a "¿el estado final del sistema es el que debía ser?".

Anthropic recomienda en Building effective agents empezar con sistemas simples y medir antes de añadir complejidad. La idea de fondo es la misma: sin una forma de medir, cada cambio es una apuesta. OpenAI describe en su guía de evals las evaluaciones como pruebas repetibles contra criterios definidos, y ese es el espíritu que conviene llevar a las acciones, no solo a los textos.

Métricas que importan en producción

No hace falta un panel con treinta indicadores. Para un agente en un SaaS bastan unas pocas, medidas siempre igual, y que alguien mire cada semana. Se agrupan en dos familias: si el trabajo salió bien, y cuánto costó hacerlo.

Tarea resuelta y acierto a la primera

La métrica principal es la tarea resuelta: de todas las tareas que el agente intentó, qué porcentaje terminó con el resultado correcto en el sistema. No "respondió algo", sino "el pedido quedó en el estado esperado". Se calcula comparando el estado final del producto con el que se esperaba.

Una variante muy útil es el acierto a la primera: qué porcentaje se resolvió sin que el agente tuviera que corregirse, reintentar ni pedir ayuda a una persona. Un agente que acaba bien pero tarda cuatro intentos funciona en la demo y cuesta caro en producción. Si la tarea resuelta sube y el acierto a la primera baja, el agente está compensando con reintentos algo que está mal en las acciones o en las instrucciones.

Conviene medir además dos cosas que no entran en el porcentaje:

• Tareas que se escalan a una persona, porque un agente que deriva todo es seguro y no sirve.

• Errores graves, es decir, acciones incorrectas con efecto real (un reembolso de más, un correo al cliente equivocado). Se cuentan aparte, porque un solo caso puede pesar más que cien aciertos.

Coste y pasos por tarea

La segunda familia responde a cuánto cuesta cada tarea bien hecha. Dos números bastan:

• Pasos por tarea: cuántas acciones y llamadas al modelo necesita el agente de media. Si sube sin que suba la complejidad de las tareas, algo se está repitiendo.

• Coste por tarea resuelta: el gasto total dividido entre las tareas que terminaron bien, no entre todas las intentadas. Las tareas fallidas también cuestan, y es justo lo que este cálculo deja ver. Cómo se descompone ese coste está en el precio del token no es el coste del agente.

Mirar las dos familias juntas evita engaños. Un cambio que sube la tarea resuelta del 82% al 88% pero triplica el coste por tarea puede no compensar. Uno que baja el coste a la mitad a cambio de perder cinco puntos de acierto, tampoco.

Qué capturar en cada traza

Una traza es el registro paso a paso de una ejecución: qué hizo el agente, en qué orden y qué respondió cada acción. Sin trazas no puedes calcular nada de lo anterior, y tampoco entender por qué falló una tarea concreta.

Para evaluar acciones, cada traza debería guardar como mínimo:

Lo que no debería ir en la traza sin cuidado son datos de cliente y secretos. Se guardan identificadores y resultados, no el contenido íntegro de los documentos, y se aplican las mismas reglas de retención que a cualquier otro almacén. El detalle de cómo montar este registro está en trazabilidad.

Un conjunto de casos de acciones, no solo de chats

Para medir con números hace falta un conjunto fijo de casos con la respuesta esperada. En el oficio se llama golden dataset: una colección de situaciones reales, cada una con el resultado correcto ya decidido, contra la que se prueba el agente una y otra vez.

El error habitual es armarlo solo con conversaciones: una pregunta y la respuesta ideal. Eso evalúa el texto. Para un agente, cada caso debería describir tres cosas:

1. La situación inicial: el estado del producto antes de empezar (un pedido enviado, un ticket abierto, un cliente con un plan concreto).

2. La petición del usuario, tal y como llega.

3. El resultado esperado en el sistema: qué acción debe haberse llamado, con qué datos, y en qué estado debe quedar todo. Y, igual de importante, qué no debe haber tocado.

Algunas pautas para construirlo sin que se vuelva inmanejable:

• Empieza con 20 a 30 casos reales, tomados de tareas que el agente ya ha manejado, con los datos de cliente anonimizados. Es mejor un conjunto pequeño y revisado que uno enorme y dudoso.

• Incluye los casos difíciles a propósito: peticiones ambiguas, datos que faltan, un cliente que pide algo que no está permitido, una acción que devuelve error. Un conjunto solo de casos fáciles da una nota alta y no enseña nada.

• Añade cada fallo real que ocurra en producción. Cuando el agente se equivoque con un cliente, ese caso entra al conjunto con el resultado correcto. Así el mismo error no vuelve sin que lo notes.

• Separa por cliente cuando importe. En un SaaS con varias cuentas, algún caso debería comprobar que el agente de una cuenta no toca datos de otra.

Regresión al cambiar modelo, acciones o instrucciones

Una regresión es que algo que antes funcionaba deje de funcionar después de un cambio. En agentes ocurre con más facilidad de la que parece, porque casi todo es modificable: el modelo, las instrucciones, la descripción de una acción o el esquema de sus datos. Un ajuste pensado para arreglar un caso puede romper otros tres sin que nadie lo vea.

La defensa es una rutina simple:

1. Antes de cambiar nada, ejecuta el conjunto de casos con la versión actual y guarda los números.

2. Haz el cambio (otro modelo, una instrucción nueva, una acción reescrita).

3. Ejecuta el mismo conjunto con la versión nueva.

4. Compara las dos tablas: tarea resuelta, acierto a la primera, pasos, coste y errores graves.

5. Publica solo si la nueva no empeora lo que importa, o si el empeoramiento es una decisión consciente.

Dos matices evitan malas lecturas. Primero, el modelo no responde exactamente igual dos veces, así que conviene repetir cada caso varias veces o mirar tendencias en lugar de un único resultado. Segundo, una mejora media puede esconder una caída en un tipo concreto de tarea: mira siempre el desglose por tipo de caso, no solo el total.

Esto aplica también cuando cambias solo la descripción de una acción. Como vimos en contratos de herramientas para agentes, el modelo lee esa descripción en cada paso y decide por ella, así que tocarla equivale a tocar el comportamiento.

Revisión humana sin convertirla en un cuello de botella

Los números automáticos no lo cubren todo. Hay cosas que solo una persona juzga bien: si el tono fue adecuado, si la decisión era razonable, si la acción tenía sentido aunque técnicamente fuera válida. El riesgo es que la revisión se convierta en una cola que nadie termina.

Tres reglas la mantienen manejable:

• Revisa por muestreo, no todo. Una muestra pequeña y constante (por ejemplo, un 5% de las tareas de la semana) da una imagen fiable sin colapsar al equipo. Sube el porcentaje solo para las tareas de riesgo alto.

• Prioriza lo raro. Las tareas con muchos reintentos, con coste muy por encima de la media o escaladas a una persona son las que más enseñan. Revísalas primero.

• Convierte cada revisión en un caso. Si una persona detecta un fallo, ese caso pasa al conjunto de pruebas. Así la revisión alimenta la medición automática en lugar de repetirse cada semana.

Para acciones que no se pueden deshacer, como un cobro o un envío al cliente, la revisión no es muestreo: es aprobación antes de ejecutar, y eso se diseña en el sistema de permisos, no en la evaluación. Lo trata identidad, permisos y límites.

Checklist de evaluación

Antes de dar por evaluado un agente en producción, comprueba que puedes responder que sí a esto:

• Mides la tarea resuelta mirando el estado final del producto, no el texto de la respuesta.

• Conoces el acierto a la primera y cuántas tareas se escalan a una persona.

• Cuentas los errores graves por separado.

• Sabes los pasos y el coste por tarea resuelta, no solo el precio del modelo.

• Cada ejecución guarda una traza con acciones, datos, resultados, versión y estado final.

• Tienes un conjunto de 20 o más casos reales, con situación inicial y resultado esperado en el sistema.

• Ese conjunto incluye casos difíciles y cada fallo real de producción.

• Ejecutas el conjunto antes y después de cambiar modelo, instrucciones o acciones, y comparas.

• Revisas una muestra fija de tareas cada semana y conviertes los fallos en casos nuevos.

• Alguien con nombre mira estos números a diario o a la semana, y puede pausar el agente si empeoran.

Si faltan varios, el siguiente paso no es mejorar el modelo. Es medir: sin esos números, cada cambio se decide por intuición, y el piloto se queda atascado discutiendo si el agente "va mejor". Cuando la medición existe, la discusión cambia: ya no es una opinión, es una tabla. Es parte del salto que tratamos en una demo no es un agente en producción.