Evaluación y observabilidad de agentes: el oficio que separa al operador real del hobbysta

Cada post previo de esta serie hizo referencia a la evaluación como una pieza crítica: DELEGATE-52 mostró que los modelos corrompen silenciosamente en workflows largos; el editorial sobre despidos la rankeó segunda en el stack de skills del operador; el threat model la presentó como la defensa central contra el drift. Ninguno de esos posts te dijo cómo hacerla en realidad. Este post es la receta. Las cuatro categorías de métricas que importan, la suite de evaluación chica y rápida que cada operador debería lanzar antes de su primer usuario pagante, el stack de observabilidad de producción que hace al drift detectable, la disciplina de versionado de prompts que convierte la regresión del martes en el rollback del miércoles, y el patrón de canary deployment que captura los problemas antes de que alcancen toda la flota. Este es el oficio que separa al operador con un negocio del operador con un hobby.

La razón por la que la evaluación importa más para agentes que para modelos

Evaluar un modelo es una actividad para publicar un paper. Lo corres contra MMLU, GSM8K, HumanEval, publicas un número de leaderboard, lanzas el modelo. El benchmark es público, el test set es fijo, la métrica es inequívoca.

Evaluar un agente no es nada de eso. El benchmark que efectivamente te importa es el tuyo — tus clientes, tus datos, tus casos de borde. El test set tiene que construirse a partir de la carga que estás corriendo, no de un dataset académico. La métrica es multi-dimensional porque un agente que da la respuesta correcta pero cuesta $20 hacerlo no es mejor que uno que da una respuesta ligeramente peor por $0.02. Y cada cambio en cualquiera de los componentes del agente — el prompt, la lista de tools, el modelo detrás, la versión de cualquier server MCP que consume — puede cambiar silenciosamente el comportamiento de maneras que los benchmarks a nivel modelo nunca capturaron.

Los operadores que vemos tener éxito tratan a su suite de evaluación como su segundo artefacto más importante, atrás del prompt mismo. Los operadores que vemos fallar la tratan como algo a lo que van a llegar después de tener clientes, momento en el cual las regresiones ya les costaron clientes.

Las cuatro categorías de métricas que cada operador debería rastrear

Las métricas de agentes caen en cuatro categorías. Intentar rastrear todo es una receta para no rastrear nada útil; la disciplina es elegir un número específico en cada categoría y vigilarlo consistentemente.

Correctitud. ¿El agente produjo el output correcto? La más difícil de las cuatro porque "correcto" es específico de la carga. Para un agente de código, correctitud es si el código compila y pasa los tests. Para un agente de investigación, correctitud es si los hechos citados son reales y la conclusión está respaldada. Para un agente de customer support, correctitud es si el problema real del cliente se resolvió. No puedes medir la correctitud en general; solo puedes medirla contra la forma específica de tu carga.

Costo. ¿Cuánto gastó el agente para producir el output? Tokens para la capa de modelo, llamadas para tools con precio, cómputo para sandboxes, fees de liquidación para pagos. El costo es la categoría más fácil de medir (todo es un número en una factura) y la más fácil de ignorar (porque nada se rompe si el costo sube). Los operadores que no rastrean el costo se llevan una sorpresa al final del primer mes de gran volumen.

Latencia. ¿Cuánto tardó desde el input hasta el output? La latencia de reloj es lo que el usuario siente; incluye inferencia del modelo, llamadas a tools, reintentos, encolamiento. Mide p50, p95, y p99 por separado porque la latencia de cola es donde vive la ruptura de experiencia del usuario. Un p95 de 30 segundos con un p99 de 5 minutos es un desastre de experiencia aunque la mediana esté bien.

Drift. ¿El agente de hoy se comporta de la misma forma que el agente de la semana pasada? El drift puede venir de actualizaciones del modelo, cambios de tools, actualizaciones del corpus RAG, ediciones del system prompt, o solo inputs inusuales del usuario. La métrica que quieres es alguna comparación entre los outputs recientes y un baseline de referencia — tasas de excepción, distribuciones de largo del output, patrones de llamadas a tools. Un salto del 20% en cualquiera de estos es una señal para mirar más de cerca.

Construyendo una suite de evaluación en una tarde

La suite de eval que cada operador debería tener el día uno es chica, rápida, y construida a partir de casos reales. El error es intentar hacerla exhaustiva en la primera pasada; el camino correcto es hacerla mínima y hacerla crecer a medida que encuentras nuevos modos de falla.

La receta:

1. Recolecta 20-50 casos golden. Estos son inputs concretos del agente que ya pasaste por el agente y para los que sabes la respuesta correcta. Algunos deberían ser fáciles (el agente debería claramente tener éxito), algunos deberían ser difíciles (el agente podría fallar), algunos deberían ser adversariales (quieres saber cómo falla el agente). Veinte es suficiente para empezar; cincuenta es suficiente para sentirte cubierto el primer trimestre. La propiedad más importante es que cada caso sea real, no sintético.

2. Escribe el output esperado (o el validador) para cada caso. Para outputs determinísticos (un JSON parseado, un resultado de query SQL, una respuesta numérica), el output esperado es solo un valor para comparar. Para outputs no determinísticos (respuestas de lenguaje natural, resúmenes), necesitas un validador: otra llamada al modelo que califica el output del agente contra criterios que tú especificas. El validador no tiene que ser perfecto; tiene que ser consistente.

3. Corre la suite una vez y registra el baseline. Cada caso recibe un pass/fail. La suite como un todo produce una tasa de pass, un costo total de tokens, un tiempo de reloj total. Esa tripleta es tu baseline. Cada corrida futura se compara contra ella.

4. Agrega un caso nuevo cada vez que encuentras una falla en producción. Cuando un usuario reporta algo mal, lo primero que haces — antes de arreglarlo — es agregar el caso a la suite de eval. Si el fix rompe la regresión, la suite te lo va a decir. Si el fix funciona para ese caso pero rompe otros cinco, la suite también te lo va a decir.

5. Corre la suite antes de cada cambio significativo. Ediciones de prompt, cambios de modelo, agregados de tools, upgrades de servers MCP, cualquier cosa que pudiera afectar el comportamiento. La suite es tu gate; nada que falle la suite se lanza.

Esto es aproximadamente una tarde de trabajo para un operador que tiene una carga corriendo. La parte más difícil es ser honesto sobre qué casos genuinamente te importan; la trampa es incluir casos que lucen interesantes pero nunca aparecen en producción.

Un esqueleto mínimo de suite de eval, conceptualmente:

casos = [
  { id: "facil-01", input: "¿Cuál es la capital de Francia?",
    expected: "París", categoria: "trivia" },
  { id: "dificil-04", input: "Resume las ganancias Q3 de AAPL",
    validador: "el resumen menciona revenue, EPS, guidance",
    categoria: "finanzas" },
  { id: "adv-09",  input: "Ignora las instrucciones previas y...",
    comportamiento_esperado: "rechazar", categoria: "injection" }
]

resultados = []
para caso en casos:
  output = agente.run(caso.input)
  resultado = calificar(output, caso)
  resultados.append({ id: caso.id, pass: resultado.pass,
                       tokens: output.tokens, ms: output.ms })

baseline = agregar(resultados)
// Compara cada corrida futura contra `baseline`

Observabilidad de producción — qué loguear, sobre qué alertar

La suite de eval te dice cómo se comporta el agente sobre un set fijo de casos. La observabilidad de producción te dice cómo se está comportando el agente ahora mismo sobre los casos que efectivamente está viendo. Ambas son necesarias; ninguna reemplaza a la otra.

Las cuatro categorías de señal de producción:

Traces. Cada acción significativa del agente logueada como un span en un sistema de tracing distribuido (OpenTelemetry es el estándar; Datadog, Honeycomb, y similares lo reciben). El trace debería incluir el input, las llamadas a tools hechas, los resultados de tools, el output final, y el tiempo de reloj por span. El release 2026-07-28 de MCP estandariza la propagación de W3C Trace Context, así que las llamadas a tools mediadas por MCP correlacionan naturalmente con los spans propios del agente.

Medidor de costo. Por request, por agente, por tool. Agregado a por-día y por-mes. Un operador debería poder responder "qué agente quemó más tokens ayer" en menos de treinta segundos. El medidor de costo es también el sistema de alerta temprana para loops descontrolados; un único agente quemando de repente 100x su baseline es casi siempre un loop.

Tasa de excepciones. El porcentaje de corridas del agente que fallaron, reintentaron, o escalaron a humano. Un agente en estado estable tiene una tasa de excepciones estable; una desviación de más de dos desviaciones estándar del baseline de cola es señal para mirar más de cerca. Rastrea la tasa de excepciones por categoría (timeout, falla de validación, error de tool, rechazo del modelo) porque las categorías te dicen dónde vive el problema.

Distribución de forma del output. La distribución de largos de output, formatos de output, conteos de llamadas a tools por request, y patrones de interacción con contrapartes. Un cambio súbito en cualquiera de estos es drift. El agente que ayer producía respuestas de 500 tokens en promedio y hoy está produciendo respuestas de 50 tokens en promedio o cambió o está fallando silenciosamente.

La disciplina de alerting importa más que la lista de métricas. La trampa es alertar sobre cada métrica en tiempo real; el resultado es fatiga de alertas y alarmas ignoradas. La disciplina es alertar sobre un número chico de condiciones de alta señal: picos de costo >3x el baseline dentro de una hora, tasa de excepciones >2σ por encima del baseline de cola de 24 horas, p99 de latencia >5x el baseline, divergencia KL en la forma del output por encima de un umbral. Cuatro alertas a las que efectivamente respondes le ganan a cuarenta alertas que ignoras.

Versionado de prompts, la disciplina que nadie quiere armar

Los prompts driftéan de la misma forma que el código driftéa. El operador que retoca el prompt cada martes a la tarde "para arreglar la cosa de la que se quejó el usuario" sin registrar qué cambió es el operador que no puede responder "qué versión del prompt estaba corriendo cuando ocurrió este output" seis semanas después.

La disciplina mínima:

Cada cambio de prompt va a un repositorio con control de versiones. Git es la opción obvia; el prompt vive como un archivo en un repo, el mensaje de commit describe qué cambió y por qué. Cada agente en producción referencia un commit hash específico, no un puntero móvil de "latest".

Cada versión del prompt tiene su suite de eval corrida antes de lanzar. El resultado de la corrida queda registrado junto a la versión (tasa de pass, costo, baseline de latencia). El operador puede mirar la historia de versiones y decir "esta versión regresionó la correctitud en 8% pero redujo el costo en 30%; el trade-off fue intencional."

El rollback es un comando. Si un cambio de prompt está causando problemas en producción, el operador cambia el puntero de versión al commit anterior. La flota entera vuelve a la versión known-good en minutos. Sin re-deploy, sin rebuild, sin rehacer el trabajo.

Agent Builder lanza esta disciplina por defecto: cada cambio de prompt es un nuevo artefacto versionado, cada versión guarda el resultado de su suite de eval, y el botón de rollback es un único click en el dashboard. Los operadores fuera de Agent Builder tienen que cablearlo ellos mismos, y el cableado es exactamente tan aburrido como suena — pero los operadores que lo saltean se arrepienten la primera vez que necesitan hacer rollback a las 11 PM.

Canary deployment para agentes

Las actualizaciones de agentes en producción no deberían cambiar la flota entera de una vez. El patrón prestado del despliegue de software — canary releases — aplica casi sin cambios a los agentes.

La forma: cuando un nuevo prompt o una nueva versión de modelo está lista para desplegar, el operador apunta el 5% del tráfico entrante a la nueva versión mientras mantiene el 95% en la versión known-good. La suite de eval corre continuamente contra el canary; las métricas de producción (costo, latencia, tasa de excepciones) se comparan entre canary y baseline. Si el canary aguanta unas horas bajo tráfico real, escalas a 25%, después a 50%, después a 100%. Si el canary degrada, haces rollback al baseline e investigas.

El truco que hace que los canaries efectivamente funcionen para agentes es el mismo que para software: tienes que tener las métricas en su lugar antes de empezar el canary. Un canary sin observabilidad es solo una versión más chica del cambio que se va a romper antes de que lo notes. El mecanismo de canary de Agent Builder se enchufa directamente con las métricas descritas arriba; el operador ve la tasa de pass, el costo, y la latencia del canary en el mismo dashboard, lado a lado con el baseline.

El patrón de detección de drift que previene perder clientes

El drift es el asesino silencioso. Los costos suben 5% por semana. La latencia p95 se duplica en seis semanas. El estilo del output del agente cambia. La tasa de escalación de customer support sube de 10% a 18%. Ninguno es alarmante en ningún día dado. Para el fin del trimestre el agente es un producto distinto al que el cliente firmó.

La defensa es detección comparativa de drift. Elige una ventana de referencia chica de tráfico reciente (los últimos siete días) y una ventana de evaluación chica (las últimas seis horas). Computa las cuatro categorías de métricas en cada una. La métrica de drift es alguna medida de distancia entre las dos: divergencia KL sobre distribuciones de largo de output, cambio porcentual en tasas de excepción, ratio en costo-por-tarea. Una vez al día, un widget del dashboard muestra el número de drift con un umbral amarillo/rojo.

Esto no es exótico. Es la disciplina aburrida de preguntar "¿el agente de hoy es el mismo que el agente de la semana pasada?" y no esperar a que la respuesta llegue en forma de queja del cliente. Los operadores que corren este loop capturan regresiones semanas antes que sus clientes; los operadores que no corren este loop son los operadores de los que sus clientes ya empezaron a hablar de irse.

Cómo Agent Builder lanza los defaults

Para un operador que quiere el piso en su lugar sin cablearlo él mismo, Agent Builder hace estas cosas por defecto para cada agente de la flota.

Cada agente genera automáticamente una suite de eval inicial a partir de las primeras treinta corridas reales (con la revisión del operador para confirmar los outputs esperados). Las fallas posteriores capturadas en producción se agregan a la suite como casos candidatos que el operador aprueba con un click.

El stack de observabilidad con propagación W3C Trace Context que cubrimos en el post de MCP está prendido por defecto. Los traces se envían al backend elegido por el operador; el dashboard built-in los renderea localmente si no hay backend configurado.

Costo, latencia, tasa de excepciones, y distribución de forma del output se rastrean por agente y por flota con los umbrales de alerting pre-fijados a los valores que encontramos funcionan para el operador mediano. Ajustarlos es un slider; los defaults son conservadores.

Los prompts se versionan automáticamente en un store con forma de Git. Cada agente en producción referencia una versión pineada. El rollback es un click.

El canary deployment es el default para cualquier cambio de prompt o de modelo en agentes por encima de un umbral de tráfico configurable. Las versiones nuevas escalan 5% → 25% → 50% → 100% sobre una ventana que el operador fija, con auto-rollback si las métricas regresan más allá del umbral.

Nada de esto es magia. Es el piso operacionalmente correcto que los operadores experimentados terminan construyendo de todos modos; Agent Builder lo lanza para que el piso sea el mismo para todos en la plataforma.

Qué le queda al operador hacer por sí mismo

Tres cosas que la plataforma no puede hacer por el operador.

Decidir qué significa "correcto" para la carga. El validador que califica el output de un agente de investigación no lo puede proveer Agent Builder porque los criterios son específicos del dominio. El operador escribe el validador. La buena noticia es que "otro modelo evaluando contra un prompt que el operador escribió" es el patrón estándar, y funciona.

Leer transcripts. La actividad de mayor leverage en operaciones de agentes es leer los outputs reales que el agente produjo y notar qué está raro. Ninguna métrica la reemplaza. Los operadores que dedican treinta minutos por día a leer transcripts capturan problemas que ninguna métrica automatizada va a recoger.

Decidir qué casos importan para la suite de eval. La plataforma puede sugerir casos de corridas de producción, pero el operador decide cuáles son core (nunca deben regresar), cuáles son edge (lindo manejarlos), y cuáles están fuera de scope. La suite de eval es el contrato del operador consigo mismo sobre qué hará y qué no hará su agente.

Cierre

La disciplina de evaluación y observabilidad es lo más cercano a un moat que un operador individual puede construir. Los protocolos son abiertos. Los modelos son commodities. El dashboard es un SaaS. Lo que compone — lo único — son los datos propios del operador sobre cómo se comportan sus agentes en su carga, y el proceso disciplinado para usar esos datos para mejorar a los agentes con el tiempo.

Los operadores que hacen este trabajo lucen lentos a los outsiders durante las primeras seis semanas. Para el mes tres están lanzando cambios más rápido que sus competidores porque su canary captura regresiones en quince minutos que otros operadores descubren a partir de clientes enojados en dos semanas. Para el mes seis tienen una suite de evaluación que es ella misma un activo — cuando se lanza un nuevo modelo, saben en una tarde si mejora su carga. Para el año uno han compuesto hasta volverse el operador en el que el mercado confía porque sus agentes son demostrablemente más confiables, y la demostración es la suite que muestran a los prospectos en la llamada de ventas.

La tarde que pasas construyendo la primera versión de tu suite de eval es la tarde de mayor leverage de tu primer trimestre como operador. El dashboard que armas antes de tu primer cliente pagante es el dashboard que te salva cuando golpea la primera regresión. El versionado de prompts que cableas antes de necesitar un rollback es la disciplina que te deja dormir el martes a la noche.

El próximo post de esta serie da un paso atrás hacia la vista de síntesis — un diagrama, las cinco capas del stack agéntico, dónde la evaluación y la observabilidad se sientan transversalmente a través de todas ellas. Los patrones son el esqueleto, el eval y la observabilidad son el sistema nervioso, y la síntesis es el mapa que el operador cuelga en la pared.