Post-mortem : la boucle qui a coûté 3 200 $ en une nuit.

Imaginons un agent de recherche qui entre dans une boucle de réessai non détectée après avoir reçu une réponse d'outil ambiguë. Sans condition de terminaison autre qu'un plafond de pas par session (que la boucle réinitialise à chaque nouvelle sous-tâche) et sans alerte de coût en place, l'agent effectue 24 847 appels API sur 9 heures et 14 minutes, accumulant 3 218 $ en dépenses API avant qu'un ingénieur ne remarque l'anomalie lors d'une vérification matinale de routine. Ce billet parcourt cette défaillance de bout en bout.

Minute par minute, puis heure par heure

La chronologie de l'incident ci-dessous enregistre chaque changement d'état, de l'invocation normale à la contention. Les chiffres de dépenses indiquent le coût API cumulatif à chaque point de contrôle.

La courbe des dépenses, heure par heure

Dépenses API totales sur la fenêtre de l'incident. La boucle s'emballe après 23 h 00, plafonne à environ 400 $/heure pendant la nuit, et est interrompue par l'arrêt manuel à 07 h 18.

Trois mesures de protection absentes. Toutes les trois requises.

Ce n'était pas un cas limite rare. Le déclencheur, une réponse 200 vide d'un scraper à limitation de débit, survient sur environ 3 % des invocations du scraper. La boucle était un résultat prévisible d'une entrée prévisible, sans défense en profondeur. Le post-mortem a identifié cinq facteurs contributifs. Trois étaient des mesures de protection indépendantes qui, si l'une d'elles avait été en place, auraient contenu l'incident.

À quoi ressemblait le code. Avant et après.

La condition de terminaison manquante tenait en trois lignes : un compteur de pas au niveau du workflow et une vérification avant chaque génération de sous-tâche. L'alerte de coût était une seule règle CloudWatch. Aucune des deux n'exigeait de changements architecturaux. Les deux ont nécessité l'incident pour sembler nécessaires.

# ── BEFORE: sub-task spawn with no workflow-level guard ──────────
def spawn_subtask(task: str, context: dict) -> dict:
    # No check on total workflow steps. This is the gap.
    sub_agent = ResearchAgent(max_steps=20)  # per-task cap only
    return sub_agent.run(task, context)

# ── AFTER: workflow-level budget enforced across all sub-tasks ────
@dataclass
class WorkflowBudget:
    max_steps:     int   = 100   # across ALL sub-tasks
    max_spend_usd: float = 5.00  # hard dollar cap
    steps_used:    int   = 0
    spend_usd:     float = 0.0

    def check(self) -> None:
        if self.steps_used >= self.max_steps:
            raise WorkflowBudgetExceeded(f"Step limit  reached")
        if self.spend_usd >= self.max_spend_usd:
            raise WorkflowBudgetExceeded(f"Spend limit $ reached")

def spawn_subtask(task: str, context: dict, budget: WorkflowBudget) -> dict:
    budget.check()                           # enforced before spawn
    sub_agent = ResearchAgent(
        max_steps=20,
        budget=budget,                        # shared budget object
        on_step=lambda cost: setattr(
            budget, "spend_usd", budget.spend_usd + cost
        )
    )
    return sub_agent.run(task, context)

# The confidence budget (the planner post) sits above this. It
# detects stalling before the dollar cap is reached. The dollar
# cap is the last line of defense, not the first.

Le WorkflowBudget est transmis à chaque génération de sous-tâche. Les sous-tâches ne reçoivent pas un budget neuf, elles puisent dans le même pool. Le plafond en dollars est fixé de façon conservatrice pour le premier déploiement de tout nouveau workflow et relevé au fur et à mesure que la confiance dans la plage de dépenses attendue du workflow se consolide. Le budget de confiance du billet sur le planificateur se situe en amont et détecte généralement les boucles emballées avant qu'elles n'atteignent le plafond en dollars. Le plafond en dollars est la terminaison de dernier recours.

Ce qui a changé. Dans son intégralité.

Trois choses que cet incident a changées définitivement

La défense en profondeur n'est pas optionnelle pour les boucles agentiques. Toute mesure de protection unique peut être contournée : le plafond de pas l'a été. Le budget de confiance, le plafond de dépenses au niveau du workflow, et l'alerte de coût en temps réel sont trois défenses indépendantes. Si l'une manque, les autres peuvent encore contenir un incident. Si les trois manquent, vous rédigez un post-mortem.

Le succès invisible est le mode de défaillance le plus difficile à détecter. La boucle a effectué 24 847 appels API réussis. Chaque appel a retourné 200. Aucune erreur n'a été levée. La pile de surveillance voyait un système sain. Le seul signal anormal était les dépenses, que personne ne surveillait. Les métriques de succès ne détectent pas les boucles, elles les confirment.

Les mesures de protection de cette série sont listées par ordre de prévention des incidents, non de complexité d'implémentation. Le budget de confiance avait été écrit avant cet incident mais n'avait pas été déployé sur tous les workflows. Le harnais d'éval existait mais ne couvrait pas ce mode de défaillance. Le traceur de coût n'existait pas encore. Les trois billets ont été écrits, au moins en partie, à cause de cette nuit-là.

Si vous souhaitez que nous testions les mesures de protection de votre propre stack d'agents, le formulaire de contact est le moyen le plus rapide. Nous offrons des révisions de 30 minutes pour les stacks d'agents en production, gratuitement.