Contrôles des étapes : l’état était bon, l’agent non

Les contrôles d’état répondent à la question la plus importante : le compte a-t-il fini dans le bon état ? Mais parfois, il y arrive par chance.

Bon état, mauvaises étapes

Lors d’une exécution, l’agent a proposé deux fois la même résiliation. Guard a reconnu le doublon et n’a rien fait la seconde fois : Stripe semblait donc parfait. En production, avec un remboursement à la place d’une résiliation et une clé d’idempotence différente, la même habitude pourrait coûter de l’argent.

Ce qu’est un contrôle des étapes

Une règle sur la façon dont l’agent est arrivé au résultat, définie par scénario :

• un outil est appelé avant un autre (consulter l’abonnement avant de résilier) ;
• un outil est appelé au plus N fois, ou jamais ;
• l’agent ne répond qu’après la décision de COLVO ;
• aucune étape ne s’est terminée par une erreur.

Les contrôles des étapes sont déterministes et ne peuvent qu’ajouter un FAIL. Ils ne transforment jamais un FAIL en PASS : l’état décide toujours.

D’où viennent les étapes

Pendant le test, votre agent exporte sa trace OpenTelemetry vers COLVO, avec la clé propre au test fournie dans la requête. Nous suivons les conventions GenAI (spans chat … et execute_tool …) et ne conservons que les noms, les durées, les modèles et le nombre de tokens — jamais les prompts, les réponses ni les arguments des outils. Avec le preset OpenAI, COLVO mène lui-même la conversation : il enregistre donc chaque étape sans aucune configuration.

Les propositions sont toujours comptées par COLVO et, pour chaque action, la source qui a vu le plus d’appels l’emporte : une nouvelle tentative dédoublonnée par Guard compte quand même.

Pas de trace ? Pas de pénalité

Si l’agent n’envoie pas de trace, les contrôles portant sur ses propres outils apparaissent comme « non vérifiés ». Une trace manquante n’est jamais un FAIL.