Perché gli agenti si bloccano al nono passaggio

Gli agenti impressionano nei primi cinque minuti e poi, nei workflow abbastanza lunghi, si fermano spesso nello stesso modo: non con un errore spettacolare, ma con una piccola assunzione sbagliata che passa inosservata. Il passaggio nove non è speciale. È semplicemente il punto in cui una probabilità di successo molto buona, moltiplicata abbastanza volte, smette di essere buona.

La reliability si moltiplica

Supponi che ogni passaggio di un workflow abbia il 95% di probabilità di essere eseguito correttamente. Novantacinque per cento sembra eccellente. Ma se dieci passaggi devono riuscire tutti, la probabilità complessiva è 0.95^10, circa 0,60. A venti passaggi scende a circa 0,36.

Non serve che l’agente diventi improvvisamente stupido. Basta che ogni passaggio aggiunga una piccola possibilità di scegliere il file sbagliato, interpretare male un risultato, utilizzare uno stato vecchio oppure credere che un comando abbia avuto l’effetto desiderato perché è terminato senza errori.

Il problema vero è la deriva di stato

Gli errori più costosi non sono quelli che fermano l’agente. Sono quelli che gli permettono di continuare.

Un comando restituisce exit code zero ma ha modificato il file sbagliato. Una query API restituisce un oggetto valido ma relativo all’ambiente di staging. Un test eseguito sulla directory sbagliata passa. Il modello vede un risultato plausibile, aggiorna il proprio stato mentale e il passaggio successivo parte da una premessa falsa.

Dopo tre o quattro passaggi quella premessa è ormai sepolta nella cronologia. Tutto ciò che segue può essere internamente coerente e globalmente sbagliato.

“Eseguito” non significa “riuscito”

Ogni azione importante ha bisogno di un post-condition check. Se crei una risorsa, leggila indietro e verifica i campi che contano. Se modifichi codice, esegui il test che dimostra proprio quella modifica. Se fai deploy, controlla l’artefatto effettivamente servito e non soltanto il log della pipeline.

La differenza è sottile:

# fragile
esegui deploy
se il comando termina, continua

# robusto
esegui deploy
leggi la versione servita
verifica che commit == commit_atteso
solo allora continua

Il secondo workflow costa una chiamata in più e impedisce a un errore silenzioso di avvelenare tutti i passaggi successivi.

Progetta per la ripresa, non per la perfezione

Un agente affidabile non è quello che non fallisce mai. È quello che fallisce in un punto identificabile e può riprendere senza ripetere il lavoro già validato.

Tre proprietà fanno quasi tutto il lavoro.

• Checkpoint. Dopo ogni fase costosa salva uno stato minimo e verificabile: id della risorsa, commit, hash dell’artefatto, versione dello schema, output atteso.
• Idempotenza. Rieseguire lo stesso passaggio deve produrre lo stesso stato oppure riconoscere che quello stato esiste già. “Crea se assente” è molto più sicuro di “crea e spera che non esista”.
• Confini di fase. Pianificazione, mutazione e verifica non dovrebbero essere un’unica lunga conversazione. Una fase può produrre un piano; la successiva lo esegue; una terza controlla ciò che esiste davvero.

Riduci la libertà dove non serve

Il modello dovrebbe decidere soltanto dove esiste davvero una decisione. Parsing, aritmetica, validazione, selezione di file tramite regole note e controlli di precondizione dovrebbero stare in codice o in tool con schemi stretti.

Ogni scelta aperta che lasci al modello aggiunge un altro punto in cui la probabilità può moltiplicarsi. La flessibilità è preziosa nel piano e costosa nell’esecuzione.

I retry devono sapere che cosa stanno ritentando

Ripetere semplicemente una chiamata fallita è sicuro soltanto quando l’azione è idempotente. Se il primo tentativo ha creato una risorsa ma la risposta si è persa, il secondo può crearne un duplicato. Per le mutazioni servono chiavi di idempotenza, lookup prima della scrittura oppure uno stato transazionale che permetta di capire che cosa sia già successo.

Lo stesso vale per il ragionamento. “Riprova” senza nuove informazioni produce spesso la stessa traiettoria. Un retry utile cambia qualcosa: recupera lo stato attuale, restringe le opzioni o consegna all’agente l’errore verificato invece della sua interpretazione precedente.

Un modello migliore non elimina il problema

Aumentare l’affidabilità di ogni singolo passaggio aiuta moltissimo, perché la curva è moltiplicativa. Ma non cambia la forma del problema. Anche un modello che fa la cosa giusta il 99% delle volte ha soltanto circa l’82% di probabilità di attraversare venti decisioni indipendenti senza un errore.

L’obiettivo dell’architettura non è quindi sperare in un 100% locale. È ridurre il numero di decisioni irreversibili, verificare ogni mutazione importante e fare in modo che un errore non possa propagarsi per altri nove passaggi.

Che cosa portarsi a casa

Gli agenti stallano nei workflow lunghi perché la reliability locale si moltiplica e perché gli errori silenziosi diventano stato. La soluzione non è una catena di prompt più lunga: sono post-condition verificabili, checkpoint, idempotenza e meno libertà nei passaggi deterministici.

Se il passaggio nove fallisce, il sistema migliore non ricomincia dal primo. Sa esattamente che cosa è già vero.