GSD: l'orchestratore non esegue, ed è questa la ragione per cui il sistema regge

La prima volta che ho fatto lavorare più agenti insieme su un progetto vero, il risultato è stato peggiore di quando lavoravo da solo con una singola sessione. Più output, più velocità apparente, e un pomeriggio a rimettere insieme i pezzi perché due di loro avevano toccato lo stesso file con idee diverse su cosa dovesse contenere.

Il problema non era il modello. Era che non avevo un'architettura: avevo tante conversazioni.

GSD è il nome che uso per l'architettura che ho costruito dopo. Sta per Get Stuff Done, gira in produzione da metà febbraio 2026, e la sua regola centrale sta in tre parole: l'orchestratore non esegue.

Cos'è GSD, detto senza decorazioni

GSD è un framework di orchestrazione. La sessione principale con cui parlo non scrive codice, non fa deploy, non tocca file. Legge, valuta, decide a chi passare il lavoro, mi chiede quello che serve chiedere, e mette insieme gli esiti. Il lavoro vero lo fanno sub-agenti che girano in parallelo e riportano.

Non è un metodo di project management. Non sostituisce una to-do list, non organizza le tue scadenze, non ti dice su cosa lavorare. Fa una cosa sola: rende ripetibile il modo in cui un compito viene assegnato, eseguito, verificato e accettato.

A metà febbraio 2026, quando il sistema è entrato in produzione, sopra ci giravano 21 automazioni. Oggi, 27 luglio 2026, sono circa una sessantina distribuite su cinque runtime diversi, contate una per una alla fonte. Cito volentieri i due numeri con le loro date, perché la cifra vecchia continua a circolare nei miei materiali come se fosse il conteggio di adesso, e non lo è più da mesi.

Il numero cresce e non è quello il punto. Il punto è che il modo di aggiungerne una è rimasto lo stesso.

Primo pilastro: il contesto è un file, non una conversazione

Il collo di bottiglia del lavoro con l'AI non è il modello. È che ogni sessione nuova comincia senza sapere niente, e tu la riempi a mano di informazioni che hai già dato venti volte.

La risposta di GSD è banale e ha impiegato mesi a diventare disciplina: il contesto vive in file versionati che l'agente legge da solo all'avvio.

Nel mio caso è un documento di istruzioni per progetto, letto a ogni apertura di sessione, più i documenti a cui quello rimanda. La gestione della memoria di progetto in Claude Code è documentata e funziona come descritto, ma il valore non sta nel meccanismo: sta in cosa ci metti dentro.

Cosa ci va, e cosa no

Ci va quello che una sessione nuova non può dedurre leggendo il repository:

1. Le decisioni prese e il motivo, soprattutto quelle contro-intuitive
2. I vincoli che non si negoziano (schemi, campi corretti, regole legali, limiti di piattaforma)
3. Le trappole già pagate, con la data dell'incidente
4. Dove sta la verità su ogni argomento, cioè quale file è autorevole

Non ci va quello che il codice dice meglio del testo. Una descrizione in prosa di una funzione diverge dalla funzione il giorno dopo, e a quel punto è peggio del silenzio: è un'informazione sbagliata scritta con autorità.

La tabella di instradamento

Il pezzo che ha cambiato di più la resa quotidiana è una tabella in cima al documento principale: domanda a sinistra, file da leggere a destra. Nient'altro.

Serve perché un documento di contesto che cresce diventa una zavorra: paghi per caricarlo in ogni sessione e l'agente ne usa il tre per cento. Con la tabella, il documento principale resta corto e contiene solo l'evergreen e le regole bloccanti; tutto il resto è raggiungibile in un salto.

Accanto alla tabella c'è una regola scritta in maiuscolo, che è la più importante di tutto il sistema: la routing table è autorevole, non rispondere a memoria. Un agente che risponde da quello che ricorda invece che dal file canonico produce risposte plausibili e sbagliate, che è la categoria di errore più costosa da scoprire.

Secondo pilastro: i ruoli sono configurazione, non prompt

Per mesi l'ho fatto a mano. Ogni volta che delegavo, riscrivevo il prompt: "sei un agente che verifica, non toccare nulla, riportami solo i fatti". Ogni volta un po' diverso. Il che significa che il comportamento era un po' diverso, e non sapevo mai quale variante avevo usato.

Oggi i ruoli sono file versionati dentro il progetto, che ogni sessione eredita in automatico. Sono subagent con un frontmatter che dichiara nome, descrizione, strumenti concessi, strumenti vietati e modello, e un corpo che è il loro prompt di sistema.

I quattro che uso:

Il verificatore. Gira su Sonnet, è di sola lettura. Lo chiamo quando la domanda è "guarda com'è davvero e riportami i fatti": stato dei processi, inventari, conteggi, letture da fonti live, controlli ripetitivi. Veloce ed economico, ed è il ruolo che uso più spesso di tutti.

Il builder. Gira su Opus, tocca i file. Lavoro delicato dove un errore costa: modifiche chirurgiche, deploy, operazioni git non banali, patch ai gate, migrazioni. Ha nel prompt l'obbligo di fermarsi e chiedere quando manca un pezzo di contesto critico, invece di provare e vedere.

Il ricercatore. Gira su Opus e consegna un report datato con le fonti. Serve quando la risposta a memoria non basta: documentazione ufficiale, normativa, note di rilascio. Ogni affermazione con la sua fonte e un marcatore esplicito dove la fonte non è confermata.

Il revisore. Gira su Opus ed è ostile per mestiere. Prova a rompere una specifica, un contenuto, un piano. Restituisce un verdetto con le severità e non applica correzioni: le trova, e poi decido io.

Perché due sono di sola lettura per contratto

Verificatore e revisore hanno gli strumenti di scrittura negati nel frontmatter, non solo scoraggiati nel prompt.

È una distinzione che sembra pedante e non lo è. Un prompt è una richiesta: sotto pressione, con un compito ambiguo, un modello può ragionevolmente decidere che sistemare quella riga era nello spirito dell'incarico. Uno strumento che non esiste non si può usare.

La stessa logica vale per la sequenza: prima l'agente che verifica, poi quello che applica. Mai fondere i due ruoli in uno, perché chi ha appena proposto una soluzione non è la persona giusta per giudicarla.

Come si sceglie il modello, e il giorno in cui ho sbagliato

La regola è semplice: Sonnet 5 per verifiche, inventari, ricognizioni. Opus 5 per costruire, ricercare, giudicare. Haiku 4.5 per compiti stretti dove conta solo la latenza. I nomi e le sigle stanno nella pagina dei modelli, e vale la pena controllarla invece di andare a memoria: cambiano più in fretta di quanto uno se lo aspetti.

Il 21 luglio 2026 ho violato la mia stessa regola nel modo più stupido possibile. Uno script di workflow lanciava nove agenti, e in nessuno dei nove avevo passato il parametro del modello. Il valore predefinito è "eredita quello della sessione", quindi tutti e nove hanno girato sul modello della sessione principale invece che su quello del loro ruolo. Costo dell'omissione: circa 721.000 token per un lavoro che ne avrebbe chiesti una frazione.

L'ho scritto nel file dei ruoli, con la data. Se ti interessa il ragionamento su quale modello scegliere per quale compito, l'ho sviluppato in questo confronto.

Terzo pilastro: i cancelli li tiene una macchina

Questa è la parte che mi ha fatto risparmiare più tempo, e la meno intuitiva.

Se un controllo può essere fatto da uno script, non lo fa un modello. Non perché il modello sbagli spesso, ma perché sbaglia in modo non riproducibile: oggi passa, domani no, e non sai perché.

Nel mio sistema i controlli deterministici sono script che girano dentro il ciclo di igiene notturna. Verificano cose stupide e verificabili: che non ci siano sezioni duplicate nel file condiviso, che le note di memoria rispettino il contratto di formato, che ogni priorità dichiarata abbia una data di verifica recente, che nessun pattern da credenziale compaia dove non deve.

Nessuno di questi controlli richiede intelligenza. Tutti richiedono di essere fatti ogni singola volta, che è precisamente la cosa in cui un umano e un modello sono entrambi inaffidabili.

Cosa lascio a un giudizio, allora

Al modello resta quello che un'espressione regolare non sa fare: se questo testo suona come me, se questa architettura ha un punto di rottura che non ho considerato, se questa affermazione regge una domanda ostile.

E anche lì c'è una regola procedurale che non salto: prima di modificare qualsiasi file che genera contenuto o che fa da cancello, la suite di valutazione deve essere verde prima e verde dopo, con la differenza nel commit. Se la tocco e il verde sparisce, il problema è la mia modifica, non la suite.

Come i pezzi si parlano senza parlarsi

Con una trentina di processi che girano su runtime diversi, la domanda pratica è: come fa quello delle 21:30 a sapere cosa ha trovato quello delle 09:00?

La risposta che uso è un file condiviso in sola aggiunta, una sezione per argomento. Ogni processo scrive quello che ha trovato, i processi a valle leggono quelli a monte nello stesso ciclo. Non è elegante, ed è la ragione per cui funziona: è ispezionabile a occhio, versionato, e non richiede un servizio in più da presidiare.

Le due regole che lo tengono in piedi: chi possiede una sezione la sostituisce invece di accodare all'infinito, e un guardiano deterministico verifica ogni notte che nessuna sezione sia stata duplicata. Il secondo controllo esiste perché la duplicazione è successa davvero, più di una volta, quando due processi hanno scritto insieme.

La memoria: cosa merita di sopravvivere alla sessione

Un sistema di agenti che riparte da zero ogni volta è un sistema che ti fa rispiegare le stesse cose in eterno. Ma una memoria che accumula tutto diventa rumore.

Il criterio che uso: finisce in memoria un fatto durevole e non deducibile dal repository. Una decisione con il suo perché, una trappola pagata con la sua data, lo stato reale di un progetto. Non ci finisce quello che si ricava leggendo il codice o guardando la cronologia dei commit.

Ogni fatto è una nota singola, con un indice che le elenca. Le note di stato portano una data di ultima verifica, e qui c'è la regola che mi ha convinto di più: quando una sessione verifica un fatto alla fonte, aggiorna la data anche se non cambia una parola. La conferma è un aggiornamento. Senza questa regola non riesci a distinguere una nota vera da una nota vecchia che nessuno ha più guardato.

Dal 26 luglio 2026 le relazioni fra note non vivono più solo in prosa: si dichiarano nel frontmatter con quattro tipi di legame (una nota ne sostituisce un'altra, ne è sostituita, la contraddice, o la presuppone) e un controllo automatico verifica che il bersaglio esista e che i legami siano simmetrici. Il pezzo interessante non è la sintassi: è che i legami dichiarati permettono un recupero deterministico del contesto giusto prima ancora di chiamare il modello.

Il lavoro sporco che nessuno racconta

Le presentazioni sui sistemi multi-agente si fermano all'architettura. I problemi veri, quelli che ti costano il pomeriggio, sono altri due.

Le risorse temporanee che nessuno spegne

Il 21 luglio 2026 ho trovato ancora attivo un processo pianificato che avevo creato per un singolo evento del giorno prima. Nessun danno, per fortuna, ma la lezione è generale: un'azione con una scadenza non può vivere in un documento in prosa.

Da lì è nato un principio operativo che applico da allora: una risorsa temporanea creata in sessione, che sia un job pianificato, un flag, una credenziale di prova, o si spegne nella stessa sessione che ne verifica l'esito, oppure nasce già auto-terminante. Se davvero deve restare aperta oltre la sessione, va scritta nel documento di stato con la data, dove i controlli automatici e l'orchestratore la vedono. Mai solo in una nota.

Tre agenti, un solo indice git

Il 26 luglio 2026 ho avuto tre collisioni in una sola giornata. Più agenti lavoravano sullo stesso checkout, quindi condividevano l'indice git, e più di un commit si è portato dietro file di un'altra sessione.

La correzione è una regola di sintassi, non di architettura: si committa sempre dichiarando esplicitamente i percorsi coinvolti nello stesso comando, così l'operazione ignora quello che altri hanno preparato. Niente aggiunta all'indice e commit come passi separati, niente scorciatoie che prendono tutto.

È il tipo di dettaglio che non compare mai nei racconti sui sistemi di agenti, e che decide se il tuo funziona per una settimana o per sei mesi.

Una settimana vera, non una settimana tipo

Le "settimane tipo" nei post sui framework sono sempre pulite: lunedì pianifico, mercoledì consegno, venerdì retrospettiva. La mia non lo è, e mostrare quella vera è più utile.

Quello che è fisso è poco: un ciclo di igiene notturno che controlla le invarianti e corregge quello che è meccanicamente correggibile, un controllo di salute serale che guarda le fonti vere invece dei log, e un momento a settimana in cui leggo cosa hanno prodotto i cicli di apprendimento.

Tutto il resto è a domanda. E la cosa che rende sostenibile il "a domanda" è che ogni sessione nuova parte già informata: legge il contesto, apre la voce giusta della tabella, sa quali ruoli ha a disposizione. Il tempo di riscaldamento, che era il costo maggiore quando gestivo più progetti in parallelo, è quasi sparito.

Se stai partendo da zero con lo strumento, la base la trovi nella mia guida completa a Claude Code.

Cosa GSD non risolve

Tre cose, e le dico perché il framework non venga comprato per quello che non è.

Non decide cosa vale la pena fare. Un'architettura di orchestrazione esegue meglio, non sceglie meglio. Il rischio concreto è produrre più roba inutile con più efficienza, e ci sono passato: metà del mio sistema, a un certo punto, esisteva per sorvegliare l'altra metà.

Non toglie la responsabilità. Quello che esce firmato col mio nome è mio, che l'abbia scritto io o un agente. Il confine fra cosa delego e cosa no l'ho messo per iscritto, ed è il ragionamento che ho fatto in questo articolo sulla delega.

Non si tiene da solo. I file di contesto divergono, le note invecchiano, i ruoli vanno aggiornati quando cambia il modo di lavorare. La manutenzione è reale, e nel mio caso è il motivo per cui esiste un ciclo di igiene automatico: senza, in due mesi il sistema mente.

Da dove partire domani

Se vuoi provare questo modo di lavorare, l'ordine più corto che conosco è questo.

1. Scrivi il file di contesto del progetto. Trenta righe bastano: vincoli, decisioni prese, dove sta la verità.
2. Aggiungi la tabella di instradamento appena il file supera le due schermate.
3. Definisci due ruoli, non quattro. Uno che verifica in sola lettura e uno che costruisce. Gli altri due arrivano quando servono.
4. Sposta il primo controllo dal modello a uno script. Quello che fai a mano ogni volta e che ogni tanto dimentichi.
5. Scrivi la prima nota di memoria su una trappola che hai già pagato, con la data.

Il passo 4 è quello che restituisce di più. Ogni controllo che sposti su una macchina è una cosa in meno che dipende da come è andata la giornata.

Se vuoi il percorso strutturato per costruirti questo sistema, dalla prima automazione all'orchestrazione, è quello che insegno in Claude Mastery. Se invece hai un caso aziendale con più progetti in parallelo e vuoi capire se questa architettura regge sul tuo, prenota una call e la guardiamo insieme.