Un agente de IA mal instrumentado es una caja negra que gasta dinero. Las llamadas al modelo son caras, las llamadas a herramientas pueden ser caras también, y el flujo de decisión suele ser no determinista. Sin una instrumentación pensada para este tipo de sistema, cuando algo falla o cuando la factura llega más alta de lo esperado, el equipo se encuentra leyendo registros sueltos e intentando reconstruir la secuencia a mano. Después de año y medio operando agentes en productos con usuarios reales, tengo una lista bastante formada de qué hay que instrumentar primero, qué estándares han ido emergiendo y qué errores caros se evitan teniendo trazas bien hechas desde el primer día.
Por qué los sistemas clásicos no bastan
La observabilidad tradicional se construyó alrededor de servicios HTTP sincrónicos: una petición entra, ocurren llamadas a base de datos y a otros servicios, y una respuesta sale. Las trazas distribuidas capturan ese árbol de llamadas, las métricas cuentan peticiones por segundo y percentiles de latencia, y los registros dan contexto. Con ese conjunto, un equipo acostumbrado puede responder a la mayoría de preguntas operativas.
Los agentes rompen ese molde en tres aspectos. Primero, una sola entrada de usuario puede desencadenar decenas de llamadas al modelo encadenadas, con ramificaciones y bucles cuya estructura solo se conoce después de la ejecución. Segundo, cada llamada lleva asociado un coste económico explícito en tokens de entrada y salida, que importa tanto o más que la latencia. Tercero, el contenido de las entradas y salidas, a diferencia de un JSON de API normal, es relevante para depurar y a menudo necesario para entender por qué el agente tomó una decisión u otra. Instrumentar eso bien exige salir del molde tradicional y tomar decisiones específicas.
La primera capa: traza por ejecución
Lo primero que hay que tener es una traza por cada ejecución de agente, con cada llamada al modelo y cada llamada a herramienta como span anidado. Esto suena obvio pero es sorprendente cuántos equipos operan sin ello y se dan cuenta solo cuando la factura del proveedor les llega disparada y no pueden decir qué ejecuciones consumieron qué. OpenTelemetry ha consolidado durante 2025 un conjunto de convenciones semánticas para IA generativa que define cómo nombrar los spans, qué atributos usar y cómo representar la relación entre el agente y las herramientas que invoca. Todos los SDK principales de LLM (OpenAI, Anthropic, Google, Azure) tienen ya instrumentación automática que emite estos spans sin cambios de código o con cambios mínimos.
Lo que hay que capturar en cada span de llamada al modelo es el nombre del modelo, los parámetros de muestreo (temperatura, tope de tokens), los tokens de entrada y salida contados, el coste estimado en la moneda del proveedor, el tiempo de primera emisión si es streaming, el tiempo total y, crucialmente, los mensajes de entrada y el texto o llamadas a función de salida. Este último punto es delicado porque esos contenidos pueden incluir datos personales, y la configuración debe permitir redactarlos o hasharlos según la política de la organización.
Para cada llamada a herramienta, el span debe capturar el nombre de la herramienta, los argumentos, el resultado o error, y el tiempo invertido. Una herramienta que consulta una API externa hereda además sus propias trazas, así que el contexto de OpenTelemetry debe propagarse hasta ahí para poder ver el árbol completo de lo que pasa cuando el agente tira de una función.
La segunda capa: métricas agregadas
Trazas sueltas no dan la foto. Hacen falta métricas agregadas que permitan mirar el comportamiento del sistema en conjunto. Las cinco que instrumento siempre son: coste por conversación en la moneda del proveedor, latencia de extremo a extremo vista por el usuario, tasa de finalización exitosa frente a abandono o error, número medio de pasos por conversación y tasa de uso de herramientas por paso. Con esas cinco se puede responder a las preguntas operativas habituales sin bucear en trazas individuales: si el coste medio sube de repente, si una versión nueva del modelo empeora la tasa de finalización, si una herramienta nueva está dando problemas o se está sobreusando.
A partir de ahí vienen métricas más específicas del dominio. Si el agente tiene un camino feliz esperado, por ejemplo una reserva completada o una consulta resuelta, conviene instrumentar la tasa de éxito en ese camino. Si hay interacción humana, conviene medir la tasa de escalado a humano. Si hay presupuestos por usuario, conviene alertar cuando una conversación se acerca al límite. Estas métricas son las que traducen el comportamiento del agente en algo que entienden producto y operaciones.
La tercera capa: evaluaciones sobre producción
La observabilidad clásica termina ahí, pero los agentes necesitan una capa más: evaluaciones que se ejecutan sobre las conversaciones reales o muestras de ellas para medir calidad. No basta con saber que la conversación terminó; hay que saber si terminó bien. Las técnicas en uso son variadas: anotación manual de muestras, juicios por modelo (LLM como juez) contra criterios definidos, comparación contra un conjunto de referencia, detección de patrones específicos como rechazos innecesarios o alucinaciones detectables.
Las evaluaciones automáticas sobre producción tienen un coste computacional real y exigen una política clara: qué se evalúa, cada cuánto, con qué modelo y qué se hace con los resultados. Lo que he visto funcionar es una pirámide: una fracción pequeña de conversaciones evaluadas por humanos, una fracción mayor evaluada por un modelo juez, y el resto con métricas heurísticas baratas. Los tres niveles se calibran entre sí periódicamente para asegurar que el juez automático no se desvía de los humanos de referencia.
El patrón de fallo más común
El fallo más caro que he visto en equipos operando agentes en producción es no tener forma de responder a la pregunta “por qué esta conversación costó treinta euros”. La conversación ocurrió, el coste está en la factura, pero los registros no contienen el detalle suficiente para decir si fue un bucle del agente, un prompt del usuario que llenó la ventana de contexto, una herramienta mal configurada o un modelo escogido mal. Sin esa trazabilidad el equipo no puede evitar que vuelva a pasar, y la factura mensual de LLM se convierte en una caja negra que crece sin explicación.
La cura es instrumentar desde el primer día, aunque parezca un sobrecoste. Los agentes empiezan pequeños y crecen rápido; montar las trazas cuando ya tienes miles de conversaciones diarias es mucho más caro que haberlo hecho al principio. Y el esfuerzo es modesto: OpenTelemetry tiene instrumentación automática para los SDK principales, y las herramientas comerciales de observabilidad de agentes (Langfuse, Helicone, Phoenix, Weave y similares) se enchufan con pocos cambios de código.
Una ruta mínima
Para un equipo que empieza hoy con un agente en producción, la ruta mínima que recomiendo es clara. Primero, activar instrumentación OpenTelemetry en el SDK del modelo usado, con las convenciones semánticas de IA generativa. Segundo, enviar esas trazas a un backend que entienda conversaciones, Langfuse o similar funcionan bien, o a un Grafana Tempo con paneles hechos a mano si prefieres autohospedado. Tercero, definir cinco métricas de negocio básicas y ponerlas en un panel visible. Cuarto, instalar una evaluación automática sencilla, aunque sea un modelo juez con tres criterios, sobre una muestra del tráfico.
# Ejemplo mínimo con instrumentación OpenTelemetry automática
from opentelemetry import trace
from opentelemetry.instrumentation.openai_v2 import OpenAIInstrumentor
import openai
OpenAIInstrumentor().instrument()
tracer = trace.get_tracer("agente.reservas")
with tracer.start_as_current_span("conversacion", attributes={"usuario.id": uid}) as span:
respuesta = openai.chat.completions.create(
model="gpt-4o-mini",
messages=mensajes,
tools=herramientas,
)
span.set_attribute("agente.pasos", len(respuesta.choices[0].message.tool_calls or []))Ese cuarteto cubre el ochenta por ciento del valor. Después se añaden capas más finas según crece el sistema: trazas propagadas a herramientas internas, presupuestos por usuario, evaluaciones comparativas entre versiones del modelo, alertas específicas. Todo eso tiene sentido cuando ya hay un sistema vivo al que observar; antes de eso es sobreingeniería.
Mi lectura
La observabilidad de agentes pasó en 2025 de ser un hueco incómodo a tener respuestas aceptables. Las convenciones semánticas de OpenTelemetry para IA generativa, la maduración de plataformas como Langfuse y Phoenix, y la incorporación de instrumentación automática en los SDK de los proveedores grandes hacen que el coste de entrada sea hoy asumible incluso para equipos pequeños. No hay excusa para operar agentes a ciegas.
Lo que falta todavía es estandarización plena en cómo representar estados intermedios del agente, ramificaciones de planeamiento y memoria persistente. En eso el ecosistema está moviéndose rápido y las convenciones cambiarán en los próximos dieciocho meses. Lo prudente para un equipo es adoptar las convenciones actuales asumiendo que habrá migración; la alternativa, construir algo propio desde cero, casi nunca envejece bien. Instrumentar pronto, instrumentar con convenciones abiertas, y revisar cuando aparezcan versiones más consolidadas es la política que mejor me ha funcionado.
