La mappa: cicli di retroazione degli agenti, strumenti e approcci

TeamRetro è interessata a ogni ciclo di miglioramento continuo intrapreso dai team; il lavoro assistito dall’intelligenza artificiale è un nuovo ambito che stiamo analizzando attraverso la nostra ottica retrospettiva. Questa pagina costituisce il documento di riferimento complementare alla presente guida: l’intero argomento è presentato in modo sistematico. Se preferite iniziare dalla narrazione, partite dall’introduzione della guida e poi tornate qui.

Di cosa tratta questa pagina

Tre aspetti, in ordine: il ciclo di vita che un singolo caso di attrito percorre dal momento in cui si verifica fino alla sua risoluzione; i cicli denominati che il settore ha sviluppato per gestire tale ciclo di vita, ordinati in base al livello a cui ciascuno opera; e gli schemi di classificazione in uso per definire cosa è andato storto. Legga il documento dall’alto verso il basso per individuare la posizione del Suo team: quali fasi sono già coperte dai Suoi strumenti, quale ciclo sta già gestendo con un altro nome e quale vocabolario utilizzerebbe per etichettare i risultati. Tutto quanto qui riportato è autonomo: nulla di ciò richiede l’adozione della nostra prassi, delle nostre etichette o del nostro prodotto.

Il ciclo di vita: sette fasi, dall’attrito alla risoluzione

Quando un operatore impegnato in attività concrete incontra un ostacolo (un documento mancante, un’istruzione ambigua, uno strumento inaffidabile), tale segnale è effimero: l’operatore trova una soluzione alternativa, la sessione termina e la sessione successiva si scontra con lo stesso ostacolo. I modelli di attrito di Rahul Garg definiscono il costo di primo ordine (il «ciclo di frustrazione» generazione → revisione → non idoneità → rigenerazione); il ciclo di vita riportato di seguito illustra il problema di secondo ordine: cosa deve accadere affinché l’attrito venga risolto al livello appropriato. Il divario è misurabile: circa il 90% dei team registra le tracce degli agenti, ma solo circa il 37–52% le valuta sistematicamente (LangChain, giugno 2026). La maggior parte dei team è in grado di individuare gli attriti; ben pochi, invece, li trasformano in soluzioni.

Palcoscenico	La domanda a cui risponde	Opzioni	Termine relativo al professionista
0 · Hosting	Dove viene eseguito l’agente?	CLI locale · web · IDE · CI/headless · pianificato	n/a
1 · Rilevamento	Come si percepisce l’attrito?	autocontrollo · revisione da parte di un agente secondario · correzione umana · telemetria	revisione del tracciato, analisi degli errori
2 · Strumentazione	Come fa l’agente a sapere di doverlo monitorare?	abilità · gancio · convenzione · comando	n/a
3 · Registrazione	Come viene acquisito e dove?	memoria · archivio MCP · log/tracce · ticket · commit contrassegnati	codifica aperta, memoria episodica
4 · Raccolta	Come si fa a raccogliere informazioni al di là di una singola sessione?	estrazione delle tracce vs aggregazione degli artefatti · scansione vs evento · deduplicazione	n/a
5 · Sintesi e selezione dei bersagli	Dati grezzi → modelli → quale livello di correzione?	raggruppare + assegnare un punteggio, quindi smistare in base all’altitudine	codifica assiale, tassonomia dei guasti
6 · Chiudere il ciclo	La soluzione ha ridotto gli attriti futuri?	misurare l’andamento	Volano di retroazione, ingegneria compounding

Fase 0: Hosting

Tutto ciò che segue dipende dal luogo in cui viene eseguito l’agente. Un agente CLI locale lascia una trascrizione su disco e può scrivere file di memoria; un agente CI o headless può essere effimero, e la sua unica traccia è costituita da ciò che ha registrato prima che il container terminasse; un agente web o IDE conserva una cronologia lato server che è possibile interrogare ma non analizzare con grep; un agente pianificato viene eseguito senza supervisione umana. L’hosting definisce le opzioni disponibili per ogni fase successiva: cosa è osservabile, dove lo stato può persistere e chi (o cosa) può esaminarlo. Il compromesso: una maggiore osservabilità locale a fronte della riproducibilità e dell’archiviazione centralizzata delle esecuzioni ospitate.

Fase 1: Individuazione

Quattro canali, raramente esclusivi. L’autocontrollo (l’agente riconosce i propri tentativi ripetuti e i propri passi indietro) è il metodo più economico ma anche il più distorto: l’agente non sa ciò che non sa. La revisione da parte di un agente secondario, in cui un agente nuovo legge la trascrizione a posteriori, è più obiettiva ma richiede un secondo passaggio. La correzione umana rappresenta il segnale di massima qualità e rimane ancora quello predominante: uno studio di produzione della durata di otto settimane ha rilevato che circa il 70% degli errori silenziosi è stato individuato per la prima volta da un essere umano che ha notato che qualcosa non quadrava (arXiv 2606.14589). La telemetria (tassi di errore degli strumenti, negazioni di autorizzazioni, conteggi dei cicli) è automatica ma superficiale: rileva ciò, non il perché. Le configurazioni più efficaci utilizzano un approccio triangolare: la telemetria segnala dove cercare, mentre una fase di revisione spiega il motivo.

Fase 2: Strumentazione

Un agente non registrerà alcun attrito a meno che non vi sia un fattore che lo determini. Le opzioni, in base a quanto si basano sulla memoria del modello, sono: una abilità (una procedura esplicita e trasferibile invocata in un punto di interruzione: chiara, ma deve effettivamente attivarsi), un hook (si attiva automaticamente all’avvio o alla chiusura della sessione: affidabile, ma generico), una convenzione (un’istruzione contenuta in un file di contesto: infrastruttura nulla, basata sulla fiducia) oppure un comando (attivato dall’utente: deliberato, ma subordinato all’intervento umano). Questa è la fase più spesso tralasciata, ed è il motivo per cui così tanti attriti non vengono registrati: nessuno ha detto all’agente di controllare.

Fase 3: Registrazione

Due domande: cosa contiene un registro valido e dove viene archiviato. Un registro utile riporta riferimenti a prove concrete (cosa è accaduto, quanto è costato), utilizza un’unica etichetta tratta da un vocabolario prestabilito in modo che i registri siano successivamente comparabili e si conclude con una proposta relativa al passo successivo. Per quanto riguarda la sua collocazione, ciascuna opzione comporta un vero e proprio compromesso: file di memoria (duraturi e a basso attrito, ma privati e con una struttura poco rigida), un archivio MCP (condiviso e interrogabile, ma richiede un server), log/tracce (automatici e completi, ma il segnale è sepolto nel rumore), ticket (attuabili e visibili al team, ma pesanti per ogni singola voce), oppure commit e PR contrassegnati, ad esempio un’etichettawork-material-friction che collega l’attrito alla modifica esatta, sebbene solo laddove il lavoro venga inserito nel controllo di versione. Nulla di tutto ciò è specifico del codice: anche il registro di un account del team multimediale o la cronologia annotata di una coda di assistenza costituiscono substrati di registrazione. Un avvertimento che vale per qualsiasi substrato su cui gli agenti si baseranno in seguito: la memoria scritta dagli agenti costituisce una superficie di attacco e deriva ben identificata (OWASP Agentic Top 10, ASI06), un argomento a favore di scritture documentate e sottoposte a revisione.

Fase 4: Raccolta

L’attrito in una singola sessione è un rumore; lo stesso attrito che si ripete in otto sessioni costituisce un problema di processo. La scelta strategica è tra il trace-mining (rilettura delle trascrizioni grezze: completo, ma costoso e con un forte impatto sulla privacy) e l’aggregazione degli artefatti (analisi dei record scritti in modo mirato: economica, ma efficace solo nella misura in cui la Fase 3 è condotta con rigore); i flussi di lavoro reali combinano entrambe le approcci. Seguono poi la cadenza (un’analisi programmata contro la raccolta a fine sessione) e il lavoro poco affascinante della deduplicazione: lo stesso attrito espresso in cinque modi diversi da cinque persone deve essere sintetizzato in un unico modello con un conteggio accurato. È nella raccolta che emerge il valore, poiché è l’aggregazione a ridefinire le priorità: un fastidio di cinque minuti che nessuno risolverebbe individualmente rappresenta, nel complesso, un costo rilevante per il team. Per un esempio concreto di raccolta tra persone anziché tra sessioni, osservi come cinque di noi abbiano messo in comune i propri ricordi privati relativi al Claude Code per trasformarli in regole condivise.

Fase 5: Sintesi e selezione dei bersagli

Due passaggi. Raggruppamento e valutazione: raggruppare i risultati in schemi, ordinati in base alla frequenza × costo; è proprio a questo che servono gli schemi di classificazione riportati di seguito. Individuare il livello appropriato: indirizzare ciascun modello verso il giusto livello di soluzione, da quello effimero a quello strutturale (memoria → competenza/prompt → ambiente e configurazione → documentazione → il materiale di lavoro stesso → processo → strumento o fornitore a monte). Se si punta troppo in basso (una nota privata nella memoria per ciò che in realtà è un documento di squadra mancante), l’attrito si ripresenta per tutti gli altri; se si punta troppo in alto (una nuova competenza per un caso isolato), si appesantisce un artefatto fino a renderlo illeggibile. Il settore ha raggiunto indipendentemente lo stesso gradiente: ridimensionare la memoria effimera, promuovere l’apprendimento duraturo verso il controllo di versione. La documentazione di Windsurf/Devin suggerisce di trasformare le lezioni ricorrenti in regole o in AGENTS.md (il file di istruzioni permanenti letto dagli agenti) piuttosto che affidarsi alla memoria automatica; le linee guida del Codex di OpenAI indicano che il caso di «stesso errore ripetuto due volte» comporta un aggiornamento di AGENTS.md, e la memoria di Copilot scade dopo 28 giorni per impostazione predefinita: la memoria non promossa dovrebbe scomparire. Un giudizio di sintesi è facile da trascurare: non tutto l’attrito è uno spreco. Una parte di esso costituisce la superficie di controllo: «l’attrito è ciò che è necessario… per governare» (una sintesi dell’intervento di Ronacher all’AIE Europe), pertanto la selezione prevede la scelta tra «mantenere o eliminare», non solo «correggere».

Fase 6: Chiudere il ciclo

Il vero banco di prova dell’intero ciclo di vita: l’attrito di quel tipo tende a diminuire nel corso delle sessioni successive? Una correzione segnalata ma mai implementata, oppure implementata ma che non cambia nulla, è solo una messinscena. Si tratta della condizione del “Feedback Flywheel” descritta da Garg e della premessa della ingegneria cumulativa: ogni correzione rende più facile l’unità di lavoro successiva, a condizione che il ciclo si chiuda effettivamente.

I cicli denominati, per livello operativo

Il settore ha concordato su questo ciclo di vita, che è stato denominato con almeno una mezza dozzina di nomi diversi. Sono tutti validi; nulla in questa pagina sostituisce alcuno di essi. L’unico criterio di ordinamento applicato in questa tabella è il livello al quale opera ciascun ciclo, e l’aspetto da notare una volta effettuato l’ordinamento è il seguente:

Ciclo	È in programma alle	Chiude il ciclo mediante
Loop Engineering / Ingegneria dei composti	un professionista	regole personali, indicazioni, linee guida
apprendimento-continuo-v2 (Everything Claude Code)	un professionista	un agente in background che trasforma i registri delle chiamate agli strumenti in regole con punteggio di affidabilità, caricate all’avvio della sessione
agent-retro	una sessione	modifiche alle impostazioni e alle configurazioni per singola sessione, ricavate dalla trascrizione
Sensori per l’ingegneria dei cablaggi (Thoughtworks)	l’infrastruttura di un codice sorgente (la struttura portante attorno al modello)	integrazione degli strumenti di feedback nativi (test, linter, CI) nel ciclo dell’agente
Dreaming (Anthropic, OpenAI)	la memoria di una piattaforma	estrazione in tempo di inattività della cronologia delle sessioni in differenze di memoria a intervalli prestabiliti, a livello di flotta
Motore LangSmith / Argomenti di Braintrust	un unico stack di osservabilità	raggruppamento dei guasti di produzione in problemi, redazione di PR e valutazioni
Segnali di fabbrica	una piattaforma unica per gli agenti	individuazione dei modelli di attrito nelle sessioni e archiviazione automatica dei ticket
Analisi delle sessioni di gh-aw (GitHub)	le sessioni di una piattaforma	rapporti automatizzati di analisi delle sessioni relativi alle esecuzioni del flusso di lavoro degli agenti (esempio con 50 sessioni)
Volano di retroazione (Garg)	i materiali di un team	sintetizzare le conoscenze acquisite in documenti introduttivi, comandi, procedure operative e linee guida

Rilegga la colonna centrale: un professionista, una sessione, una piattaforma, uno stack. Quasi ogni ciclo in questo ambito opera a livello individuale o di flotta: una persona e il suo agente, oppure un fornitore e la sua intera base installata. Solo il volano di Garg si rivolge al team, e il suo elenco di cadenza indica la sede (un punto all’ordine del giorno nella retrospettiva di sprint esistente) senza renderlo operativo. Questa è la nostra interpretazione del genere, ed è l’unico punto in cui emerge la prospettiva propria di questa guida: il livello del team è lo strato aperto (molte persone, molti agenti, più di uno strumento, con i responsabili delle correzioni coinvolti nella stessa conversazione). Se state già eseguendo uno dei cicli sopra descritti, continuate a farlo; il livello del team ne utilizza i risultati, senza entrare in competizione con essi.

Everything Claude Code (ECC), un progetto con licenza MIT, rappresenta l’esempio più chiaro presente nella mappa di un ciclo locale in cui l’agente definisce autonomamente le proprie regole. La sua abilità “continuous-learning-v2” (ECC 2.2.3 al momento della stesura del presente articolo) registra le chiamate agli strumenti tramite un hook di Claude Code. Un agente osservatore in background, in esecuzione su Haiku, legge periodicamente tale registro e genera degli «istinti»: brevi regole di tipo «trigger-and-action», ciascuna con un punteggio di confidenza che aumenta quando il modello viene rilevato nuovamente e diminuisce di settimana in settimana quando non lo è. All’avvio della sessione, per impostazione predefinita, fino a sei «istinti» con un livello di confidenza pari o superiore a 0,7 vengono inseriti direttamente nel contesto dell’agente, senza alcuna fase di revisione. L’osservatore viene fornito disattivato, pertanto la sua attivazione rappresenta una scelta deliberata. Per la configurazione di un singolo utente, si tratta di un ciclo completo. Per un contesto su cui fa affidamento un intero team, invece, filtreremmo le inserzioni: le prove entrano liberamente, le regole vengono escluse tramite revisione.

I sistemi di classificazione

Per raggruppare gli attriti occorrono categorie, e gli schemi di riferimento dei vari ambiti classificano elementi diversi; più che rivali, sono strumenti orientati verso questioni diverse:

Schema	Cosa classifica	Forma	Affidabilità / provenienza
MAST	In che modo i sistemi multi-agente falliscono	14 modalità / 3 categorie	150 tracce esaminate da esperti, convalidate su oltre 1600; κ tra annotatori = 0,88
Scuola di analisi degli errori (Husain/Shankar)	qualunque cosa rivelino le vostre tracce	a risposta aperta; le categorie emergono dai Suoi dati	metodologia, non un insieme fisso; l’analisi delle vostre tracce è «l’attività più importante nelle valutazioni»
A quattro strati (Greyling)	quale livello dello stack ha presentato un errore	4 strati	sintesi delle segnalazioni di guasti sul campo; circa il 9,9% dei guasti è attribuibile al ragionamento basato sui modelli
TraceProbe	Azioni di gestione degli errori nelle tracce	9 azioni	analisi automatizzata delle tracce
Segnali di fabbrica	quale sintomo di attrito si manifesta durante una sessione	7 tipi di segnale	sessioni di codifica degli agenti di produzione
Il nostro vocabolario relativo alle cause alla radice	perché si sono verificati attriti nella collaborazione	10 etichette / 5 gruppi; il gruppo codifica l’altitudine fissa	sessioni di lavoro, sia per sviluppatori che per non sviluppatori; affidabilità inter-valutatore non ancora misurata: l’esperimento è in corso e il vocabolario è gestito per versioni ed è modificabile

Due note di lettura. Innanzitutto, gli assi sono effettivamente distinti: gli schemi dei sintomi (i segnali di Factory) indicano che una sessione è andata male; gli schemi a livelli (Four-Layer) indicano in quale punto dello stack si è verificato il problema; un vocabolario delle cause ne spiega il motivo, ed è proprio questo che consente a un’etichetta di indirizzare parzialmente la propria soluzione (un risultatowork-material-friction rimanda al materiale stesso: debito tecnico nel codice, oppure un account, un pannello di controllo o un modello intricato al di fuori di esso; un’etichetta di briefing rimanda al processo). In secondo luogo, la tensione tra «universale» ed «emergente» è reale: le tassonomie fisse garantiscono comparabilità e affidabilità misurabile nell’etichettatura (il κ = 0,88 di MAST rappresenta lo standard di riferimento), mentre le categorie emergenti si adattano alla vostra effettiva distribuzione dei fallimenti. Una via di mezzo praticabile prevede un vocabolario fisso ridotto per l’aggregazione, con note di evidenza in codice aperto sotto ciascuna etichetta. E un monito che l’intero settore si è guadagnato: le etichette in agent-errorstile - dovrebbero essere l’eccezione, non la regola. La scuola di «harness engineering» rifiuta esplicitamente tale riflesso, in cui l’ingegnere attribuisce la colpa al modello e lo archivia sotto la voce «in attesa della prossima versione»; occorre invece correggere l’harness (Osmani, Agent Harness Engineering). L’analisi a quattro livelli attribuisce solo circa il 9,9% dei fallimenti al ragionamento del modello.

Indichi la Sua posizione

Una breve analisi diagnostica. Esaminate le fasi e contrassegnate ciò che avete già:

• Disponete di tracce o registri di sessione (strumenti di osservabilità, JSONL su disco, cronologia lato server) → Il rilevamento e la registrazione sono garantiti. I dati di LangChain indicano che è proprio a questo punto che la maggior parte dei team si ferma.
• Qualcosa ricorda all’agente di registrare l’attrito (un’abilità, un gancio di interruzione, una convenzione relativa ai file di contesto) → La strumentazione è garantita; se nulla lo fa, questa è solitamente la prima soluzione più economica.
• Aggiorna i file AGENTS.md / CLAUDE.md ogni volta che si verifica una ricorrenza → sta effettuando la sintesi a livello individuale, seguendo lo schema del Codex che prevede di ripetere lo stesso errore due volte.
• La vostra piattaforma cura la memoria per voi (consolidamento in stile “Dreaming”, memoria “Copilot”) → raccolta e sintesi a livello di flotta, all’interno di tale piattaforma.
• Il vostro stack di osservabilità raggruppa i guasti e le bozze delle correzioni (Engine, Topics, Signals) → sintesi a livello di stack, per il traffico che lo stack rileva.
• Qualcuno esamina periodicamente le sessioni, le persone e gli strumenti, e i responsabili delle soluzioni decidono di comune accordo → Raccolta e sintesi a livello di team. Questa è la riga che la maggior parte dei team lascia in bianco.

La lacuna più comune, secondo la nostra osservazione, è proprio quell’ultima riga: la visione d’insieme che abbraccia strumenti e persone, e le decisioni discrezionali che ne derivano: mantenere o eliminare, a quale livello, quale priorità. Si noti la questione relativa all’ambito della revisione che ne deriva: quale attività rientra in un determinato ambito per una specifica discussione? Il repository, il prodotto, l’account pubblicitario, la casella di posta dell’assistenza, il coinvolgimento del cliente? Si definisca l’ambito in base a dove verrebbero applicate le correzioni, e i casi non legati al codice vengano indirizzati con la stessa naturalezza di quelli relativi al codice.

Il resto di questa guida affronta i vari livelli uno alla volta: l’introduzione espone la storia in forma narrativa; i capitoli successivi trattano come cogliere l’attrito nel momento stesso in cui si verifica, come raccogliere i risultati tra una sessione e l’altra, la decisione sull’altitudine e come si presenta, nella pratica, una sede a livello di squadra. Iniziate da dove si trova la vostra riga vuota.

Capitolo successivo: Le caratteristiche di un buon registro dei problemi di attrito comprendono la registrazione del momento in cui si verifica il problema, l’indicazione delle cause alla radice e le regole relative a ciò che non va mai registrato.