Vercel: evals para saber si tu agente de IA acierta

Un agente puede acertar la llamada y fallar la tarea

Un pedido de latte helado que se ejecuta sin errores, devuelve 200 OK y aparece impecable en el dashboard de observabilidad puede haber entregado un latte caliente. Nada falló a nivel de red: falló el resultado. Vercel abre su guía con esa escena porque resume el problema: si un test pregunta ¿funcionó?, un eval pregunta ¿con qué frecuencia funciona y qué tan bien?

Al founder le importa por una razón de negocio: el fallo silencioso no llega al churn como bug, llega como el producto no me sirve. Y el hueco entre ver y medir se ve en los datos. En la encuesta State of Agent Engineering de LangChain, con 1.340 profesionales y publicada a fines de 2025, el 89% de las organizaciones reportó algún tipo de observabilidad sobre sus agentes y el 62% tenía trazado detallado de pasos y llamadas a herramientas. Pero solo el 52,4% corría evaluaciones offline sobre un set de pruebas y apenas el 37,3% evaluaba el tráfico real, según el repaso de investigación que publica Unite.AI. La calidad fue, además, la barrera más citada para llevar agentes a producción, con un 32%.

La investigación apunta en la misma dirección. En el benchmark τ-bench —presentado en ICLR 2025 por Shunyu Yao y colegas de Sierra— un agente basado en GPT-4o resolvía alrededor del 61% de tareas de retail en un solo intento, pero cuando debía acertar la misma tarea ocho veces seguidas la tasa caía cerca del 25%, siempre según la cobertura de Unite.AI. Una demo que funciona una vez no dice casi nada sobre el sistema que corre mil veces.

Leíste lo que hace la IA. ¿Y en tu negocio?

Un agente de IA puede quedarse con parte de tu día: ordenar lo pendiente y pedirte el OK antes de actuar. El Kit «tu mano derecha con IA» trae un video de 11 minutos y una ficha para dejar al tuyo trabajando. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

La pirámide de testing de agentes: tres niveles según las llamadas al modelo

Vercel agrupa las pruebas por cuántas llamadas al LLM necesitan típicamente, y ese número resultó un buen indicador del esfuerzo de construirlas, del tiempo que tardan y de lo que cuestan:

Tests deterministas (0 llamadas): validan la lógica del producto que no depende del modelo.
Evals de un turno (1 llamada): comprueban una sola decisión, como qué comando ejecuta el agente primero.
Evals end-to-end (2 o más llamadas a lo largo de toda una tarea): dejan al agente resolver el trabajo completo dentro de un entorno y revisan si el resultado final cumple lo que pidió el usuario.

La regla de uso es simple: parte del problema que quieres atrapar y elige el nivel más bajo que pueda atraparlo. Para el éxito de la tarea eso es la cima de la pirámide, porque el resultado depende de la secuencia entera (buscar opciones, filtrar por criterios, ejecutar la acción) y cada paso puede parecer razonable por separado mientras el conjunto termina mal. Los benchmarks de código más conocidos, como SWE-bench y Terminal-Bench, son evals end-to-end.

Pass@k y pass^k: puede hacerlo no es lo hace siempre

Las métricas que Vercel usa con más frecuencia son tres. Success rate es la proporción de intentos que pasan. Pass@k es la probabilidad de que al menos uno de k intentos pase, y responde a la pregunta ¿puede el agente hacer esto?. Pass^k es la probabilidad de que todos los k intentos pasen, y responde a ¿puedo confiar en que lo hará cada vez?. La eficiencia —pasos, tiempo y costo— se mide solo sobre los intentos exitosos, porque un fallo corto suele ser un fallo que se saltó trabajo.

En el ejemplo ilustrativo que usa el artículo, cinco intentos de un mismo agente sobre un pedido concreto arrojan un 60% de éxito: eso equivale a un pass@5 cercano al 99% y a un pass^5 de apenas el 8%. Ambos números son correctos y responden a preguntas distintas. Si el agente falla una de cada doce semanas, quien pide su café cada mañana va a recibir el pedido equivocado con frecuencia. Por eso el costo real no es el costo por intento exitoso, sino el costo por éxito cuando se suman los intentos fallidos que igual se pagaron.

Qué métrica priorizar depende de lo que cuesta un fallo para el usuario. Si reintentar es barato porque el error se detecta antes de que importe, pass@k alcanza. Si no hay reintento —un pedido de café, un cobro, una reserva— necesitas pass^k. Y conviene mirar siempre los resultados tarea por tarea: un promedio general puede esconder una tarea que falla casi siempre, y con pocos intentos un 100% significa todavía no vi fallos, no nunca falla.

Los cinco pasos para construir un eval end-to-end

1. Fijar un objetivo. Cubrir todo lo que un LLM podría hacer con tu producto no es viable. Elige un resultado que le importe a tus usuarios y que puedas evaluar con un puñado de tareas. Vercel lo busca en tres lugares: observabilidad (qué agentes usan el producto y dónde fallan), clientes (tickets de soporte, feedback, churn) y roadmap (la hipótesis que necesitas validar).

2. Definir métricas. Success rate, pass@k o pass^k según el costo del fallo, más pasos, tiempo y costo sobre los intentos exitosos.

3. Diseñar el set de tareas. Cada tarea necesita una instrucción, un entorno con el mismo estado inicial en cada intento, un verifier que puntúe restricción por restricción y, opcionalmente, una solución conocida que demuestre que la tarea es resoluble. Un buen set cubre el caso común, los casos borde que rompen a los agentes y al menos una petición donde lo correcto sea no actuar.

4. Correr el job. Vercel usa Harbor, un framework open source de los creadores de Terminal-Bench que ejecuta agentes en contenedores, valida resultados y registra sus acciones. La integración con Vercel Sandbox corre intentos en paralelo y cachea los entornos ya construidos, y AI Gateway unifica el acceso a modelos de varios proveedores con una sola clave. En el ejemplo del artículo, cuatro tareas por cuatro variantes por cinco intentos dan 80 pruebas.

5. Analizar las trazas. Los puntajes dicen con qué frecuencia falla el agente; las trazas dicen por qué. Hay que leer los fallos y también una muestra de los aciertos, porque un acierto solo significa que el verifier quedó satisfecho.

El verifier que regala aprobados

La parte más útil del artículo es la que documenta los errores de su propio eval. En la primera corrida todos los modelos puntuaron 0%: los agentes no sabían que la herramienta existía, así que nunca la intentaron. Era la etapa de descubrimiento del embudo fallando dentro del propio experimento, y se arregló nombrando la herramienta en la instrucción. La lección es de producto: ser descubrible por un agente también es parte de tu producto.

El segundo hallazgo es más incómodo. Uno de los agentes aprobaba casi siempre la tarea imposible, pero al leer las trazas nueve de cada diez aprobados eran el agente rindiéndose sin buscar. El verifier solo comprobaba que no se hubiera colocado ningún pedido. Al endurecerlo para exigir evidencia de búsqueda previa, esos falsos positivos desaparecieron.

El tercero es de seguridad: si el estado que revisa el verifier vive en el mismo entorno que el agente, el agente puede intentar hacer trampa y editar el inventario o escribir el archivo de pedidos directamente. Protege los datos semilla y el código del verifier, y obliga a que los cambios pasen por las herramientas del producto.

Por qué el contexto pesa tanto como el modelo

Un eval compara variantes: modelo, prompt, herramientas, memoria y skills. La evidencia disponible sugiere que ahí hay tanto margen como en cambiar de modelo. Bito reportó en febrero de 2026 que un agente con Claude Sonnet 4.5 potenciado con su motor de contexto alcanzó 60,8% de éxito en SWE-Bench Pro frente al 43,6% del mismo agente sin ese contexto, según el comunicado difundido por Yahoo Finance. Y un trabajo presentado en ICLR 2024 y recogido por Unite.AI encontró que cambiar solo el formato de los ejemplos del prompt —separadores, espacios, mayúsculas— movía la precisión hasta 76 puntos en una misma tarea. Un prompt es un cambio de código: necesita historial de versiones y una prueba antes de llegar a usuarios.

También conviene saber cuánto pesa esto en la economía real del agente. Raindrop, una de las plataformas de fiabilidad de agentes que levantó una ronda Serie A liderada por CRV, cita investigación según la cual la duración de las tareas que un agente puede completar de forma autónoma se duplica aproximadamente cada siete meses, y señala que una corrida individual ya puede durar días e implicar miles de llamadas a herramientas, según Pulse 2.0. Si el alcance crece a ese ritmo, un set de pruebas fijo se queda viejo rápido: los evals se saturan y dejan de decirte qué mejorar.

¿Qué significa esto para tu startup?

Elige la métrica según el costo del fallo, no por costumbre. Si tu agente reserva, cobra o compra, optimiza pass^k. Si el reintento es barato y el error se detecta a tiempo, pass@k es suficiente.
Saca las tareas de tus propios datos. Los mejores objetivos están en los tickets de soporte y en las trazas de producción, no en una lluvia de ideas. Si el 32% de los equipos señala la calidad como freno para producción, tu lista de tickets es el mejor punto de partida que tienes.
Escribe una tarea imposible y verifica que el agente buscó antes de rendirse. Es la prueba más barata que separa un agente prudente de uno que abandona y aprueba.
Versiona prompts y descripciones de herramientas como código y corre el eval en cada release. Sirve para detectar regresiones, comparar modelos y saber si una skill nueva aporta algo antes de publicarla.
Traduce el resultado a lenguaje de negocio. Como plantea Forbes Tech Council, un benchmark aislado rara vez predice resultados: lo que decide es medir tasa de tarea completada, latencia y costo por tarea exitosa contra un KPI que ya exista en la empresa.

Conclusión

La conclusión más valiosa de la guía no es técnica sino de gestión: el eval es infraestructura, no un experimento puntual. Un agente no anuncia sus fallos, y la única forma de saber si la última versión mejoró algo es repetir las mismas tareas y volver a calificar los resultados. Empieza con un objetivo, cuatro o cinco tareas bien diseñadas y un verifier honesto. Eso te da más señal que cualquier leaderboard.