Introducción
Los agents de IA ya están en producción, pero cuando fallan no generan stack traces: se estancan en loops, alucinan respuestas plausibles o queman tokens sin progreso. Los equipos de DevOps descubren estos problemas cuando llega la factura de la cloud o un usuario reporta un resultado incorrecto. El APM tradicional — designed para microservicios y requests HTTP — no responde preguntas clave como por qué el agent hizo la misma consulta tres veces o qué decisión llevó a una secuencia de tool calls costosa. Sin visibilidad interna, debuggear agents es como buscar un bug en una caja negra.
La observabilidad para agents requiere un enfoque distinto: trazas que capturen el flujo de decisión completo (cada call al modelo, cada invocación de tool, cada delegación a sub-agents), métricas de costos en tiempo real y logs estructurados que permitan reconstruir sesiones sin exponer datos sensibles. No se trata de sumar más dashboards, sino de instrumentar los agents para generar datos accionables.
Qué ocurrió
Equipos que deployearon agents de IA en producción (según el reporte del CNCF) descubrieron que las herramientas de monitoreo existentes — Prometheus, Grafana, OpenTelemetry — no cubren las necesidades específicas de estos sistemas. Por ejemplo:
- Loops ocultos: Un agent quedó atrapado pidiendo la misma información a un tool en bucle porque la respuesta no coincidía con sus expectativas internas. El APM mostraba un aumento en el tiempo de respuesta, pero no por qué ocurría.
- Costos inesperados: Un cambio en el prompt causó que el modelo invocara un tool costoso (como una búsqueda en un vector store) en cada iteración. El gasto se multiplicó 10x, pero solo se detectó al final del mes.
- Hallucinaciones subtiles: El agent generaba respuestas coherentes pero incorrectas debido a datos desactualizados en su contexto. Los logs no capturaban el estado interno del agent durante la sesión.
El problema central es que los agents son sistemas dinámicos: su comportamiento depende de la conversación previa, las respuestas de los tools y las decisiones del modelo. Las métricas agregadas (promedios, percentiles) ocultan estos flujos no lineales.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
Para los equipos de infraestructura, la falta de observabilidad en agents tiene consecuencias concretas:
- Costos imprevistos: Un solo agent mal configurado puede generar miles de dólares en gastos de LLM en horas. En un entorno con múltiples agents, esto escala rápidamente. Según el CNCF, equipos reportaron facturas hasta 50x mayores que lo estimado por falta de monitoreo de token usage.
- Degradación silenciosa: Los agents pueden fallar parcialmente (ej.: devolver resultados menos precisos) sin triggerear alertas de error. Esto afecta la experiencia de usuario sin dejar rastro en los sistemas tradicionales.
- Riesgos de seguridad: Si un agent delega tareas a sub-agents o interactúa con systems sensibles (ej.: APIs de cloud), una falla en su lógica podría llevar a acciones no autorizadas. Sin trazas detalladas, auditar estos flujos es casi imposible.
- Dificultad para escalar: Sin datos sobre el comportamiento real de los agents, es difícil dimensionar recursos (ej.: cuántas instancias deployear) o estimar costos para nuevos features.
Para los equipos de seguridad, la visibilidad es crítica para detectar prompt injections o abusos del agent (ej.: un usuario que lo convence de ejecutar commands arbitrarios). Los logs deben capturar tanto las entradas del usuario como las decisiones del model, pero sanitizando datos sensibles (como credentials en tool outputs).
Detalles técnicos
Trazas especializadas para agents
Cada sesión de un agent debe generar una agent trace que incluya:
- Spans por cada call al modelo: modelo usado, prompt, parameters (temperature, max_tokens), respuesta del model, latency y token count (input + output).
- Spans por cada tool invocation: nombre del tool, argumentos, resultado, latency y cost (si aplica).
- Spans para decisiones internas: ej.: classification steps, routing entre sub-agents, checks de governance.
- Relaciones jerárquicas: las trazas de sub-agents deben anidarse como children de la traza principal, para seguir el flujo de delegación.
Herramientas como Langfuse (usada en el reporte del CNCF) implementan este modelo. Ejemplo de estructura de una traza:
{
"trace_id": "agm-123",
"name": "customer_support_agent",
"spans": [
{
"span_id": "span-456",
"name": "llm_call",
"start_time": "2026-08-04T10:00:00Z",
"end_time": "2026-08-04T10:00:05Z",
"input": {"model": "gpt-4", "prompt": "Resuma el ticket #789..."},
"output": {...},
"metadata": {"tokens_input": 500, "tokens_output": 200, "cost": 0.03}
},
{
"span_id": "span-789",
"name": "tool_call",
"start_time": "2026-08-04T10:00:05Z",
"end_time": "2026-08-04T10:00:07Z",
"input": {"tool": "fetch_ticket", "arguments": {"id": "789"}},
"output": {...},
"metadata": {"cost": 0.01}
}
]
}- Non-blocking: El envío de spans no debe bloquear la ejecución del agent. Usar un batch exporter (ej.: OpenTelemetry con
BatchSpanProcessor) que bufferée spans en memoria y los flushee periódicamente (ej.: cada 1 segundo o al alcanzar 50 spans). - Graceful shutdown: Al apagar el agent, drenar los spans pendientes. En Python, usar un contexto de shutdown:
from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto grpc._exporter import OTLPSpanExporter
provider = TracerProvider()
exporter = OTLPSpanExporter(endpoint="otlp-endpoint:4317")
processor = BatchSpanProcessor(exporter)
provider.add_span_processor(processor)
tracer = provider.get_tracer("agent")
try:
# Código del agent
pass
finally:
processor.shutdown()
- Alta disponibilidad: Si el backend de trazas (ej.: Langfuse, Jaeger) falla, los spans se pierden, pero el agent debe seguir funcionando. Implementar un fallback a un buffer en disco para spans no entregados.
Métricas en Prometheus
Exportar métricas bounded a Prometheus para alerting y dashboards. Ejemplo de métricas útiles:
# Tokens usados por model y agent
agent_llm_tokens_total{model, agent} 1250
# Costo por sesión (en USD)
agent_session_cost_usd{agent} 2.45
# Éxitos/fallos de tools
agent_tool_calls_total{tool, status} 42 # status: success, error, timeout
# Latencia de approvals (para agents con human-in-the-loop)
agent_approval_latency_seconds{agent} 3600- Labels de baja cardinalidad:
agent,model,tool(valores limitados). - Evitar labels de alta cardinalidad:
session_id,user_id,trace_id. Estos belongs a logs o trazas, no a métricas.
Logs estructurados
Loggear cada evento importante con campos estructurados (JSON) para facilitar búsquedas. Ejemplo:
{
"timestamp": "2026-08-04T10:00:05Z",
"level": "info",
"event": "tool_call",
"agent_id": "customer_support_v2",
"session_id": "agm-123",
"tool": "fetch_ticket",
"arguments": {"id": "789"},
"status": "success",
"duration_ms": 2000,
"cost_usd": 0.01
}import re
def sanitize_output(output):
return re.sub(r'api[_-]?key[\s]*[:=]\s*\S+', '[REDACTED]', output)Análisis automático de trazas
Con miles de sesiones diarias, revisar trazas manualmente es invible. Implementar análisis automatizado para detectar anomalías:
- Loops: 3 o más calls idénticos consecutivos al mismo tool con la misma input.
- High cost: Sesiones con costo > 5x el promedio móvil de los últimos 100 sessions.
- Tool errors: Más de 2 fallos del mismo tool en una sesión.
- Token efficiency: Ratio tokens_output / tokens_input fuera del rango esperado.
Ejemplo de consulta en Langfuse para detectar loops:
SELECT trace_id, count(*) as loop_count
FROM spans
WHERE name = 'llm_call' AND input = '¿Cuál es el estado del ticket?'
GROUP BY trace_id
HAVING loop_count >= 3;Qué deberían hacer los administradores y equipos técnicos
- Instrumentar agents con trazas especializadas:
– Asegurar que cada call al modelo, tool invocation y decisión interna genere un span.
– Configurar el exporter para envío non-blocking y graceful shutdown.
- Monitorear costos en tiempo real:
costo_usd = (tokens_input + tokens_output) * precio_per_token / 1000000
(Ej.: gpt-4-32k cuesta $0.80 por 1K input tokens y $0.40 por 1K output tokens en agosto 2026).
– Crear alertas en Grafana para sesiones con costo > 5x el promedio de las últimas 24 horas.
- Implementar guardas proactivos:
– Tool budgets: Limitar el número de calls a tools costosos (ej.: max 5 calls a search_vector_store por sesión).
– Loop detection: Bloquear calls repetidos idénticos al mismo tool.
– Ejemplo en Python con LangChain:
from langchain.agents import AgentExecutor
from langchain.agents.stopping import EnduresTooManySteps, StoppingError
executor = AgentExecutor(
agent=agent,
max_iterations=20,
early_stopping_errors=[StoppingError]
)
- Centralizar logs y trazas:
– Configurar el backend de trazas para retención adecuada (ej.: 30 días para debugging).
– Asegurar que los datos sensibles estén sanitizados.
- Crear un command de diagnóstico:
agent-doctor que verifique:– Conectividad con los modelos (ej.: curl -X POST $LLM_ENDPOINT).
– Reachability de vector stores y APIs.
– Estado del backend de trazas.
– Métricas de salud (ej.: error rate de tools en las últimas 5 minutos).
– Ejemplo:
agent-doctor check --agent customer_support_v2
# Output:
# ✅ Model gpt-4: OK (latency 200ms)
# ✅ Vector store: OK
# ❌ Tool fetch_ticket: 500 error (last failure: 10:05)
# ✅ Trace backend: OK
- Automatizar el análisis de trazas:
– Integrar con sistemas de ticketing (ej.: Jira) para crear issues automáticos para las sesiones flaggeadas.
Conclusión
La observabilidad para agents de IA requiere más que el APM tradicional: trazas que capturen el flujo de decisión, métricas de costos y logs sanitizados. Sin esto, los equipos volarán a ciegas, descubriendo problemas cuando el daño ya está hecho. La instrumentación debe ser non-blocking, los guardas proactivos y el análisis automatizado para escalar. Herramientas como Prometheus, Grafana y Langfuse son piezas clave, pero el valor real está en cómo las usamos: enfocándonos en las preguntas específicas que solo los agents pueden responder.