Cuando el que despliega es un agente: un ejemplo de por dónde se está abriendo la observabilidad

Imagina un equipo pequeño que ha dejado que su agente de código —Claude Code, Cursor, el que sea— se encargue de un problema conocido: el checkout de su tienda online completa menos pedidos de los que debería, y nadie tiene muy claro por qué. El agente investiga, propone un cambio (paralelizar dos comprobaciones que corrían una detrás de otra, la de fraude y la de dirección), lo despliega… y aquí es donde la mayoría de equipos se quedan a ciegas. ¿Mejoró de verdad la tasa de finalización? ¿O simplemente cambió el tráfico esa tarde y parece que mejoró? Sin una forma de medir antes y después con la misma vara, la respuesta es «yo creo que sí», que es la peor respuesta posible cuando quien tomó la decisión no fue un humano con criterio, sino un agente que actúa dentro de unos límites que tú le has puesto.

Esto lo he tenido presente estos días por un motivo muy concreto: bajo el último artículo de este blog, sobre IA causal en observabilidad, un lector firmado como JR dejó un comentario señalando justo este tipo de problema —cómo verificar de verdad que un diagnóstico o una mejora automatizada es correcta, y no una casualidad de la mezcla de tráfico—. Al mirar quién era, resultó ser el creador de Telemetry (telemetry.sh), una herramienta pensada exactamente para el escenario que describía. Me pareció un buen punto de partida para repasar qué ofrece este tipo de producto, qué dice la comunidad sobre el enfoque, y —lo que más interesante me parece— cómo encaja en un cambio más amplio: ahora que cualquier equipo puede tener a un agente escribiendo y desplegando código, la observabilidad se está abriendo en varios caminos distintos a la vez, y merece la pena entender por qué.

Qué resuelve telemetry.sh, en pocas palabras

La idea de telemetry.sh es sencilla de explicar aunque no siempre sencilla de aplicar bien: tú (o tu agente) registras eventos propios con la forma que tú decides —telemetry.log("checkout_attempt_completed", { status, duration_ms, release, step, customer_segment })—, la herramienta los guarda como datos consultables, y luego escribes SQL directo contra ellos para responder preguntas concretas:

sql

SELECT release,
  AVG(status = 'completed') completion,
  PERCENTILE_CONT(0.95) duration_p95
FROM checkout_attempt_completed
GROUP BY release

Volviendo al ejemplo del checkout: con ese evento ya instrumentado, comparar la release v42 contra la v43 después de paralelizar las comprobaciones es una consulta, no una intuición. En la demo que publican, la finalización sube de 62,6 % a 68,4 % y el p95 baja de 1,6 a 1,1 segundos entre una release y la siguiente — es un caso de laboratorio, pero ilustra bien el mecanismo: primero se despliega la medición, después el cambio, y solo entonces se compara con los mismos criterios. Ese orden —medir antes de tocar nada— es más importante que la herramienta concreta, y es justo el matiz que señalaba JR en su comentario: una mejora después de un cambio no prueba causalidad por sí sola si también cambió la mezcla de tráfico u hubo otra intervención a la vez.

Lo que hace que esto encaje especialmente bien con agentes de código es que telemetry.sh publica su propio skill.md —un fichero de instrucciones que un agente como Claude Code puede leer para saber qué comando ejecutar y qué tabla consultar—, siguiendo el mismo estándar abierto de agent skills que ya usan Anthropic o Vercel. En la práctica, esto significa que el propio agente que hizo el cambio puede ser quien redacte después la consulta de verificación, cerrando el círculo sin que un humano tenga que ir a comprobarlo a mano cada vez.

Lo que dice la comunidad: un debate que no es nuevo

Cuando telemetry.sh se presentó en Hacker News en agosto de 2024 —antes de que existiera todo este discurso de «agentes»—, alguien preguntó lo obvio: ¿por qué no auto-instrumentar como hacen Datadog o New Relic, en vez de obligar a registrar los eventos a mano? La respuesta del fundador merece citarse porque resume toda la filosofía del producto: defendía que hay un segmento de gente a la que le gusta saber exactamente qué está midiendo, porque las herramientas que instalan un agente y recogen métricas automáticamente dan una experiencia de arranque estupenda, pero hacen más difícil saber qué datos tienes realmente y cómo consultarlos. Frente a eso, telemetry.sh apuesta por un modo «manual shift»: tú decides el evento, tú escribes la consulta.

Es un debate que cualquiera que haya configurado Dynatrace OneAgent reconocerá al instante, solo que trasladado a un contexto nuevo. Y no hay un bando «correcto»: la auto-instrumentación te da cobertura instantánea a costa de una caja negra sobre qué se mide de verdad; el registro manual te da control total del esquema a costa de que si no registras el evento, no hay SQL que lo arregle después. Con agentes de código de por medio, ese segundo punto cambia de peso: un agente puede escribir la instrumentación tan rápido como el propio cambio, así que el coste de «hacerlo a mano» empieza a diluirse.

Dos años después de aquel debate, quien ha usado telemetry.sh en producción cuenta cosas coherentes con esa filosofía de partida. En los testimonios que recoge la propia web —los fundadores de Browserflow, LogSnag y SwiftCX, todos ellos con productos pequeños construidos por equipos reducidos— se repite la misma idea con distintas palabras: lo que valoran no es la automatización total, sino no tener que preocuparse por el esquema de antemano y poder consultar sus propios datos con SQL directo en cuanto los necesitan. Es una audiencia todavía de nicho —founders solitarios y equipos pequeños, no departamentos de SRE de una gran corporación—, pero es justo el perfil que más se beneficia de un agente de código que puede instrumentar y consultar por su cuenta: alguien sin tiempo ni gente para montar un stack de observabilidad tradicional.

El otro camino: cuando la observabilidad se queda en tu propia máquina

Buscando quién más está atacando este mismo problema, apareció un contraste que dice más que cualquier comparativa de producto: agent-telemetry, un proyecto de código abierto que resuelve «¿qué hizo de verdad mi agente?» desde el extremo opuesto —nada de servicio hospedado, todo se queda en tu máquina—:

Claude Code
    │  OTLP/JSON sobre loopback :4318
    ▼
receptor local (≈180 líneas, solo node:http)
    │
    ├──▶ ~/.telemetry/raw/*.jsonl      (append-only, nunca se reescribe)
    ▼
normalización incremental e idempotente
    ▼
~/.telemetry/telemetry.db  (SQLite, vía node:sqlite)
    │
    ├──▶ servidor MCP   ── ocho herramientas de solo lectura
    └──▶ telemetry sql  ── consultas ad-hoc

Cero dependencias en tiempo de ejecución, un binario local, una base SQLite que nunca sale de tu ordenador, y ocho herramientas MCP de solo lectura que el propio Claude Code puede consultar en plena sesión para responder cosas como «¿cuánto costó esta sesión?» o «¿qué skill instalada nunca llegó a dispararse?». Su documentación es explícita sobre dónde recae la responsabilidad: ninguna de sus ocho funciones devuelve un veredicto, solo hechos y recuentos — el juicio, dicen literalmente, «vive en quien pregunta», no en la herramienta.

Es un proyecto todavía joven y de autoría individual —apenas ha empezado a recorrer su camino, como le pasa a casi cualquier idea el primer día—, así que conviene leerlo como una propuesta bien planteada más que como algo con adopción medible por ahora. Pero el contraste es el punto interesante: dos formas de responder a la misma pregunta —qué hizo de verdad un agente y si sirvió de algo— que se separan justo en el eje que más importa hoy en observabilidad: ¿los datos viven en un servicio de terceros consultable por SQL, o se quedan enteramente en tu máquina y es el propio modelo con el que ya estás hablando quien los interpreta al vuelo? Ninguno de los dos enfoques es superior en abstracto; dependen de si tu prioridad es compartir esa evidencia entre un equipo (telemetry.sh) o de si prefieres no sacar nunca esos datos de tu portátil (agent-telemetry).

Por qué esto importa más allá de estas dos herramientas

Lo que de verdad está pasando en 2026 no es que haya aparecido una herramienta más de observabilidad — es que el mercado se ha llenado de agentes escribiendo código y de productos enteros construidos casi de principio a fin por agentes, y eso obliga a repensar qué significa «observar» un sistema. Cuando el autor del cambio ya no es una persona que puede explicarte por qué lo hizo, la pregunta deja de ser solo «¿qué pasó?» y pasa a ser también «¿cómo sé que lo que decidió el agente fue lo correcto, y no solo lo que parecía correcto con los datos que tenía a mano?». Eso es exactamente lo que estaban discutiendo tanto el artículo de IA causal como el comentario de JR bajo él, y es la razón por la que herramientas como telemetry.sh —o su opuesto local, agent-telemetry— vale la pena mirarlas con calma: no tanto por si «ganan» en el mercado, sino porque cada uno responde de una forma distinta a la misma pregunta de fondo, y esa bifurcación de caminos —hospedado vs. local, esquema manual vs. auto-instrumentado, veredicto automático vs. juicio humano— es probablemente el tema que va a definir esta parte de la observabilidad los próximos años, más que cualquier nombre de producto concreto.

Si algo se puede llevar de aquí para aplicar mañana mismo, sin depender de qué herramienta acabe eligiendo cada equipo, es el criterio que dejaba JR en su comentario: antes de aceptar que un cambio —lo haya desplegado un agente o una persona— mejoró algo de verdad, pide que junto a la conclusión queden registrados la consulta exacta, la ventana temporal, el número de casos y qué fuentes de datos faltaban en ese análisis. Es barato de pedir y es, con diferencia, lo que más distingue una mejora real de una casualidad de tráfico.

Fuentes

Autor

Deja un comentario

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.