Anti-pattern No Monitoring : absence de monitoring

Idée en 30 secondes

No Monitoring est un anti-pattern où un système d'agents fonctionne presque "à l'aveugle" : sans traces d'exécution, stop_reason ni métriques de base.

Résultat : chaque incident ressemble à "le modèle s'est comporté bizarrement", et l'équipe ne peut pas trouver rapidement la root cause. Cela augmente le temps de debug, le coût des incidents et le risque de répétition des erreurs.

Règle simple : chaque run doit laisser une trace claire - run_id, événements clés des étapes, stop_reason, et métriques d'usage.

Exemple d'anti-pattern

L'équipe lance un agent de support en production, mais ne log que la réponse finale.

Quand un utilisateur signale une erreur, l'équipe ne voit pas où elle est apparue.

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

Dans ce schéma, le contexte de base du run manque :

# pas de run_id
# pas de step trace
# pas de tool status/duration
# pas de stop_reason

Pour ce cas, il faut une couche minimale d'observabilité :

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

Ici, l'absence de monitoring ajoute :

• un debug "à l'aveugle" fondé sur des hypothèses
• un temps de récupération plus long après incident
• la répétition de pannes du même type

Pourquoi ça apparaît et ce qui se passe mal

Cet anti-pattern apparaît souvent quand l'équipe se concentre sur les features et remet le monitoring "à plus tard".

Causes typiques :

• seul l'output final est loggé, sans événements run-level
• il n'y a pas de schéma d'événements unifié pour agent/tool/stop
• les métriques de base par route sont absentes (success rate, latency, cost per request)
• aucun responsable clair de l'observabilité dans l'équipe

Résultats :

• MTTR long - difficile de localiser rapidement la root cause
• incidents répétés - les correctifs sont faits "à l'aveugle" sans validation des causes
• dégradation cachée - la latency et le cost augmentent sans être vus
• qualité fragile - l'équipe ne voit pas où le success rate chute
• pilotage faible - impossible d'expliquer pourquoi un run s'est terminé ainsi

Contrairement à No Stop Conditions, la panne principale ici est l'absence de visibilité : même si la logique de stop existe, l'équipe ne voit pas comment elle a fonctionné sur un run concret.

Signaux de production typiques indiquant un monitoring insuffisant :

• le support découvre le problème avant le monitoring
• l'équipe ne peut pas reconstruire la chaîne d'événements via run_id
• les logs n'ont souvent pas de stop_reason, ou il n'est pas rattachable au run
• cost per request ou P95 augmente, mais l'équipe le voit trop tard

Point important : chaque étape agent/tool fait partie de l'exécution du run. Sans traces et métriques, le système devient une boîte noire pour l'équipe, et le lien cause-effet entre action et incident disparaît.

Bonne approche

Commencez par un socle minimal d'observabilité et rendez-le obligatoire pour chaque route. Ajoutez de nouvelles métriques seulement quand elles couvrent des incidents concrets ou des zones aveugles.

Cadre pratique :

• enregistrez run_id et step_id pour chaque run
• loggez pour chaque tool-call : tool, status (ok/error), duration_ms, args_hash
• loggez stop_reason et les métriques d'usage pour chaque run
• suivez les dashboards clés (par exemple success rate, P95, cost per request) et configurez des alertes sur les écarts critiques

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

Avec ce schéma, chaque run devient transparent : l'équipe voit ce qui s'est passé, où l'échec est apparu et comment valider un correctif.

Test rapide

Si la réponse à ces questions est "oui", vous avez un risque d'anti-pattern No Monitoring :

• Est-il difficile d'expliquer en 1-2 minutes pourquoi un run précis s'est terminé ainsi ?
• Le support signale-t-il souvent les incidents avant vos alertes ?
• Est-il impossible de rejouer le dernier run en échec à partir des logs et métriques ?

Différence avec les autres anti-patterns

No Stop Conditions vs No Monitoring

En bref : No Stop Conditions concerne le contrôle de boucle, alors que No Monitoring concerne l'absence de visibilité sur ce qui s'est réellement passé.

Overengineering Agents vs No Monitoring

En bref : Overengineering Agents augmente la complexité du système, et No Monitoring rend cette complexité invisible et non pilotable.

Agents Without Guardrails vs No Monitoring

En bref : Agents Without Guardrails concerne l'absence de limites de contrôle, tandis que No Monitoring concerne l'absence de visibilité sur la façon dont ces limites ont (ou non) fonctionné pendant un run.

Auto-vérification : avez-vous cet anti-pattern ?

Vérification rapide de l'anti-pattern No Monitoring.
Cochez les points pour votre système et consultez le statut ci-dessous.

Vérifiez votre système :

FAQ

Q : Est-ce suffisant d'écrire seulement des application logs ?
R : Non. Les systèmes d'agents ont besoin de monitoring run-level : run_id, événements d'étapes, stop_reason, traces d'outils et métriques qualité/coût.

Q : Par quoi commencer si le monitoring est presque absent ?
R : Commencez par le minimum : run_id, stop_reason, tool status/duration, success rate, P95, cost per request. Cela réduit déjà fortement les zones aveugles.

Q : Faut-il un replay complet dès le début ?
R : Un replay complet n'est pas obligatoire au départ, mais au moins une reconstruction partielle du run à partir des logs doit exister. Sinon, valider les correctifs reste de la supposition.

Et ensuite

Anti-patterns proches :

• No Stop Conditions - quand la boucle d'agent n'a pas de conditions de fin claires.
• Agents Without Guardrails - quand l'agent fonctionne sans policy boundaries claires.
• Overengineering Agents - quand l'architecture accumule des couches inutiles.

Ce qu'il faut construire à la place :

• Stop Conditions - comment garantir une terminaison contrôlée d'un run.
• Tool Execution Layer - où centraliser logging et contrôle des tool-calls.
• Agent Runtime - comment rendre l'exécution agent transparente au niveau des étapes et décisions.