L’agente ha davvero finito? Come verificare il risultato senza fidarsi della sua risposta finale

L’azione non è il risultato

Un agente può rispondere «fatto» anche se l’obiettivo non è stato raggiunto. Può anche inviare una chiamata a uno strumento, ricevere una risposta che conferma l’accettazione della richiesta e, nonostante ciò, lasciare il lavoro in sospeso o incompleto. Sono affermazioni diverse e richiedono prove diverse.

È utile distinguere tre stati. Primo: l’agente ha tentato un’azione, per esempio inviando un’istruzione per modificare un record. Secondo: il sistema che ha ricevuto la richiesta l’ha accettata o vi ha risposto. Terzo: lo stato finale richiesto dalla persona esiste e soddisfa le condizioni concordate. Solo il terzo stato dimostra, di per sé, che l’obiettivo è stato raggiunto.

Questa distinzione è importante perché una risposta positiva può riferirsi soltanto a una fase del processo. «Richiesta ricevuta» non significa necessariamente «modifica salvata»; «test eseguito» non significa che siano soddisfatti tutti i requisiti della modifica; e «prenotazione richiesta» non equivale a «prenotazione confermata». La risposta dell’agente può riassumere ciò che è successo, ma non dovrebbe diventare l’unica prova di ciò che è successo.

La valutazione degli agenti riguarda la verifica dell’affidabilità con cui i sistemi capaci di compiere azioni portano a termine un’attività. Questo articolo ha un obiettivo più circoscritto: stabilire quali prove permettano di considerare completata una specifica attività. Le raccomandazioni e gli esempi che seguono costituiscono un metodo pratico, non l’affermazione che esista un segnale universale valido per ogni agente o strumento.

Passaggio 1: trasformare la richiesta in uno stato finale osservabile

Prima di eseguire un’attività, riformula la richiesta descrivendo come dovrebbe essere la situazione al termine. «Aggiorna il record» è ambiguo: non specifica quale campo modificare, quale valore impostare o se altri dati debbano rimanere invariati. Anche «fai la modifica al codice» non chiarisce quale comportamento ci si aspetti né quali condizioni debbano continuare a essere soddisfatte.

Una formulazione utile identifica l’elemento interessato, lo stato desiderato, le condizioni da preservare e gli eventuali limiti pertinenti. Non occorre trasformare ogni richiesta in una specifica lunga. È però necessario risolvere le ambiguità che cambierebbero la decisione di considerare completata l’attività.

Il risultato osservabile deve poter essere descritto senza dipendere dalle intenzioni dell’agente. Invece di dire «l’agente ha gestito la prenotazione», specifica che cosa dovrebbe esistere per poterla definire confermata. Invece di dire «l’agente ha corretto il codice», definisci quale comportamento atteso deve funzionare e quali verifiche sono pertinenti alla modifica.

Definisci anche ciò che resta fuori dall’ambito. Se è stato chiesto di aggiornare un campo, non presumere che l’agente debba modificare altri campi, avvisare terze parti o controllare l’intera cronologia. Questo confine aiuta a evitare due errori opposti: accettare un’attività parziale come completa e ampliare l’incarico senza autorizzazione.

Passaggio 2: concordare i criteri di accettazione prima di agire

I criteri di accettazione specificano che cosa dovrebbe essere osservabile per considerare soddisfatta la richiesta. È preferibile definirli prima di eseguire l’azione: in seguito è più facile scambiare un risultato comodo per una prova adeguata o abbassare il livello richiesto per giustificare un esito parziale.

Un criterio utile è specifico e verificabile. «Il record è a posto» lascia troppo spazio all’interpretazione. «Il campo di stato mostra il valore concordato per il record identificato» indica uno stato e un oggetto precisi. Se è importante anche che altri campi restino invariati, occorre aggiungere un criterio separato.

Non tutti i requisiti si verificano con un solo segnale. Una modifica può richiedere che il valore sia presente e che un altro attributo non sia cambiato. Una prenotazione può richiedere sia una conferma sia la correttezza dei dettagli. Un test del codice può coprire un comportamento importante senza dimostrare, da solo, che ogni requisito dell’incarico sia stato implementato. L’elenco deve riflettere le condizioni effettive della richiesta, non soltanto quelle più facili da misurare.

Per le richieste aperte, può essere necessario chiedere prima un chiarimento. Se esistono più interpretazioni ragionevoli e la differenza incide su ciò che si può accettare come risultato, l’agente non dovrebbe sceglierne una in silenzio e trattarla poi come se fosse l’unica possibile. I criteri concordati determinano anche quando un’attività è solo parzialmente completa e quali informazioni comunicare.

Passaggio 3: scegliere prove pertinenti all’affermazione

Le prove devono rispondere alla domanda concreta: che cosa permette di affermare che lo stato finale desiderato esiste? L’output di uno strumento può essere adeguato per sapere che una richiesta è arrivata a un determinato componente, ma non necessariamente per dimostrare che il risultato sia stato salvato o soddisfi tutti i requisiti. Non attribuire a un segnale un significato più ampio di quello che ha davvero.

Quando è possibile, verifica lo stato leggendo il sistema interessato o eseguendo un controllo che valuti direttamente il risultato. Per alcuni lavori, la prova può consistere in un test automatizzato; per altri, in una conferma visibile nella fonte che gestisce quello stato. «Indipendente» non significa sempre «di un altro fornitore»: significa che l’unica prova non è l’affermazione dell’agente che dichiara di aver completato l’attività.

Anche l’indipendenza ha diversi gradi. Chiedere di nuovo all’agente se ha finito può semplicemente ripetere la sua affermazione, anziché verificarla. Consultare una vista del record può fornire un’osservazione dello stato, ma occorre sapere che cosa rappresenta quella vista e se riguarda l’oggetto corretto. Una fonte separata può offrire un confronto ulteriore, purché misuri davvero il risultato richiesto.

La prova deve essere collegata al criterio e all’oggetto corretti. Un test del codice superato non dimostra automaticamente requisiti che non copre. Una risposta di conferma della prenotazione è utile solo se si riferisce alla prenotazione richiesta e se i dettagli corrispondono a quanto concordato. Se non riesci a stabilire questo collegamento, esplicita l’incertezza invece di colmare le lacune con supposizioni.

Passaggio 4: separare esecuzione e verifica

Il componente che compie un’azione e quello che ne controlla il risultato hanno funzioni diverse. In un flusso semplice, lo stesso agente può chiamare uno strumento e poi consultare il sistema interessato. Anche in questo caso, però, la seconda operazione deve fornire un’osservazione dello stato, non limitarsi a ripetere che la prima è andata a buon fine.

Nei sistemi con un impatto maggiore, può essere preferibile che la verifica segua un percorso diverso da quello dell’esecuzione o che venga affidata a una persona. La separazione riduce il rischio che un’unica risposta venga trattata contemporaneamente come azione e come prova. Non è una regola assoluta: il grado di separazione appropriato dipende dal rischio, dall’ambiguità dell’attività e dalla qualità dei segnali disponibili.

L’automazione può essere sufficiente quando i criteri sono chiari, il controllo copre il risultato rilevante e le possibili conseguenze degli errori sono limitate. La revisione umana diventa più importante quando le istruzioni ammettono interpretazioni diverse, le conseguenze sono significative, le prove non sono conclusive o serve un giudizio contestuale che un test automatico non rappresenta.

Chiedere una revisione umana non rende automaticamente corretta una conclusione. Chi revisiona deve poter vedere che cosa è stato richiesto, quali criteri sono stati concordati e quali prove sono state osservate. Un’approvazione priva di questi elementi può trasformarsi in un altro «sì» senza fondamento. La revisione dovrebbe chiarire un dubbio concreto, non essere una formalità scollegata dal risultato.

Tre esempi pratici

Gli esempi che seguono illustrano il metodo attraverso criteri ipotetici. Non descrivono uno strumento o un prodotto specifico; i segnali disponibili variano da un sistema all’altro. In tutti e tre i casi, l’aspetto fondamentale è non trasformare una risposta di accettazione nella prova del completamento senza aver verificato che cosa significhi.

Quando si aggiorna un record, la richiesta può riguardare la modifica di un campo specifico. L’azione inviata dimostra un tentativo; una risposta di accettazione può indicare che il sistema ha ricevuto la richiesta. Per dichiarare completato il lavoro, occorre osservare il record corretto e controllare il valore concordato. Se era stato chiesto anche di preservare altri dati, la verifica deve includerli. Se il sistema mostra soltanto che la modifica è in sospeso, il risultato non soddisfa ancora un criterio che richiede che il valore sia già presente nel record.

Nel caso di una modifica al codice, il compito non è definito dal fatto che esista una patch o che sia arrivata una risposta positiva. Prima di procedere, chiarisci quale comportamento ci si aspetta e quali condizioni fanno parte dell’incarico. Poi usa verifiche pertinenti a quel comportamento e rivedi i criteri che i test non coprono. Il fatto che un test termini senza errori costituisce una prova relativa a ciò che quel test ha eseguito; non dimostra automaticamente che siano soddisfatti tutti i requisiti funzionali o di qualità della richiesta.

Per una prenotazione, distinguere tra richiesta e conferma è decisivo. L’agente può inviare una richiesta e ricevere una risposta che non chiarisce se la prenotazione sia stata confermata. La prova deve permettere di identificare la prenotazione pertinente e confrontare i dettagli concordati. Se c’è soltanto una richiesta in sospeso o non è possibile confermare i dati necessari, il messaggio finale deve dirlo, senza presentare la prenotazione come conclusa.

Risultati parziali, contraddittori o non verificabili

Se è soddisfatta solo una parte dei criteri, descrivi il risultato come parziale. Non trasformare «l’azione è stata accettata» in «l’attività è completata» per dare una conclusione più convincente. Evita anche l’errore opposto: se esistono prove valide per alcuni requisiti, indicali invece di presentare l’intero lavoro come ignoto.

Se due segnali si contraddicono, sospendi la conclusione finché non è chiaro che cosa misuri ciascuno e a quale stato si riferisca. Una risposta positiva può riguardare la ricezione della richiesta, mentre un’altra osservazione mostra che lo stato finale non è ancora cambiato. Non è necessariamente una contraddizione reale: potrebbe trattarsi di fasi diverse. Finché la differenza non è chiarita, però, non è possibile dichiarare il completamento dell’attività.

Se non esiste un modo adeguato per osservare il risultato, la conclusione corretta è che non è stato possibile verificarlo, non necessariamente che l’agente abbia fallito o che abbia avuto successo. Comunica quale azione è stata tentata, quale risposta è stata osservata e quale criterio resta da verificare. La mancanza di prove sullo stato finale non dimostra, da sola, quale sia quello stato.

Mantieni la descrizione del risultato proporzionata alle prove. «Richiesta inviata» è diverso da «richiesta accettata»; «modifica osservata nel campo» è diverso da «tutti i requisiti verificati»; e «test selezionati completati» è diverso da «non resta alcun problema». Un messaggio preciso aiuta chi riceve il risultato a decidere se attendere, controllare o accettare l’attività.

Lista di controllo per progettare un flusso

La valutazione degli agenti può esaminare se un sistema che esegue azioni completa un’attività in modo affidabile; i test possono aiutare a interpretare singole esecuzioni. Tuttavia, un punteggio, uno stato di esecuzione o una risposta dello strumento non sostituiscono la definizione del risultato che conta per una specifica attività. Il team deve tradurre la richiesta in criteri osservabili e collegare ogni conclusione alle prove che la sostengono.

Prima di accettare un’attività o comunicarla come completata, passa in rassegna questa lista. Non riuscire a rispondere a una domanda non significa sempre che l’attività sia fallita; indica però che è opportuno limitare l’affermazione, ottenere le prove mancanti o chiedere una revisione adeguata all’impatto.

Continua a esplorare

Correzioni e trasparenza

Se trovi un dato errato o non aggiornato, inviaci la pagina e la fonte da verificare.