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. Leggetelo dall’alto verso il basso per individuare la posizione del vostro team: quali fasi sono già coperte dai vostri strumenti, quale ciclo state già gestendo con un altro nome e quale vocabolario utilizzereste per etichettare i risultati. Tutto ciò che è riportato qui è autonomo: nulla di tutto ciò richiede l’adozione della nostra pratica, 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 un modo per aggirarlo, 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 l’attrito; ben pochi, invece, lo trasformano in soluzioni.

Palcoscenico	La domanda a cui risponde	Opzioni	Termine relativo ai professionisti
0 · Hosting	Dove viene eseguito l’agente?	CLI locale · web · IDE · CI/headless · pianificato	—
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	—
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?	trace-mining vs aggregazione di artefatti · sweep vs evento · deduplicazione	—
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 si arrestasse; 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 contrapposta alla riproducibilità e all’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, rifiuti di autorizzazioni, conteggi dei cicli) è automatica ma superficiale: rileva ciò, non il perché. Le configurazioni più efficaci utilizzano un approccio triangolare: la telemetria indica 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 al grado di dipendenza dalla 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 poco preciso), 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 buon documento e dove si trova. Un documento utile riporta riferimenti a prove concrete (cosa è accaduto, quanto è costato), utilizza un’unica etichetta tratta da un vocabolario prestabilito in modo che i documenti siano comparabili in un secondo momento e si conclude con una proposta relativa al passo successivo. Per quanto riguarda la sua collocazione, ciascuna opzione presenta 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 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. Nessuna di queste soluzioni è specifica del codice: anche il registro degli account di un 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 denominata soggetta ad attacchi e derive (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 redatti deliberatamente: 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 prioritario per il team.

Fase 5: Sintesi e individuazione dei bersagli

Due passaggi. Raggruppamento e valutazione: raggruppare i risultati in modelli, classificati in base alla frequenza × costo; è proprio a questo che servono gli schemi di classificazione riportati di seguito. Individuare il livello appropriato: indirizzare ciascun modello al 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 orientamento: ridimensionare la memoria effimera, promuovere l’apprendimento duraturo nel controllo delle versioni — la documentazione di Windsurf/Devin suggerisce di trasformare le lezioni ricorrenti in regole o in AGENTS.md (il file delle istruzioni permanenti che gli agenti leggono) piuttosto che affidarsi alle memorie automatiche, le linee guida del Codex di OpenAI affermano che il caso in cui si commetta lo stesso errore 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 essere eliminata. Un giudizio di sintesi è facile da trascurare: non tutto l’attrito è uno spreco. In parte 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 che viene segnalata ma non viene mai implementata, o che viene implementata senza cambiare nulla, è pura messinscena. Questa è la condizione descritta da Garg nel Feedback Flywheel e la premessa della compounding engineering: ogni correzione semplifica 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
Ingegneria dei circuiti / Ingegneria dei composti	un professionista	regole personali, indicazioni, linee guida
agent-retro	una sessione	modifiche alle impostazioni e alle configurazioni per singola sessione, ricavate dalla trascrizione
Sensori per la progettazione di 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
Sognare (Anthropic, OpenAI)	la memoria di una piattaforma	estrazione, durante i periodi di inattività, della cronologia delle sessioni sotto forma di differenze di memoria a intervalli prestabiliti, a livello dell’intera flotta
Motore LangSmith / Argomenti 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 durante le sessioni e archiviazione automatica dei ticket
Approfondimenti sulla sessione 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)
Feedback Flywheel (Garg)	i materiali di un team	sintetizzare le conoscenze acquisite in documenti di riferimento, 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 proprio 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 renderla operativa. Questa è la nostra interpretazione del concetto, ed è l’unico punto in cui emerge la prospettiva specifica 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.

I sistemi di classificazione

Per raggruppare i punti di attrito occorrono categorie, e gli schemi di riferimento del settore classificano elementi diversi; più che rivali, sono strumenti orientati verso questioni diverse:

Schema	Cosa comprende	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 Sue tracce	a risposta aperta; le categorie emergono dai vostri 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 su 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 degli agenti di codifica in produzione
Il nostro vocabolario relativo alle cause alla radice	perché si sono verificati attriti nella collaborazione	10 etichette / 5 gruppi; il gruppo indica 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 è suddiviso in versioni e modificabile

agent-errorDue 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’osservazionework-material-friction rimanda al materiale stesso — debito tecnico nel codice, oppure un account, un tabellone 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 di tipo -style dovrebbero essere l’eccezione, non la regola. La scuola di ingegneria dell’harness 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 propria posizione

Una breve analisi diagnostica. Esamini le fasi e contrassegni ciò che ha già a disposizione:

• 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 gli attriti (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, con 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? Definire l’ambito in base a dove verrebbero applicate le correzioni, in modo che 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 illustra la storia in chiave narrativa; i capitoli successivi trattano la cattura dell’attrito nel momento stesso, la raccolta di spunti tra una sessione e l’altra, la decisione di alto livello e come si presenta nella pratica una sede a livello di team. Iniziate da qualsiasi riga vuota.

Capitolo successivo: Come si presenta un registro delle frizioni ben strutturato — la registrazione immediata, le etichette relative alle cause alla radice e le regole relative a ciò che non va mai registrato.