Observabilidad de agentes en Grafana: el caso de Hermes

El domingo 16 de agosto, a las 08:40 UTC, alguien publicó en Show HN un repositorio llamado grafana-agento11y-hermes: una capa de observabilidad en Grafana para el agente Hermes. Cuando escribimos esto acumula un punto y cero comentarios. No hay hilo del que tirar, no hay demo viral, no hay discusión. Solo el código, en grafana-agento11y-hermes, y el envío en Hacker News donde pasó desapercibido.

Nos interesa precisamente por eso. La observabilidad de agentes es de esos problemas que nadie considera urgente hasta que tiene cuatro agentes en producción, una factura de tokens que no cuadra y ninguna forma de saber cuál de ellos entró en bucle a las tres de la mañana.

Qué hay realmente en el repositorio

Conviene ser preciso con lo que se puede afirmar. El proyecto se presenta como observabilidad basada en Grafana para un agente concreto, Hermes, no como un estándar ni como un producto con hoja de ruta. Sin hilo de comentarios ni notas de lanzamiento, lo honesto es leerlo como lo que es: alguien ha instrumentado su propio agente, ha montado los paneles que necesitaba y ha decidido publicarlos. Ese formato de "aquí está mi stack, cógelo si te sirve" ha movido históricamente más el ecosistema que la mayoría de anuncios corporativos.

Por qué importa medir un agente

Un agente no se rompe como se rompe un servicio HTTP. Un endpoint devuelve 500 y lo ves. Un agente devuelve 200, tarda cuarenta segundos, llama once veces a la misma herramienta, se corrige a sí mismo, gasta 180.000 tokens y entrega algo que casi funciona. En un dashboard clásico de aplicación, eso es una petición correcta.

Las señales que sí sirven son otras:

tokens de entrada y salida por ejecución, no por día
número de iteraciones del bucle antes de terminar o de rendirse
latencia y tasa de error desglosadas por herramienta, no agregadas
cuántas ejecuciones acaban topando con el límite de pasos en lugar de con una respuesta
* coste por tarea completada, que suele ser la única cifra que entiende quien paga

OpenTelemetry lleva tiempo trabajando en convenciones semánticas específicas para sistemas GenAI (semconv gen-ai), y ahí está la parte aburrida y decisiva del asunto. Si la telemetría sale en un formato común, el panel de Grafana es casi un detalle de presentación. El trabajo real está en instrumentar el bucle del agente, no en elegir el color de la gráfica.

Cómo se traduce al stack de Claude

Para quien trabaja con Claude Code, el patrón es transportable sin mucho esfuerzo. Los hooks (PreToolUse, PostToolUse, Stop) son puntos de enganche naturales: un comando shell que escriba una línea por llamada a herramienta, con nombre, duración y resultado, ya da buena parte de lo que hace falta para un primer panel. Los subagentes se prestan a modelarse como tramos anidados, porque cada delegación tiene principio, fin y coste propio. Y los MCP servers son la frontera más rentable de medir: casi todos los fallos raros de un agente aparecen cuando cruza hacia una herramienta externa, no dentro del modelo.

Nada de esto obliga a adoptar el repositorio de Hermes. Obliga a aceptar que un agente en producción es un sistema distribuido con un componente no determinista, y a tratarlo como tal.

Para quién es útil

Si estás probando agentes en local, esto todavía no te hace falta. Si tienes agentes ejecutándose sin supervisión, en cron, en CI o de cara a un cliente, el coste de no medir ya lo estás pagando, solo que en forma de horas de depuración y de facturas que se explican a posteriori. También sirve como lista de la compra: aunque nunca clones el repositorio, mirar qué paneles montó otro es la forma rápida de descubrir qué métricas te faltan.

Es un repositorio pequeño, sin tracción y atado a un agente concreto, y aun así apunta al sitio correcto: el tooling de agentes ha corrido mucho más rápido que su instrumentación. En ElephantPink preferimos un panel feo que funcione hoy antes que esperar a que aparezca el estándar definitivo.