Introduzione: che cosa deve sopravvivere a una sessione

Una sessione di lavoro con un agente ha un difetto semplice: finisce.

Dentro quella sessione può succedere molto. Magari stai costruendo un backend, una UI, un servizio. L’agente propone una struttura; tu gli fai notare un vincolo che non poteva conoscere. L’agente trova un’alternativa; tu riconosci un errore che hai già visto mille volte. Insieme cambiate direzione, scartate una soluzione plausibile, stabilite che cosa non deve rompersi e decidete quale evidenza renderà credibile l’output prodotto.

Alla fine resta l’artefatto: codice, test, validazione, configurazione, documentazione. Probabilmente resta anche la conversazione. Ma ciò che ha reso buona quella sessione rischia di non rimanere affatto: perché una proposta è stata rifiutata, quale precedente ha cambiato la decisione, quale eccezione vale soltanto in questo sistema e per quel cliente, in quale punto l’agente deve fermarsi la prossima volta.

Nella sessione successiva, l’agente può avere davanti tutto il repository e non sapere niente di tutto questo. Può rileggere i file e disporre della conversazione, ma non per questo sa che cosa il Senior e l’agente hanno imparato, né conosce la strada percorsa per arrivare a una scelta.

Il costo non è soltanto il tempo necessario a rispiegare. È molto di più. È il rischio di decidere diversamente, perché la ragione della decisione già presa è scomparsa.

Il libro comincia da quella perdita di informazioni.

Prima di chiedersi che cosa un Senior possa delegare, conviene guardare la natura del sistema con cui si ha a che fare.

Un modello linguistico produce risposte probabilistiche a partire dal contesto disponibile e dai dati con cui è stato addestrato. Da solo non apre un file, non esegue un comando e non conserva nulla della sessione precedente.

Un agente nasce quando un framework agentico — il software che circonda il modello e lo mette al lavoro — lo colloca dentro un ciclo. L’accezione è operativa: non la libreria con cui uno sviluppatore si costruisce un agente su misura, ma il software che si adotta già costruito e si configura nei punti che espone. Il framework assegna al modello gli strumenti, gli permette di osservare l’ambiente, interpreta le richieste del modello, esegue le azioni e al passo successivo gli restituisce gli effetti. La parte del framework che esegue quel ciclo è il runtime. Il comportamento del modello dipende quindi anche dal framework che lo ospita: dal modo in cui costruisce il contesto, espone gli strumenti, conserva lo stato, gestisce i permessi, intercetta gli eventi e decide quando il ciclo termina.

Questa composizione rende l’agente molto potente ma anche discontinuo nell’operatività di lungo periodo. La finestra corrente può contenere una discussione molto ricca e perderne il significato alla sessione successiva. C’è di più: al crescere della finestra le prestazioni tendono a peggiorare, sia perché l’attenzione del modello si distribuisce peggio su un contesto lungo, sia perché nel frattempo il contesto accumula informazione superata o contraddittoria. Il fenomeno va sotto il nome di context rot.¹

Il framework può conservare la chat o la cronologia della conversazione. Questa memoria non strutturata, però, non distingue una decisione da un’ipotesi: conserva il risultato senza rendere espliciti l’alternativa scartata, il vincolo che ha determinato la decisione o la condizione che obbligherebbe a riaprirla.

Se poi il Senior cambia framework, cambiano i formati, gli eventi, gli strumenti e i meccanismi di memoria: ciò che era stato appreso rischia di restare intrappolato nell’ambiente che lo ha prodotto.

Un Senior può governare il sistema che si trova davanti? Su questo interrogativo poggia il resto del libro, ma prima di affrontarlo conviene spostare lo sguardo altrove, perché il lavoro vero non si gioca dove sembra.

Quello che fa la differenza è ciò che accade tra una risposta e l’altra. Il Senior porta esperienza puntuale, responsabilità e conoscenza del sistema; l’agente porta capacità di esplorazione, esecuzione e confronto. Correzioni, obiezioni, decisioni e verifiche danno forma al lavoro. Nel confronto, l’esperienza smette di essere soltanto un ricordo personale e diventa un criterio applicato al progetto.

In questo libro, il termine giudizio indica la capacità, radicata nel contesto, di scegliere in condizioni di informazione incompleta, riconoscere i vincoli strutturali, valutare i compromessi e farsi carico delle conseguenze. L’agente prende già decisioni operative: esplora alternative, ordina i passaggi e sceglie implementazioni entro perimetri definiti. Il giudizio del Senior, però, non si trasferisce in blocco: la responsabilità finale e le decisioni direzionali restano in capo a lui.

Una parte di questo giudizio produce esiti che possono essere resi espliciti: una decisione motivata, un vincolo strutturale da presidiare, una lezione ricavata da un errore, un dubbio da mantenere vivo o una condizione che obbliga a fermarsi.

Questi esiti sono «distillabili»: dal flusso informale del confronto fra Senior e agente si può estrarre la sola parte che ha valore oltre la sessione.

L’obiettivo non è trasferire il giudizio all’agente, ma condensarne le conclusioni — decisioni, vincoli, lezioni — in una forma che l’agente possa consultare nelle iterazioni successive.

La distillazione non ricade però sul Senior come lavoro manuale di fine giornata. È il System Harness a sostenerla (con quale perimetro si vede più sotto): guida l’agente nell’estrarre gli esiti dell’iterazione, dà loro una forma e conserva le tracce oltre la sessione corrente. Il Senior sceglie quali iterazioni valga la pena distillare e quali esiti rendere persistenti; il sistema fa in modo che ciò che passa di lì prenda una forma riutilizzabile.

La distillazione serve a impedire che il giudizio già esercitato evapori alla chiusura della finestra. Che poi quelle tracce tornino davvero utili nell’iterazione successiva è l’ipotesi che il libro mette alla prova, non un risultato acquisito: una traccia recuperata resta contesto da valutare, non un ordine da eseguire. Che una traccia sia vicina per significato non la rende pertinente, e una decisione valida ieri può essere stata superata.

Un archivio di conversazioni è memoria. Conserva ciò che è stato detto. Anche un repository è memoria: conserva gli artefatti che il lavoro ha prodotto.

La memoria è necessaria, ma non basta. Si può conservare tutto e non sapere che cosa conta, o ritrovare due decisioni incompatibili senza sapere quale delle due sia ancora in vigore.

In questo libro, cognizione persistente indica una pretesa più precisa: conservare decisioni, criteri, lezioni, dubbi e collegamenti in modo che il sistema possa recuperare che cosa vale, perché vale, da dove arriva, che cosa ha superato e quando deve essere rimesso in discussione.

Questa pretesa non significa attribuire una mente al repository. «Cognizione» è il nome dell’ipotesi operativa che il libro mette alla prova: una parte del sapere maturato nella collaborazione può essere distillata in schede — i documenti in cui una decisione viene scritta insieme alle sue ragioni — collegate con sufficiente precisione da tornare pertinenti e utilizzabili in una sessione futura?

La differenza è nel verbo. La memoria conserva. La cognizione persistente deve anche permettere di orientarsi.

I collegamenti cambiano la natura dell’archivio. Una scheda isolata ricorda una conclusione. Una scheda collegata può dire quale fonte l’ha informata, quale iterazione l’ha prodotta, quale scelta precedente estende, quale vincolo la rende corrente e quale decisione successiva l’ha superata. Il valore aggiunto non è avere più testo: è poter ricostruire, a partire dal risultato, la strada che lo ha giustificato.

Torna alla sessione dell’inizio. Il vincolo che avevi fatto notare all’agente, l’alternativa scartata, la ragione per cui una soluzione plausibile non andava bene: separati restano appunti. Collegati sono il percorso che ha portato fin lì, e un’altra sessione può ripercorrerlo.

Il termine harness circola già. Trivedy chiama agent harness l’insieme di codice, configurazione e logica di esecuzione che circonda il modello, ne gestisce lo stato, esegue gli strumenti e applica vincoli;² la documentazione di Claude Code descrive la stessa separazione dall’altro lato, dove i modelli ragionano, gli strumenti agiscono e l’harness fornisce contesto ed esecuzione.³

Il System Harness di questo libro riprende il termine con un perimetro diverso, e le due funzioni annunciate nel Patto con il lettore ricevono qui il loro nome. Delimitare le mosse dell’agente significa governare il mandato, il contratto con cui il Senior circoscrive ciò che l’agente può fare: la prima parte formula quel contratto per intero. Conservare le decisioni insieme alle loro ragioni significa sostenere la persistenza degli esiti del giudizio, e la cognizione persistente è una delle proprietà richieste al sistema. Come il System Harness faccia l’una e l’altra cosa è materia della seconda parte.

La prima parte comincia dalla frattura che sposta il baricentro del mestiere dello sviluppatore dalla produzione di codice alla decisione su che cosa costruire e a quali condizioni. Da lì scompone il lavoro del Senior nelle condizioni che lo rendono possibile, una per capitolo, e alla fine lo ricompone nella figura del Senior amplificato.

Il libro però non parte da ciò che l’agente sa fare in una risposta: parte da ciò che il Senior e l’agente riescono a non perdere tra una risposta e la successiva.

Con quale disegno ho provato a non perdere le decisioni e le loro ragioni è il capitolo che segue.