El harness mínimo de evals para un agente de IA en producción (casi nadie lo hace)
Un harness mínimo son cinco piezas: un set curado de 15 a 50 tareas reales con resultados esperados, evals offline en CI en cada cambio, unas pocas verificaciones automatizables (match de salida estructurada, una rúbrica con LLM-como-juez, corrección de tool-calls), evals online sobre una muestra del tráfico real, y un ciclo donde las fallas se vuelven casos nuevos. No necesitas plataforma: un archivo de tests y tus trazas le ganan a dashboards sin calificaciones.
La brecha de 2026: los equipos observan sus agentes pero no los califican
Hay un dato que me dejó pensando. En el reporte State of Agent Engineering 2026 de LangChain encuestaron a 1,340 profesionales (entre el 18 de noviembre y el 2 de diciembre de 2025) y salió un hueco enorme: los equipos saben ver lo que hacen sus agentes, pero casi no saben calificarlo.
Los números del reporte: el 89% ya implementó observability para sus agentes y el 62% tiene tracing detallado. Es decir, la mayoría puede mirar exactamente qué pasó en cada corrida. Pero las evals se quedan atrás: solo el 52.4% corre evals offline sobre sets de prueba, y apenas el 37.3% corre evals online sobre tráfico real. Mientras tanto, el 57.3% ya tiene agentes en producción y cerca de un tercio dice que la calidad es su mayor barrera para desplegar más.
La distinción que ordena todo este post: la observability te dice qué pasó; las evals te dicen si estuvo bien. La mayoría tiene lo primero y se salta lo segundo.
Opinión, y la marco como tal: lanzar un agente que puedes observar pero no calificar es lanzar a ciegas con un dashboard bonito. El dashboard te enseña que el agente llamó una herramienta y respondió en 1.2 segundos. No te dice si la respuesta era correcta. Esa es justo la parte que le cuesta dinero a tu negocio.
La brecha de 2026: observan pero no califican
Observabilidad vs evals: qué pasó vs si estuvo bien
Vale la pena separar bien estos dos conceptos, porque se confunden todo el tiempo y no son sustitutos.
Observability son trazas, logs, spans, latencia, costo en tokens. Te responde “qué pasó en esta corrida”. Es material crudo: puedes ver que el agente recibió un mensaje, decidió llamar una herramienta, recibió un resultado y respondió.
Evals son un veredicto calificado contra un comportamiento esperado. Te responden “esa salida, ¿estuvo correcta/buena?”. Toman una muestra de esas trazas y les ponen una nota.
La diferencia se ve clarísima con un ejemplo. Una traza que muestra que se disparó un tool-call no te dice nada sobre si fue la herramienta correcta con los argumentos correctos. Puedes ver con todo detalle que tu agente llamó la herramienta de reembolsos; solo una eval te dice que reembolsó el monto correcto al cliente correcto. La traza te da tranquilidad falsa: “sí hizo algo”. La eval te da la verdad: “hizo lo bueno” o “metió la pata”.
Por eso necesitas las dos. La observability te da las trazas; las evals convierten una muestra de esas trazas en calificaciones.
Observability — qué pasó
- Trazas, logs y spans
- Latencia y costo en tokens
- Muestra que se disparó un tool-call
- No sabe si fue el tool correcto
- Material crudo de cada corrida
Evals — si estuvo bien
- Veredicto contra lo esperado
- Califica la salida (correcta/incorrecta)
- Verifica tool + argumentos correctos
- Detecta el monto o cliente equivocado
- Convierte trazas en notas
Paso 1: arma un set de evals con 15 a 50 tareas reales
Aquí empieza el harness. Y la primera regla es contraintuitiva: no arranques con un benchmark público gigante. Arranca con 15 a 50 tareas reales sacadas de tu propio tráfico.
Cada caso necesita dos cosas: un input y un resultado esperado. El resultado esperado puede ser una respuesta exacta, un tool-call esperado, o criterios de una rúbrica. Nada más.
¿De dónde sacas los casos? De tus trazas de producción y de tus tickets de soporte. Ahí están los casos que de verdad ocurren y, sobre todo, los que se rompieron. Esos son oro.
En LATAM, que es mi terreno: para un agente de soporte o pagos en español, escribe los casos con el fraseo real en español mexicano que usan tus clientes — no traducciones del inglés. “¿Me pueden regresar mi dinero?”, “no me llegó el reembolso”, “quiero cancelar y que me devuelvan” no son lo mismo que un benchmark en inglés, y tu agente los va a enfrentar todos los días.
Opinión (marcada): 30 casos reales bien escogidos le ganan a un benchmark de 1,000 filas que no entiendes. El benchmark gigante se siente serio, pero te dice poco sobre tu agente.
Paso 2: corre evals offline en CI en cada cambio
Tener el set no sirve si lo corres una vez y lo olvidas. La disciplina es cablearlo a tu CI para que corra en cada edición de prompt, cada cambio de modelo, cada herramienta que agregues.
La idea: verifica que la tarea salió bien, no te guíes por la corazonada. Una eval que falla debe tronar el build igual que cualquier test. Si no truena el build, no es una gate — es un ritual.
Este es el 52.4% del reporte, pero el truco no es tener evals offline; es correrlas en cada cambio, no solo en el lanzamiento. Así atrapas regresiones antes de que lleguen a un cliente. Y ojo con esto: una actualización de modelo que mejora una tarea puede romper en silencio otras tres. Sin evals en CI, te enteras por el cliente.
En pagos: un ajuste de prompt que mejora el chat general puede romper la lógica estricta de elegibilidad de reembolso. CI lo atrapa antes de que tu agente le diga “sí, procede tu reembolso” a alguien que no califica.
# tests/test_evals.py — eval offline mínima en CI (ilustrativo)
import json
from mi_agente import run_agent # tu agente
# Set curado: 15-50 casos reales sacados de tus trazas
EVAL_SET = [
{
"id": "reembolso_fuera_de_plazo",
"input": "Compré hace 45 días, ¿me pueden regresar mi dinero?",
"expected_tool": "check_refund_eligibility",
"expected_outcome": "no_elegible", # política: 30 días
},
{
"id": "reembolso_valido",
"input": "no me llegó mi pedido, quiero mi reembolso",
"expected_tool": "create_refund",
"expected_outcome": "elegible",
},
# ... 15-50 casos en el fraseo real de tus clientes
]
def test_eval_set():
fallos = []
for caso in EVAL_SET:
res = run_agent(caso["input"])
# 1) tool-call correctness
if res.tool_called != caso["expected_tool"]:
fallos.append((caso["id"], "tool incorrecto", res.tool_called))
continue
# 2) match de resultado esperado
if res.outcome != caso["expected_outcome"]:
fallos.append((caso["id"], "resultado incorrecto", res.outcome))
# falla el build como cualquier test
assert not fallos, json.dumps(fallos, ensure_ascii=False, indent=2)Paso 3: elige unas pocas verificaciones automatizables
Ya tienes el set y el CI. Ahora, ¿cómo calificas cada caso? No necesitas un sistema elaborado: tres tipos de check cubren casi todo.
Match exacto / salida estructurada. Donde el agente devuelve JSON, valida contra un schema. La API de Anthropic usa output_config.format con type: "json_schema" (docs). Límite honesto y crucial: la salida estructurada garantiza la forma, no la verdad. Que el JSON tenga el campo monto no significa que el monto sea correcto. Sigues teniendo que validar los valores.
Rúbrica con LLM-como-juez. Para pasos abiertos, califica contra una rúbrica escrita. Por ejemplo: “¿citó la política correcta, en español, sin inventar una comisión?”. El juez te da una nota y una razón.
Corrección del tool-call. Verifica que el agente llamó la herramienta correcta con los argumentos correctos. Aquí el flag aparte strict: true aplica al tool use (valida los inputs de la herramienta contra su input_schema), distinto de output_config.format que controla el formato de la respuesta. Son cosas separadas; puedes usarlas juntas.
Lo práctico es mezclarlos por caso: un campo estructurado se lleva un check exacto; una explicación en texto libre se lleva el juez.
Límite honesto: un LLM-juez también se equivoca. Revisa sus calificaciones contra tu propio criterio cada cierto tiempo — es una herramienta para reducir riesgo, no para eliminarlo.
# Rúbrica con LLM-como-juez (ilustrativo, español-first)
import anthropic
client = anthropic.Anthropic()
RUBRICA = """Eres un evaluador estricto. Califica la respuesta del agente de soporte.
Criterios (todos deben cumplirse para PASS):
1. Cita la política de reembolso correcta (plazo de 30 días).
2. Responde en español claro.
3. NO inventa comisiones, montos ni plazos que no existen.
Devuelve solo el schema pedido."""
def juez(pregunta_cliente: str, respuesta_agente: str) -> dict:
msg = client.messages.create(
model="claude-opus-4-8",
max_tokens=512,
system=RUBRICA,
messages=[{
"role": "user",
"content": f"Cliente: {pregunta_cliente}\nAgente: {respuesta_agente}",
}],
# salida estructurada: garantiza la FORMA del veredicto, no su verdad
output_config={
"format": {
"type": "json_schema",
"schema": {
"type": "object",
"properties": {
"veredicto": {"type": "string", "enum": ["PASS", "FAIL"]},
"razon": {"type": "string"},
},
"required": ["veredicto", "razon"],
"additionalProperties": False,
},
}
},
)
return msg # parsea el JSON del bloque de salidaPaso 4: corre evals online sobre una muestra del tráfico real
Este es el paso que casi nadie hace: el 37.3% del reporte. Calificar tráfico real, no solo tu set de prueba.
No necesitas calificar cada request. Registras las trazas, calificas una muestra, y alertas si hay regresión. Con muestrear un porcentaje del tráfico ya empiezas a ver lo que tu set curado nunca anticipó.
Porque eso es lo que atrapan las evals online y las offline no: el drift. Fraseos nuevos de clientes, casos borde, cambios del proveedor de modelo que no anunciaron. Tu set curado es una foto; producción es una película que sigue cambiando.
En LATAM: tus clientes reales van a decir las cosas de formas que tu set jamás imaginó. Muestrear producción es cómo las encuentras — y luego las agregas al set (eso es el Paso 5).
En pagos: un alza silenciosa de reembolsos con monto equivocado, o de búsquedas fiscales fallidas (un RFC mal resuelto, un CFDI que no cuadra), aparece aquí antes de aparecer en el churn. Y soy ingeniero, no contador: las evals te avisan que la lógica fiscal se rompió, pero la regla fiscal correcta la valida tu contador.
Paso 5: cierra el ciclo — las fallas se vuelven casos nuevos
Aquí está el flywheel, la pieza que hace que el harness se potencie con el tiempo en vez de pudrirse.
Cada falla que atrapas en evals online (o en producción) se vuelve un caso nuevo en tu set offline. Con el tiempo, tu set de evals se convierte en un mapa preciso de dónde tu agente se rompe de verdad — no de dónde un benchmark genérico cree que se podría romper.
Esa es la diferencia entre un harness que se pudre y uno que crece. Sin el ciclo, tu set envejece y deja de representar tu tráfico. Con el ciclo, cada incidente te deja mejor armado que antes.
El harness mínimo de evals en 5 pasos
- Cura 15-50 casos realesDe tus trazas y tickets, en el fraseo real en español.
- Evals offline en CICorren en cada cambio de prompt/modelo/tool; fallan el build.
- Verificaciones automatizablesMatch estructurado, LLM-como-juez, corrección del tool-call.
- Evals online sobre muestraCalifica una muestra del tráfico real; alerta en regresión.
- Las fallas vuelven casosCada falla se agrega al set offline; el harness se fortalece con el tiempo.
Y el punto que más me importa: puedes arrancar esto esta semana, sin plataforma. Un archivo de tests, tus trazas existentes, una rúbrica de LLM-como-juez y un set de evals en español sobre el fraseo real de tus clientes. Eso es todo.
Opinión (marcada): un archivo de tests más tus trazas le gana a “tenemos dashboards pero no calificaciones”, siempre.
Arranca esta semana, sin plataforma
Preguntas frecuentes
¿Necesito una plataforma de pago de evals? No para arrancar. Un archivo de tests y tus trazas bastan. Las plataformas ayudan a escala, no al principio. La razón por la que la mayoría observa pero no califica suele ser que sobreplanean: esperan la herramienta perfecta en vez de escribir 30 casos hoy.
¿Cuántos casos son suficientes para empezar? De 15 a 50 casos reales le ganan a un benchmark gigante. Crece el set desde fallas reales, no desde lo que un dataset público cree que importa.
¿Las salidas estructuradas hacen innecesarias las evals? No. output_config.format con type: "json_schema" garantiza la forma, no la verdad. El JSON va a tener el campo monto; que el monto sea correcto lo sigues calificando tú.
¿Puedo confiar de lleno en un LLM-como-juez? Casi. Pero revisa sus calificaciones contra tu criterio cada tanto. Es una herramienta para reducir riesgo, no para eliminarlo.
¿Por qué evals en español? Porque un benchmark en inglés no captura cómo tus clientes mexicanos piden de verdad un reembolso. Evalúa sobre el fraseo real o estarás midiendo un agente que no es el tuyo.
¿No basta con observability? No. Te dice qué pasó, no si estuvo correcto. Esa brecha es justo el punto de todo este post.
Lanza el harness esta semana
Las cinco piezas son lo bastante chicas para lanzarlas en una semana: set curado, evals offline en CI, verificaciones automatizables, muestreo online y un ciclo de retroalimentación. Ninguna requiere una plataforma.
No esperes la herramienta perfecta. La mayoría de los equipos que observan pero no califican están atorados porque sobreplanearon. Empieza con el archivo de tests y crece desde ahí.
Y si construyes agentes de pagos en español, las evals sobre el fraseo real de tus clientes son tu ventaja — no las regales. Si te falta el paso anterior, aquí está cómo correr el LLM/agente en producción, qué verifican las evals: grounding sin alucinaciones, qué es el agente de IA que evalúas y más guías de agentes de IA.
Fuentes: LangChain — State of Agent Engineering · LangChain — agent observability powers agent evaluation.