Anti-pattern No Monitoring: ausencia de monitoreo

Idea en 30 segundos

No Monitoring es un anti-pattern donde un sistema de agentes funciona casi "a ciegas": sin trazas de ejecución, stop_reason ni métricas base.

Como resultado, cualquier fallo parece "el modelo se comportó raro", y el equipo no puede encontrar rápido la root cause. Esto aumenta el tiempo de debug, el costo de incidentes y el riesgo de errores repetidos.

Regla simple: cada run debe dejar una huella clara - run_id, eventos clave de pasos, stop_reason y métricas de usage.

Ejemplo del anti-pattern

El equipo lanza un agente de soporte en producción, pero solo loggea la respuesta final.

Cuando un usuario reporta un error, el equipo no ve dónde ocurrió.

result = agent.run(user_message)
logger.info("answer=%s", result.text)

En este esquema falta contexto base del run:

# no hay run_id
# no hay step trace
# no hay tool status/duration
# no hay stop_reason

Para este caso se necesita una capa mínima de observabilidad:

run_id = create_run_id()
log_run_started(run_id, user_message)
...
log_stop(run_id, stop_reason, usage)

En este caso, la falta de monitoreo agrega:

• debug "a ciegas" basado en suposiciones
• más tiempo de recuperación después de incidentes
• repetición de fallos del mismo tipo

Por qué aparece y qué sale mal

Este anti-pattern aparece con frecuencia cuando el equipo se enfoca en features y deja el monitoreo "para después".

Causas típicas:

• se loggea solo el output final sin eventos run-level
• no hay un esquema unificado de eventos para agent/tool/stop
• faltan métricas base por ruta (success rate, latency, cost per request)
• no hay responsable claro de observabilidad en el equipo

Como resultado aparecen problemas:

• MTTR alto - cuesta localizar rápido la root cause
• incidentes repetidos - los fixes se hacen "a ciegas" sin validar causas
• degradación oculta - la latency y el cost suben sin que se note
• calidad frágil - el equipo no ve dónde cae el success rate
• baja operabilidad - no se puede explicar por qué un run terminó así

A diferencia de No Stop Conditions, aquí el fallo central es la falta de visibilidad: incluso si existe lógica de parada, el equipo no ve cómo actuó en un run concreto.

Señales típicas de producción de que falta monitoreo:

• support se entera del problema antes que el monitoreo
• el equipo no puede reconstruir la cadena de eventos por run_id
• en logs suele faltar stop_reason o no se puede asociar al run
• cost per request o P95 suben, y el equipo lo detecta tarde

Es importante que cada paso de agent/tool forma parte de la ejecución del run. Sin trazas y métricas, el sistema se vuelve una caja negra para el equipo y se pierde la relación causa-efecto entre acción y fallo.

Enfoque correcto

Empieza con una baseline mínima de observabilidad y hazla obligatoria para cada ruta. Agrega métricas nuevas solo cuando cubran incidentes concretos o zonas ciegas.

Marco práctico:

• registra run_id y step_id para cada run
• loggea en cada tool-call: tool, status (ok/error), duration_ms, args_hash
• loggea stop_reason y métricas de usage para cada run
• sigue dashboards clave (por ejemplo success rate, P95, cost per request) y configura alertas para desviaciones críticas

def run_support_agent(user_message: str):
    run_id = create_run_id()
    log_event("run_started", run_id=run_id, message=user_message)

    for step_id in range(MAX_STEPS):
        decision = agent.next_step(user_message)

        if decision.type == "tool_call":
            started = now_ms()
            try:
                result = run_tool(decision.tool, decision.args)
                log_event(
                    "tool_result",
                    run_id=run_id,
                    step_id=step_id,
                    tool=decision.tool,
                    duration_ms=now_ms() - started,
                    status="ok",
                )
            except Exception:
                log_event(
                    "tool_result",
                    run_id=run_id,
                    step_id=step_id,
                    tool=decision.tool,
                    duration_ms=now_ms() - started,
                    status="error",
                )
                raise
            continue

        if decision.type == "final_answer":
            log_event("stop", run_id=run_id, stop_reason="final_answer")
            return decision.output

    log_event("stop", run_id=run_id, stop_reason="max_steps_exceeded")
    return fallback_answer()  # safe default response or escalation

En este esquema, cada run se vuelve transparente: el equipo ve qué pasó, dónde apareció el fallo y cómo validar un fix.

Prueba rápida

Si respondes "sí" a estas preguntas, tienes riesgo de anti-pattern No Monitoring:

• ¿Es difícil explicar en 1-2 minutos por qué un run concreto terminó así?
• ¿Support reporta fallos antes que tus alertas?
• ¿Es imposible reproducir el último run fallido a partir de logs y métricas?

Cómo se diferencia de otros anti-patterns

No Stop Conditions vs No Monitoring

En resumen: No Stop Conditions trata del control del loop, mientras No Monitoring trata de no ver lo que realmente ocurrió.

Overengineering Agents vs No Monitoring

En resumen: Overengineering Agents aumenta la complejidad del sistema, y No Monitoring vuelve esa complejidad invisible y difícil de gestionar.

Agents Without Guardrails vs No Monitoring

En resumen: Agents Without Guardrails trata de límites de control ausentes, y No Monitoring trata de falta de visibilidad sobre cómo esos límites funcionaron (o no) en el run.

Autoevaluación: ¿tienes este anti-pattern?

Chequeo rápido del anti-pattern No Monitoring.
Marca los puntos para tu sistema y revisa el estado abajo.

Revisa tu sistema:

FAQ

Q: ¿Basta con escribir application logs?
A: No. Los sistemas de agentes necesitan monitoreo run-level: run_id, eventos por paso, stop_reason, trazas de tools y métricas de calidad/costo.

Q: ¿Por dónde empezar si casi no hay monitoreo?
A: Empieza por lo mínimo: run_id, stop_reason, tool status/duration, success rate, P95, cost per request. Eso ya reduce mucho las zonas ciegas.

Q: ¿Hace falta replay completo desde el inicio?
A: El replay completo no es obligatorio al principio, pero debe existir al menos reconstrucción parcial del run desde logs. Si no, validar fixes sigue siendo una suposición.

Qué sigue

Anti-patterns relacionados:

• No Stop Conditions - cuando el loop del agente no tiene condiciones claras de finalización.
• Agents Without Guardrails - cuando el agente opera sin policy boundaries claras.
• Overengineering Agents - cuando la arquitectura se llena de capas innecesarias.

Qué construir en su lugar:

• Stop Conditions - cómo fijar finalización controlada del run.
• Tool Execution Layer - dónde centralizar logging y control de tool-calls.
• Agent Runtime - cómo hacer transparente la ejecución del agente a nivel de pasos y decisiones.