Gli agenti, come i programmatori, a volte entrano in cicli di errore — ripetono la stessa correzione fallita ri-alimentando il context con lo stack trace. La differenza è che il programmatore si annoia dopo il secondo tentativo; l’agente è disposto a provare per ore, consumando token e accumulando modifiche sempre più lontane dalla soluzione.

Dopo due cicli falliti, fermati. Non è pigrizia: è efficienza. Il terzo tentativo con lo stesso contesto non produrrà un risultato diverso.

I sintomi del loop 🔄

Il loop di errore non è sempre evidente. Ecco i tre segnali principali:

• Sessioni lunghe senza progresso — stai lavorando da venti minuti su lo stesso file e il codice non migliora, anzi. Ogni intervento crea un nuovo problema.
• Output che ripete lo stesso pattern — l’agente propone la stessa soluzione con varianti cosmetiche, o alterna tra due fix incompatibili senza mai risolverne uno.
• Consumo passivo di token — le sessioni lunghe costano, indipendentemente dall’esito. Quando il costo cresce senza risultato, il rapporto qualità-prezzo è negativo.

Riconoscere un loop è una skill umana, non una capacità dell’agente. Il modello non sa di essere in loop: vede solo il prossimo token da generare.

Undo → Compact → Clear: le tre procedure 🔧

Quando riconosci il loop, tre procedure in sequenza ti riportano in controllo:

Undo immediato — la prima cosa da fare è tornare allo stato precedente. La maggior parte degli strumenti supporta un undo della sessione o del file. Non cercare di “sistemare il fix del fix”: riparti da zero sul file.

Compact per sintetizzare — se la sessione ha prodotto del contesto utile ma è diventata troppo lunga, un’operazione di compact sintetizza la history mantenendo le informazioni rilevanti e scartando il rumore. È come prendere appunti dopo una lunga riunione: tieni le decisioni, butta le divagazioni.

Clear e riavvio — dopo due cicli falliti, cancella la sessione e riparti con un prompt raffinato. Il prompt nuovo deve contenere: il contesto che hai imparato dal fallimento, il vincolo che l’agente ha violato, e un obiettivo più specifico. Non è un riparto da zero: è un riparto con informazioni in più.

Prevenzione con hook 🛡️

Il modo migliore di gestire un loop è non entrare mai in uno. Gli hook deterministici interrompono i loop a costo zero:

• Hook pre-commit che bloccano modifiche che violano vincoli noti (formati, import, regole architetturali).
• Test automatici che girano dopo ogni modifica e interrompono la catena prima che il prossimo step accumuli errori.
• Vincoli nel prompt che l’agente non può ignorare: “non modificare mai il file X”, “esegui sempre il test Y prima di proseguire”.

L’hook non è una restrizione: è una scorciatoia. Dove l’agente avrebbe bisogno di tre cicli per capire che un formato non è accettabile, l’hook lo blocca al primo tentativo.

Regola pratica: dopo 2 cicli falliti, fermati ⏸️

Non esiste un numero magico, ma due è un buon limite. Dopo due tentativi con lo stesso contesto e lo stesso obiettivo, il problema non è l’agente: è il contesto o l’obiettivo.

Non è pigrizia fermarsi dopo due tentativi: è la consapevolezza che il terzo con le stesse informazioni non funzionerà.

Fermarsi significa:

1. rivedere il prompt: cosa manca?
2. rivedere il contesto: quali file o informazioni non hai incluso?
3. rivedere l’obiettivo: è troppo ampio per essere gestito in una sessione?

Spesso la risposta è una combinazione delle tre.

Quando NON usare l’agente ⛔

• Quando il loop è causato da un errore ambientale — dipendenze mancanti, permessi sbagliati, configurazione rotta. L’agente non risolve problemi di infrastruttura: risolvili prima.
• Quando il contesto è intraducibile — alcune informazioni vive solo nella tua testa (business logic, vincoli non documentati). Prima le scrivi, poi le deleghi.
• Quando il task richiede iterazione rapida umana — debug interattivo, esplorazione di opzioni, decisioni architetturali. L’agente non è uno strumento di pensiero: è uno strumento di esecuzione.

Checklist finale ✅

• Riconosco i segnali di loop (sessioni lunghe, pattern ripetuti, token che crescono)?
• Prima di riprovare, faccio undo dello stato precedente?
• Dopo due cicli falliti, interrompo e rivedo prompt/contesto/obiettivo?
• Ho hook pre-commit o test che interrompono automaticamente i loop?
• Il contesto necessario è scritto nel prompt, non solo nella mia testa?

Approfondimenti 📚

• Il ciclo di lavoro — pianifica, esegui, valida: il flusso che previene i loop.
• Scrivere prompt che funzionano — come formulare richieste che riducono il rischio di loop.
• Blog: Context engineering e Maintain a rich context.