Faccio una piccola premessa... questo articolo nasce da un comportamento anomalo che ho riscontrato durante il mio lavoro utilizzando Codex, in cui un Agent sembra che lavori ma in realta' e' bloccato e non procede nelle sue azioni.
Un assistente AI può sembrare diligente, prudente e perfino trasparente. Può dire: “ho verificato”, “procedo”, “sto applicando la modifica”, “ho terminato”.
Eppure nessuna di queste frasi dimostra che l’azione sia davvero avvenuta.
Questo è un fallimento particolarmente insidioso perché non produce necessariamente un errore visibile. L’utente riceve un aggiornamento plausibile, legge un linguaggio operativo rassicurante e può ragionevolmente supporre che il lavoro stia avanzando. Ma fra una dichiarazione e un’azione eseguita esiste una distanza che, se non viene controllata, diventa un punto cieco.
Tre stati che non devono essere confusi
In un sistema con agenti AI esistono almeno tre stati distinti:
| Stato | Che cosa significa | Che cosa non dimostra |
|---|---|---|
| Intenzione | L’agente ha formulato un piano | Che abbia iniziato il lavoro |
| Avanzamento dichiarato | L’agente afferma di essere al lavoro | Che abbia chiamato uno strumento o modificato un sistema |
| Azione verificata | Esiste una traccia dell’azione e del suo esito | Che l’intero requisito sia soddisfatto |
La confusione nasce quando il secondo stato viene raccontato come se fosse il terzo.
Un esempio semplice: un agente dice “procedo con il rilascio”. Se non segue una chiamata allo strumento, un log di esecuzione o un controllo dell’oggetto rilasciato, quella frase descrive al massimo un’intenzione. Non è una prova di deploy.
Perché accade
Non serve immaginare un comportamento ingannevole. Spesso la causa è più banale e quindi più pericolosa: il modello interpreta una sotto-attività come conclusione naturale del turno.
Può accadere quando le istruzioni insistono correttamente su concetti come:
- una modifica minima alla volta;
- conferma prima di una scrittura;
- verifica dopo ogni cambiamento;
- comunicazione immediata dei problemi.
Sono principi utili. Ma, se non sono accompagnati da una regola sul completamento della sequenza, l’agente può verificare un singolo blocco, scrivere un aggiornamento finale e lasciare incompleto l’obiettivo complessivo.
Il risultato appare ordinato: nessuna modifica azzardata, nessuna affermazione tecnicamente falsa sul singolo controllo. Ma il lavoro richiesto non è terminato.
Il rischio non è soltanto il tempo perso
Quando l’utente deve ripetere “vai avanti”, “procedi” o “non fermarti”, il costo non è solo conversazionale.
Si perde continuità operativa. Aumenta il rischio che la sessione successiva riparta da una memoria incompleta. Si rende più difficile capire se un punto è stato davvero chiuso o semplicemente pianificato. E, nei contesti tecnici, una pagina APEX, un package o una configurazione possono restare a metà: abbastanza presenti da sembrare pronti, non abbastanza verificati da poter essere usati.
Un test tecnico positivo non basta se verifica soltanto l’esistenza di un oggetto. Analogamente, una risposta ben scritta non basta se non collega il risultato a evidenze osservabili.
La correzione: separare parole, strumenti ed esiti
La soluzione non è vietare gli aggiornamenti intermedi. È renderli non ambigui.
Un agente dovrebbe usare formule diverse per stati diversi:
- “Sto per eseguire”: piano dichiarato.
- “Ho avviato l’azione”: strumento realmente chiamato.
- “L’azione è riuscita”: esito tecnico disponibile.
- “Il requisito è soddisfatto”: verifica che collega l’esito al bisogno dell’utente.
E dovrebbe evitare “ho terminato” finché non sono concluse tutte le attività comprese nel perimetro autorizzato.
Le istruzioni operative possono rendere questo comportamento verificabile con una regola semplice:
Quando l’utente autorizza una sequenza completa, l’agente esegue e verifica i blocchi uno alla volta senza chiudere il turno tra sotto-attività. Si ferma solo per un errore concreto, un nuovo perimetro, un’azione non autorizzata o una decisione che richiede l’utente.
Non elimina gli errori. Ma elimina una forma frequente di ambiguità: scambiare una frase di avanzamento per una prova di lavoro eseguito.
La domanda da fare a un agente
La domanda più utile non è: “Hai finito?”
È questa:
Quale azione concreta hai eseguito, quale evidenza ne dimostra l’esito e quale requisito resta ancora aperto?
Se la risposta contiene soltanto intenzioni, piani o promesse, il lavoro non è ancora verificato. Se contiene strumenti chiamati, output, controlli e limiti dichiarati, allora l’utente può valutare il risultato con maggiore fiducia.
Il fallimento invisibile non è l’errore vistoso. È il momento in cui tutto sembra in movimento, mentre in realtà non è ancora successo nulla.
Fonti consultate
- OpenAI, Evaluate agent workflows, consultata il 24 settembre 2026.
- OpenAI, Tracing, consultata il 24 settembre 2026.
- OpenAI, Integrations and observability, consultata il 24 settembre 2026.
Nessun commento:
Posta un commento