Lo que las vistas agenticas de Vercel realmente revelan
Vercel lanzó Is Agentic el mes pasado con una característica engañosamente simple: vistas de auditoría segmentadas por tipo de sitio. La vista Commerce marca estándares de pago—conformidad con Apple Pay, cumplimiento del esquema de Stripe, datos de productos estructurados. La vista App marca patrones de autenticación y convenciones de SDK. La vista Docs marca la estructura de llms.txt e indexación de contenido. Cada vista ejecuta el mismo conjunto de pruebas pero las enruta por dominio antes de puntuar.
La idea accidental: los agentes y flujos de trabajo que tocan múltiples superficies necesitan contextos de observabilidad separados, no una única puntuación agregada. Vercel no llama a esto un problema de evaluación. Lo llama un problema de auditoría. Pero para equipos que envían agentes que leen documentación, llaman a APIs REST y ejecutan pagos—es exactamente el problema de evaluación que hemos resuelto mal.
La puntuación de evaluación monolítica te está mintiendo
Cada arnés de evaluación que hemos construido comienza de la misma manera: ejecutar un conjunto de pruebas, contar aprobaciones y fallos, reportar un porcentaje. Una tasa de aprobación del 78% se ve aceptable. Luego te llaman a las 2am porque una tormenta de reintentos de webhook de Stripe está agotando tus límites de velocidad. Extraes los registros. El agente aprobó el 78% de las trazas de evaluación. Falló en el 0% de los flujos de pago. El agregado estaba mintiendo.
Aquí está la razón técnica: los sistemas de ML generalizan a partir de datos, pero los conjuntos de evaluación rara vez representan la distribución de superficies que tu agente realmente encuentra. Un único conjunto de pruebas con 20 preguntas de documentación, 15 llamadas a API y 5 flujos de pago pesará cada superficie por igual en la puntuación final. Si tu agente acierta en documentación el 95% de las veces pero en pagos el 40%, el agregado lo oculta detrás de un número aceptable. La superficie con la menor tolerancia al fallo desaparece en el ruido.
Hemos encontrado que re-dividir datos históricos de evaluación por superficie de interacción revela brechas que ninguna tasa de aprobación única jamás ha señalado. Un agente que "aprueba el 82% de las pruebas" a menudo se divide en algo como documentación al 91%, APIs al 78% y transacciones al 41%. Una de esas es una emergencia en producción. Una puntuación agregada no te dirá cuál.
Las superficies de interacción tienen modos de fallo incompatibles
La razón por la que el enrutamiento por tipo de sitio importa es estructural, no cosmética. Cada superficie tiene una taxonomía de fallos completamente diferente y un perfil de tolerancia.
Las superficies de documentación y RAG se preocupan por alucinación, fundamentación de citas y recall@k. Una respuesta incorrecta es mala, pero recuperable mediante reintento. El presupuesto de latencia es generoso—20 segundos está bien. La idempotencia no es una preocupación.
Las superficies de API y llamadas de herramientas se preocupan por conformidad de esquema, manejo de 4xx/5xx, claves de idempotencia y colas de letra muerta. Un reintento es costoso pero seguro si estableces correctamente los encabezados Idempotency-Key. El presupuesto de latencia es ajustado—la latencia de cola de 200ms mata la experiencia del usuario.
Las superficies transaccionales y de comercio se preocupan por límites de PCI, semántica exactamente-una-vez, reversibilidad de reembolsos y flujos PSD2/SCA. Un reintento es peligroso. Una alucinación sobre un monto de reembolso es una violación de cumplimiento. El presupuesto de latencia está en algún punto intermedio, pero el costo del fallo es más alto. La granularidad de observabilidad que cada superficie necesita es completamente diferente—documentación necesita cadenas de citas, APIs necesitan IDs de correlación, transacciones necesitan IDs de traza que se extiendan a los registros de tu procesador de pagos.
Un único pipeline de evaluación no puede puntuar los tres sin diluir los controles u ocultar cuál está roto. Necesitas enrutamiento de señal específico del dominio.
Cómo se ve el enrutamiento de señal específico del dominio en la práctica
La versión más simple comienza en la capa de llamada de herramientas. Etiqueta cada traza con un campo interaction_surface—ya sea en middleware de Vercel AI SDK o metadatos de OpenAI Responses API. Anthropic y OpenAI ambos exponen metadatos de tool_use económicamente. Una recuperación de documentación es una superficie. Una llamada a API REST es otra. Un cargo de Stripe es una tercera. Emites una etiqueta por invocación de herramienta.
Enruta trazas a evaluadores específicos de superficie. Para documentación, inicia un LLM-como-juez que se fundamenta en fuentes recuperadas. Para APIs, usa pruebas de contrato—¿emitió el agente un esquema válido? Para comercio, reproduce contra el modo de prueba de Stripe y verifica la idempotencia de cargos. Cada evaluador tiene diferentes conjuntos dorados, diferentes rúbricas de puntuación y diferentes umbrales.
Almacena tasas de aprobación por superficie en Postgres con una vista de resumen. Nunca dejes que el agregado sea la puerta de despliegue. Conecta umbrales por superficie en CI: bloquea despliegues cuando la evaluación transaccional cae por debajo del 95% incluso si el agregado es 82%. El almacenamiento en caché respaldado por Redis de trazas doradas mantiene replays por superficie bajo un minuto.
Los equipos con los que hemos enviado esto tratan los resultados de evaluación por superficie de la misma manera que tratan los SLOs de producción—si cualquier superficie cae por debajo del umbral, el despliegue se bloquea, punto.
El cambio de infraestructura de evaluación que esto fuerza
Esto no es un cambio de configuración. Es un cambio de topología. Muévete de un único CLI de evaluación que ejecuta una gran suite de pruebas a una arquitectura de abanico: un despachador que enruta trazas entrantes a N ejecutores con alcance de superficie.
Los conjuntos dorados ahora versionan independientemente por superficie. Tu conjunto dorado de comercio cambia cuando la API de Stripe cambia, no cuando tu documentación se reescribe. Tu conjunto dorado de documentación evoluciona con tu estrategia de contenido, independiente de tus flujos de pago. Este desacoplamiento ahorra meses de trabajo de coordinación.
Los SLOs por superficie viven en el mismo panel que las métricas de producción—Grafana, Datadog, lo que uses. Las regresiones de evaluación y los incidentes de producción comparten vocabulario. Cuando tu evaluación muestra una caída de comercio, vive junto a tu tasa de error de Stripe en producción. La correlación es inmediata.
En términos de costo, las evaluaciones con alcance de superficie se ejecutan más frecuentemente pero en conjuntos más pequeños. Hemos encontrado que esto es generalmente más barato que ejecuciones monolíticas nocturnas. En términos de organización, el equipo de pagos posee la suite de evaluación de comercio, el equipo de DX posee documentación. No más cuello de botella del equipo central de evaluación decidiendo prioridad.
Por dónde empezar esta semana
No necesitas reconstruir todo a la vez. Hemos enviado esto en tres pasos, siempre comenzando con la superficie de mayor riesgo primero.
Paso uno: Instrumenta trazas existentes con una etiqueta de superficie. Toma una tarde con middleware de AI SDK. Si estás usando OpenAI Responses API, establece un campo personalizado en metadata. Registra la etiqueta en cada invocación de herramienta.
Paso dos: Extrae tus últimos 30 días de resultados de evaluación y re-divide por superficie. No te compliques con el agrupamiento—documentación, API, transacciones, cualquier otra cosa. Calcula tasas de aprobación por superficie. Encontrarás al menos una superficie ocultando un déficit de 20+ puntos. Escríbelo.
Paso tres: Elige la superficie de mayor riesgo (generalmente transaccional) e instala un evaluador dedicado con su propia puerta de despliegue. Haz que ese funcione antes de construir los otros. La topología de enrutamiento es la parte difícil, no los evaluadores individuales. Prueba el patrón en una superficie, luego replica.
Si quieres un segundo par de ojos en la capa de enrutamiento o la estrategia de conjunto dorado, hablemos.
Comienza con tu próxima ejecución de evaluación: divide por superficie de interacción y compara tasas de aprobación lado a lado. Si los deltas son mayores que 15 puntos, tu puntuación agregada te ha estado mintiendo. Esa brecha es donde se ocultan los fallos en producción.