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

TeamRetro si interessa 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 è esposto in modo sistematico. Se preferite iniziare dalla narrazione, partite dall’introduzione alla guida e poi tornate qui.

Di cosa tratta questa pagina

Tre aspetti, in ordine: il ciclo di vita che un singolo 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 ciò che è riportato qui è autonomo: nulla di tutto ciò richiede l’adozione delle nostre pratiche, delle nostre etichette o del nostro prodotto.

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

Quando un agente impegnato in attività concrete incontra un ostacolo (un documento mancante, un’istruzione ambigua, uno strumento inaffidabile), tale segnale è effimero: l’agente 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 descrivono 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 monitora 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 codice, 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 · registri/tracce · ticket · commit contrassegnati	codifica aperta, memoria episodica
4 · Raccolta	Come si procede oltre 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?	raggruppamento + punteggio, quindi smistamento in base all’altitudine	codifica assiale, tassonomia dei guasti
6 · Chiudere il cerchio	La soluzione ha ridotto gli attriti futuri?	misurare l’andamento	Volano di retroazione, ingegneria compounding

Fase 0: Hosting

Tutto ciò che avviene a valle 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ù oggettiva ma richiede un secondo passaggio. La correzione umana rappresenta il segnale di massima qualità e rimane ancora quello predominante: uno studio condotto su otto settimane di produzione 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 autorizzazione, 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 qualcosa non lo provochi. 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 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 affinché i documenti 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 (azionabili 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 quando il lavoro viene 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 basano 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: economico, ma efficace solo nella misura in cui la Fase 3 è condotta con rigore); le vere pipeline 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 selezione dei bersagli

Due passaggi. Raggruppamento e valutazione: raggruppare i risultati in modelli, 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 al giusto livello di soluzione, da quello effimero a quello strutturale (memoria → competenza/suggerimento → 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 convergito indipendentemente sulla stessa tendenza: ridimensionare la memoria effimera, promuovere l’apprendimento duraturo verso il controllo delle versioni. I documenti di Windsurf/Devin suggeriscono 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 di «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 scomparire. 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, oppure che viene implementata senza apportare alcun cambiamento, è pura messinscena. Questa è la condizione descritta da Garg nel Feedback Flywheel e la premessa della compounding engineering: ogni correzione rende più semplice l’unità di lavoro successiva, purché 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 tramite
Ingegneria dei circuiti a ciclo chiuso / 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 che circonda il modello)	integrazione degli strumenti di feedback nativi (test, linter, CI) nel ciclo dell’agente
Sognare (Anthropic, OpenAI)	la memoria di una piattaforma	estrazione in tempo inattivo della cronologia delle sessioni in differenze di memoria a intervalli, a livello di 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 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 si svolge 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 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.

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 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 Suoi dati	metodologia, non un insieme prestabilito; l’analisi delle vostre tracce rappresenta “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 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 è soggetta a revisione

Due note di lettura. Innanzitutto, gli assi sono effettivamente diversi: 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 pannello 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 consiste nel mantenere un piccolo vocabolario fisso 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 agent-error-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. 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 coperti. 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’interruzione, una convenzione relativa ai file di contesto) → La monitoraggio è garantito; 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 soluzioni (Engine, Topics, Signals) → sintesi a livello di stack, per il traffico che lo stack rileva.
• Qualcuno esamina periodicamente le varie 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à attribuire. Si noti la questione relativa all’ambito della revisione che ne deriva: quale attività rientra in un unico ambito di 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, la raccolta di spunti tra una sessione e l’altra, la decisione sull’altitudine e come si presenta nella pratica una sede a livello di squadra. Inizi da dove si trova la sua riga vuota.

Capitolo successivo: Come si presenta un buon registro degli attriti tratta della registrazione immediata degli eventi, delle etichette relative alle cause alla radice e delle regole relative a ciò che non va mai registrato.