Controlli sui passaggi: lo stato era giusto, l’agente no
Stripe era perfetto. L’agente aveva comunque provato ad annullare due volte. Perché ora leggiamo la traccia OpenTelemetry dell’agente, e perché una traccia mancante non fa mai fallire un test.
I controlli sullo stato rispondono alla domanda più importante: l’account è finito nello stato giusto? Ma a volte ci arriva per caso.
Stato giusto, passaggi sbagliati
In un’esecuzione l’agente ha proposto la stessa disdetta due volte. Guard ha riconosciuto il duplicato e la seconda volta non ha fatto nulla, quindi Stripe era perfetto. In produzione, con un rimborso al posto di una disdetta e una chiave di idempotenza diversa, la stessa abitudine potrebbe costare denaro.
Cos’è un controllo sui passaggi
Una regola su come l’agente ci è arrivato, impostata per scenario:
- uno strumento viene chiamato prima di un altro (cerca l’abbonamento prima di annullare);
- uno strumento viene chiamato al massimo N volte, oppure mai;
- l’agente risponde solo dopo la decisione di COLVO;
- nessun passaggio è terminato con un errore.
I controlli sui passaggi sono deterministici e possono solo aggiungere un FAIL. Non trasformano mai un FAIL in un PASS: decide sempre lo stato.
Da dove arrivano i passaggi
Durante il test il tuo agente esporta la sua traccia OpenTelemetry verso COLVO, con la chiave del test presente nella richiesta. Seguiamo le convenzioni GenAI (span chat … ed execute_tool …) e conserviamo solo nomi, tempi, modelli e conteggi di token — mai prompt, risposte o argomenti degli strumenti. Con il preset OpenAI è COLVO a condurre la conversazione, quindi registra ogni passaggio senza configurazione.
Le proposte sono sempre contate da COLVO e, per ogni azione, vale la fonte che ha visto più chiamate: un nuovo tentativo deduplicato da Guard conta comunque.
Nessuna traccia? Nessuna penalità
Se l’agente non invia una traccia, i controlli sui suoi strumenti risultano “non controllati”. Una traccia mancante non è mai un FAIL.
