Sentry muestra el hueco entre evals y trazas: el agente puede llamar tools y aun así inventar
Sentry publicó el 2 de julio de 2026 un caso práctico donde un modelo barato inventó speakers que la tool no devolvió. Para builders, la lección es que una eval detecta regresiones, pero leer trazas decide routing, costo y riesgo.
Por qué importa
Esta nota se enfoca en la decisión práctica para builders: qué cambia, qué riesgo agrega y cómo aplicarlo sin romper operación.
Sentry publicó el 2 de julio de 2026 un caso que vale más que otra promesa genérica de observabilidad: un agente de agenda para conferencias usó un modelo barato, llamó una tool real y aun así terminó inventando speakers. La trampa para builders es obvia. Si solo miras “la tool se llamó”, puedes creer que la respuesta quedó grounded. Sentry muestra lo contrario: el agente puede consultar datos, ignorar el vacío y rellenar con una historia plausible.
La nota no presenta un benchmark nuevo ni un producto aislado. Presenta una decisión operativa que muchos equipos ya están tomando: ¿cuándo conviene aceptar un modelo más barato, cuándo subir de modelo y cuándo arreglar routing, prompts o evals?
El fallo importante no fue la alucinación
La alucinación es el síntoma. El fallo de diseño es que el equipo no podía decidir con una sola métrica qué arreglar. Un eval de groundedness puede decir “esta respuesta menciona entidades que no existen en el output de la tool”. Eso es útil y debe entrar a CI. Pero la eval no decide si el modelo barato sigue siendo aceptable para usuarios anónimos, si el flujo debe enrutar esa pregunta a otra tool, o si el prompt necesita una regla explícita de “no nombres speakers si la base no los devuelve”.
Esa es la parte que Sentry aterriza bien. La traza incluye costo, latencia, modelo, user tier, input, output y cada tool call. Con eso, el equipo puede hacer una lectura menos dogmática:
- si el usuario está en una capa gratuita, quizá conviene mantener el modelo barato pero cerrar la ruta peligrosa;
- si la respuesta incorrecta tiene costo reputacional alto, hay que subir modelo o bloquear la respuesta;
- si la tool no trae el dato, la solución no es “más inteligencia”, sino decir que no hay evidencia.
Leer trazas no reemplaza evals
La mejor lectura es la inversa: las trazas te dicen qué eval vale la pena escribir. Sentry describe cómo una revisión manual del intercambio expuso una categoría de error que no estaba en el set inicial. Después de verla, el equipo puede convertirla en test repetible.
Eso importa para agentes en español y para productos pequeños en Latinoamérica. Muchos equipos no tienen miles de ejemplos etiquetados ni budget para correr evaluaciones gigantes. Sí pueden empezar con una práctica disciplinada: leer diez trazas reales por semana, agrupar fallos y promover los patrones repetidos a tests.
El punto de MCP en esta historia
Sentry también conecta el flujo con su MCP. Un agente de debugging puede buscar conversaciones de IA, traer detalles de una conversación y revisar tool calls dentro del mismo loop de investigación. Esa integración no hace magia, pero reduce una fricción real: encontrar la traza correcta antes de decidir el fix.
El riesgo es convertir MCP en otro fetiche. No basta con exponer una tool search_ai_conversations. El contrato útil debería incluir:
- identificadores estables de conversación;
- modelo y versión de prompt;
- user tier o contexto de negocio;
- output exacto de cada tool;
- decisión final del agente y resultado observable.
Sin esos campos, el agente de debugging solo tendrá más texto, no mejor evidencia.
Demanda e intención
No hay SEO tooling conectado en esta corrida, así que no invento volumen. La demanda se infiere por señales actuales: publicación oficial de Sentry, crecimiento de AI agent monitoring, adopción de MCP para depuración y búsquedas probables como agent traces, evals AI agents, groundedness check, Sentry MCP y debugging tool calls.
Agente IA puede competir porque la mayoría de notas de observabilidad se queda en “traza todo”. La lectura útil para builders es más específica: una eval detecta una regresión conocida; una traza bien leída decide qué costo, routing y riesgo aceptas.
Si todavía estás ordenando herramientas, permisos y validación básica, empieza por el curso gratis. Si ya tienes agentes con usuarios reales, esta debería ser la regla: ninguna decisión de modelo se toma solo por precio o benchmark; se toma leyendo trazas y convirtiendo los fallos repetidos en evals.