Lanza evaluaciones de agentes que detecten fallos de tarea, descuidos de seguridad, picos de costo y regresiones de latencia antes que los usuarios

Un agente de soporte puede enviar una respuesta cortés, dejar el ticket sin resolver y, aun así, hacer que el usuario repita el problema. Ese es el fallo de 'respuesta sin resolución': el usuario recibe una respuesta, no un ticket resuelto, no un estado correcto de la cuenta y no una tarea completada.

El patrón incómodo no es solo una brecha de herramientas; es un fallo de diseño: los equipos lanzan agentes más rápido de lo que pueden juzgarlos, y las herramientas de evaluación no han logrado mantener el ritmo con la creciente diversidad de frameworks de agentes. La solución es un contrato de tarea antes de que exista el agente: definir el objetivo del usuario, los criterios de éxito, las restricciones de seguridad, el presupuesto de costo, el presupuesto de latencia y las señales de retroalimentación que indican que el usuario fue ayudado y no simplemente respondido. Sin ese sistema, cada lanzamiento es una conjetura disfrazada de confianza.

Empieza por el contrato de tarea, no por el modelo

La mayoría de las evaluaciones de agentes fallan porque empiezan por el modelo y terminan con una puntuación. La mejor jugada es empezar por la tarea del usuario y terminar con una decisión de lanzamiento. El contrato de tarea es el primer artefacto de diseño, y hace posible esa decisión.

Un contrato de tarea convierte la calidad vaga en requisitos de diseño. Si el objetivo es resolver un ticket de soporte, el éxito no es una respuesta cortés. Es un ticket resuelto, un estado correcto de la cuenta, ninguna acción no autorizada y un usuario que no necesita repetir el problema. Si el objetivo es redactar un documento, el éxito incluye un borrador utilizable, ninguna fuga de contexto privado, ningún hecho fabricado y ningún bucle que queme presupuesto. El contrato es la especificación que hace responsable al agente.

Instrumenta la sesión como un artefacto de diseño

Una vez que existe el contrato, instrumenta el agente para que cada sesión pueda reconstruirse como evidencia. El span de sesión no es solo una línea de registro. Es el registro de lo que el agente vio, lo que llamó, lo que cambió y lo que devolvió. Si ese span no incluye el contenido de los mensajes, las llamadas a herramientas y el contexto del usuario, la evaluación es solo un rumor. Puede que sepas que algo ocurrió, pero no puedes juzgar si fue bueno.

Una trampa práctica es la falta de contenido de mensajes, porque los evaluadores de calidad de respuesta dan error si el span no lo tiene. El rediseño consiste en tratar el contenido de los mensajes como evidencia obligatoria, no como metadatos opcionales.

Diseña los spans con el mismo cuidado que la interfaz. Registra la solicitud del usuario, el plan del agente, cada llamada a herramienta, el resultado de cada llamada, la respuesta final y cualquier reacción del usuario. Registra el costo y la latencia a nivel de span, porque una llamada a herramienta lenta puede esconderse dentro de una respuesta que parece rápida. Registra los cambios de estado relevantes para la seguridad cuando el agente escribe, envía, elimina o cambia permisos.

Elige el andamiaje como un sistema de diseño

Un andamiaje de evaluación es el conjunto de herramientas que convierte sesiones en juicios. Se aplica el mismo movimiento: tratar el andamiaje como un sistema de diseño con componentes reutilizables, puntuación consistente y un límite claro entre el trabajo dentro de la distribución y el trabajo personalizado.

Los andamiajes personalizados siguen siendo necesarios, pero no deberían convertirse en scripts de un solo uso. El juicio es claro: los andamiajes listos para usar suelen ser mejores para tareas dentro de la distribución, mientras que los andamiajes personalizados mantienen los componentes dentro de la distribución, como la edición de archivos, alineados con el entrenamiento. El rediseño consiste en usar esos componentes como piezas reutilizables de un andamiaje consistente, en lugar de scripts de un solo uso.

El andamiaje también debe ser independiente del framework. Las evidencias de la crítica de diseño apuntan al mismo juicio: los mismos evaluadores pueden aplicarse en Strands Agents, LangGraph, OpenAI Agents SDK, LlamaIndex, Google ADK y Claude Agent SDK después de reconstruir las sesiones a partir de spans de OpenTelemetry. El rediseño consiste en hacer que esa reconstrucción sea parte del andamiaje, para que los mismos evaluadores puedan juzgar sesiones entre frameworks.

Controla los lanzamientos con el producto completo, no con una sola puntuación

El último movimiento de diseño es convertir la evaluación en una puerta de lanzamiento. Una sola puntuación no basta. La puerta revisa el producto completo: primero, el éxito de la tarea, preguntando si el agente completó el objetivo y no solo sonó plausible; luego, la seguridad, preguntando si evitó acciones no autorizadas, fugas de privacidad y errores irreversibles; luego, el costo, preguntando si se mantuvo dentro del presupuesto en lugar de quemar dinero en bucles; luego, la latencia, preguntando si cumplió el presupuesto de tiempo en lugar de hacer esperar al usuario; y, por último, la retroalimentación, preguntando si los usuarios marcaron el resultado como útil, incorrecto o inseguro. Una puerta de lanzamiento no es burocracia. Es el juicio de la crítica de diseño vinculado al contrato de tarea: no dejes que un agente más rápido cometa un error que parece más seguro, y no dejes que un agente más barato falle silenciosamente al usuario.

Por último, alimenta el próximo conjunto de evaluación con trazas de producción. La rueda de trazas de producción es el movimiento de diseño: las trazas afinan el andamiaje, el modelo y el contexto, y luego la siguiente puerta de lanzamiento se ejecuta antes de que los usuarios se encuentren con el cambio. Volviendo al agente de soporte, la puerta detecta la respuesta cortés sin resolver al verificar la resolución del ticket, el estado de la cuenta y la retroalimentación del usuario, no el tono. El veredicto es simple: si se cumple el contrato de tarea, lanza; si no, la puerta detecta las regresiones antes que los usuarios.