Anti-Pattern No Monitoring: fehlendes Monitoring

Idee in 30 Sekunden

No Monitoring ist ein Anti-Pattern, bei dem ein Agent-System fast "blind" läuft: ohne Run-Traces, stop_reason und Basis-Metriken.

Dadurch wirkt jeder Ausfall wie "das Modell war komisch", und das Team kann die Root Cause nicht schnell finden. Das erhöht Debugging-Zeit, Incident-Kosten und das Risiko wiederkehrender Fehler.

Einfache Regel: Jeder Run muss eine klare Spur hinterlassen - run_id, zentrale Step-Events, stop_reason und Usage-Metriken.

Beispiel für das Anti-Pattern

Das Team startet einen Support-Agenten in Production, loggt aber nur die finale Antwort.

Wenn ein Nutzer einen Fehler meldet, sieht das Team nicht, wo er entstanden ist.

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

In diesem Setup fehlt der grundlegende Run-Kontext:

# keine run_id
# kein step trace
# kein tool status/duration
# kein stop_reason

Für diesen Fall braucht ihr eine minimale Observability-Schicht:

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

In diesem Fall führt fehlendes Monitoring zu:

• "blindem" Debugging über Annahmen
• längerer Wiederherstellungszeit nach Incidents
• Wiederholung derselben Fehlertypen

Warum es entsteht und was schiefläuft

Dieses Anti-Pattern entsteht oft, wenn das Team auf Features fokussiert ist und Monitoring auf "später" verschiebt.

Typische Ursachen:

• es wird nur finaler Output ohne Run-Level-Events geloggt
• es gibt kein einheitliches Event-Schema für agent/tool/stop
• Basis-Metriken pro Route fehlen (success rate, latency, cost per request)
• es gibt keinen klaren Observability-Owner im Team

Dadurch entstehen Probleme:

• langer MTTR - Root Cause lässt sich nur schwer schnell lokalisieren
• wiederholte Incidents - Fixes werden "blind" ohne Ursachenprüfung gebaut
• versteckte Degradation - latency und cost steigen unbemerkt
• fragile Qualität - das Team sieht nicht, wo success rate fällt
• schwache Steuerbarkeit - es ist nicht erklärbar, warum ein Run genau so geendet hat

Im Unterschied zu No Stop Conditions liegt der Hauptfehler hier bei fehlender Sichtbarkeit: selbst wenn Stop-Logik existiert, sieht das Team nicht, wie sie in einem konkreten Run gewirkt hat.

Typische Production-Signale für unzureichendes Monitoring:

• Support erfährt von Problemen früher als das Monitoring
• das Team kann die Ereigniskette per run_id nicht rekonstruieren
• in Logs fehlt häufig stop_reason oder es ist keinem Run sauber zuordenbar
• cost per request oder P95 steigen, aber das Team merkt es zu spät

Wichtig: Jeder agent/tool-Schritt ist Teil der Run-Ausführung. Ohne Traces und Metriken wird das System zur Black Box für das Team, und die Ursache-Wirkungs-Kette zwischen Aktion und Failure geht verloren.

Richtiger Ansatz

Startet mit einer minimalen Observability-Basis und macht sie für jede Route verpflichtend. Neue Metriken ergänzt ihr dann, wenn sie konkrete Incidents oder Blind Spots schließen.

Praktischer Rahmen:

• run_id und step_id für jeden Run erfassen
• pro Tool-Call loggen: tool, status (ok/error), duration_ms, args_hash
• pro Run stop_reason und Usage-Metriken loggen
• zentrale Dashboards verfolgen (z. B. success rate, P95, cost per request) und Alerts auf kritische Abweichungen setzen

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

In diesem Setup wird jeder Run transparent: Das Team sieht, was passiert ist, wo der Fehler lag und wie ein Fix verifiziert wird.

Schnelltest

Wenn diese Fragen mit "ja" beantwortet sind, habt ihr ein Risiko für das Anti-Pattern No Monitoring:

• Ist es schwer, in 1-2 Minuten zu erklären, warum ein konkreter Run genau so geendet hat?
• Meldet Support Ausfälle oft früher als eure Alerts?
• Ist es unmöglich, den letzten fehlgeschlagenen Run aus Logs und Metriken nachzuvollziehen?

Worin es sich von anderen Anti-Patterns unterscheidet

No Stop Conditions vs No Monitoring

Kurz gesagt: No Stop Conditions betrifft Loop-Kontrolle, No Monitoring betrifft fehlende Sicht auf das, was real passiert ist.

Overengineering Agents vs No Monitoring

Kurz gesagt: Overengineering Agents erhöht die Systemkomplexität, und No Monitoring macht diese Komplexität unsichtbar und unsteuerbar.

Agents Without Guardrails vs No Monitoring

Kurz gesagt: Agents Without Guardrails betrifft fehlende Kontrollgrenzen, No Monitoring betrifft fehlende Sichtbarkeit darauf, wie diese Grenzen im Run (nicht) gewirkt haben.

Selbstcheck: Habt ihr dieses Anti-Pattern?

Schnellcheck für das Anti-Pattern No Monitoring.
Markiert die Punkte für euer System und prüft den Status unten.

Prüft euer System:

FAQ

Q: Reicht es, einfach application logs zu schreiben?
A: Nein. Agent-Systeme brauchen Run-Level-Monitoring: run_id, Step-Events, stop_reason, Tool-Traces sowie Qualitäts-/Kostenmetriken.

Q: Womit anfangen, wenn fast kein Monitoring existiert?
A: Startet mit dem Minimum: run_id, stop_reason, tool status/duration, success rate, P95, cost per request. Das reduziert Blind Spots bereits deutlich.

Q: Brauchen wir replay sofort?
A: Vollständiges replay ist am Anfang nicht zwingend, aber zumindest partielle Rekonstruktion eines Runs aus Logs muss möglich sein. Sonst bleibt Fix-Validierung Raten.

Was als Nächstes

Ähnliche Anti-Patterns:

• No Stop Conditions - wenn der Agent-Loop keine klaren Abschlussbedingungen hat.
• Agents Without Guardrails - wenn der Agent ohne klare policy boundaries läuft.
• Overengineering Agents - wenn die Architektur mit unnötigen Schichten anwächst.

Was ihr stattdessen bauen solltet:

• Stop Conditions - wie kontrollierter Run-Abschluss umgesetzt wird.
• Tool Execution Layer - wo Tool-Calls zentral geloggt und kontrolliert werden.
• Agent Runtime - wie Agent-Ausführung auf Step- und Decision-Ebene transparent wird.