Deja de ejecutar nuevos benchmarks de modelos y empieza a observar a tu agente intentar cancelar una suscripción. La brecha entre esas do

Deja de ejecutar nuevos benchmarks de modelos y empieza a observar a tu agente intentar cancelar una suscripción. La brecha entre esas dos actividades es donde mueren los sistemas de producción. Una prueba de un solo turno puede decirte si una respuesta suena agradable. No puede decirte si el agente acaba de reembolsar al cliente equivocado, si entró en un bucle catorce veces contra una API de calendario o si decidió omitir por completo la verificación de fraude. El texto es lo menos peligroso que produce un agente. Los riesgos reales se esconden en las herramientas que toca, los datos que muta y los momentos en los que debería haber pedido ayuda pero continuó adelante.

Por qué los benchmarks de texto fallan en producción

Las puntuaciones altas en los benchmarks estándar se han convertido en una forma engañosa de consuelo. Un agente que escribe prosa elegante puede seguir siendo un peligro operativo. Cuando tu sistema reserva citas, edita registros de bases de datos o abre tickets de soporte, el texto generado es solo la superficie visible del flujo de trabajo. Debajo, el agente está tomando decisiones concretas sobre qué endpoint llamar, qué payload enviar y cuándo detenerse. Puede encabezar una tabla de clasificación de comprensión lectora mientras te hace perder dinero al duplicar reservas de recursos, mutar la fila incorrecta o filtrar estados sensibles en un archivo de registro. Necesitas verificar la mecánica del trabajo, no solo el acabado del resultado. Si un agente puede obtener una buena puntuación en una prueba de QA offline y aun así fallar en tu flujo de trabajo al entrar en bucles o hacer un uso indebido de una herramienta, tu evaluación está analizando las señales equivocadas.

Mapeando las cinco dependencias

El equipo de Van Data Team comienza cada evaluación mapeando cinco puntos de control específicos. Esto cambia la pregunta por completo. Dejas de preguntar si un modelo es más inteligente que otro. Empiezas a preguntar si el agente puede realmente completar una tarea de producción bajo tus restricciones reales.

Resultados de negocio. Define qué significa "terminado" en términos de dólares e impacto en el cliente. Una tarea no está completa solo porque el agente haya emitido un resumen. Está completa cuando el registro de inventario es preciso, la cita está confirmada y el cliente ha recibido un número de seguimiento válido.

Estado mutable. Saber exactamente qué se le permite cambiar al agente. ¿Qué tablas, qué estados, qué indicadores de cuenta? Si el agente puede emitir reembolsos, reprogramar trabajos o actualizar direcciones de facturación, necesitas hacer un inventario de cada campo que toque.

Permisos de herramientas. Sé explícito sobre qué endpoints de API y funciones están dentro del alcance. Un agente con acceso a una herramienta de búsqueda, una herramienta de escritura y una herramienta de notificación las confundirá si los límites son difusos. Mapea cada permiso a una necesidad operativa específica.

Recuperación de fallos. Decide qué sucede cuando la API de calendario agota el tiempo de espera (timeout), devuelve un error 500 o entrega un JSON mal formado. El agente no debe entrar en pánico, alucinar un mensaje de éxito o reintentar infinitamente. Necesita una ruta de respaldo (fallback) clara.

Puntos de revisión humana. Identifica los momentos en los que una persona debe dar su aprobación antes de que el agente proceda. Esto no es un signo de debilidad en la automatización. Es una válvula de seguridad para cambios de alto impacto y una fuente de etiquetas de verdad fundamental (ground-truth) para tus rúbricas.

Cómo es un plan de evaluación real

Una vez mapeadas las dependencias, necesitas un plan de evaluación que se ajuste al caos de la producción. Las métricas de presentaciones de diapositivas no te servirán de

Install release gates to block bad model upgrades. A new model is only an upgrade if it improves your specific outcomes. If it hallucinates tool arguments more often, increases latency, or introduces new safety risks, it does not ship. The gate keeps production stable even when the base model vendor ships a new version.

Runtime Grading: Watching the Agent Work

Anthropic has been pushing the industry to move beyond offline tests toward runtime grading. Instead of judging a transcript after the fact, runtime grading lets a system judge the agent's work while the task is still in flight. This creates a chance to catch errors before they harden into real problems.

Adding a grader costs tokens and latency. You cannot afford to grade every tiny step. The placement of each grader is a design decision. Put them where the mistakes are expensive. The most valuable checkpoints sit just before committing a state change to a database, just before capturing a payment, and just before sending a message to a customer. These are the moments where a bad decision becomes an irreversible action.

Watch out for a specific blind spot. If the same model performs the work and also grades the work, it may miss the same mistakes. The reasoning that produced an error can easily rationalize that error away during review. For high-impact tasks, keep human review inside the loop. Let people validate the grader's own judgment, especially when money or customer trust is on the line.

The goal here is operational control. Connect your incident data, your task rubrics, and your runtime traces into one feedback cycle. Evaluate the whole path: the plan, the tool use, the recovery behavior, and the final result. Use offline tests to catch known, reproducible errors before release. Use runtime traces to find the new failures you did not anticipate. Use human review to discover where your rubrics are naive and need tightening.

So ask yourself: where would you put a runtime grader in your workflow? Before a tool call, after a tool call, or only before a risky change? Most teams start too broad, grading everything, and then grind to a halt under the cost. Start narrow. Pick the one action that would hurt the most if it went wrong. Put a grader there first.

Start With One Expensive Mistake

Operational evaluation is not a research exercise. It is a way to sleep better once the agent is live. You do not need a perfect framework on day one. You need a single, well-defined workflow, a rubric written in plain business terms, and a grader placed at the exact moment where an error becomes expensive. Get that right, and you have a foundation you can actually trust.

If you want to dig deeper into agent evaluation and runtime grading with a community of practitioners, you can find the GyaanSetu learning community at https://t.me/GyaanSetuAi.