Il sesto capitolo risponde alla domanda che decide la fattibilità economica degli agenti: perché un ciclo agentico dovrebbe costare meno a ogni esecuzione? La risposta di Williams è che non lo fa, spontaneamente. Senza un meccanismo deliberato per catturare e istituzionalizzare le lezioni, gli agenti non offrono alcun vantaggio cumulativo — ripartono da zero conoscenza a ogni ciclo. La componente che cambia questo stato di cose è la fase P7, Distill.

Distill ha due metà. La prima è la semplificazione. Controintuitivamente, la revisione architetturale e la deduplicazione dovrebbero avvenire dopo il merge, non prima. Deduplicare prima che il codice esista è speculativo; deduplicare dopo prende di mira pattern effettivamente osservabili. I test, già presenti, garantiscono la conservazione del comportamento durante questa pulizia, il che consente a modelli meno capaci — e quindi più economici — di partecipare senza rischi.

La seconda metà è l'estrazione delle lezioni, organizzata come una "lesson foundry". Questa fonderia trasforma i riscontri ricorrenti in difese permanenti: i problemi deterministici diventano regole di lint abbinate a test; i pattern contestuali alimentano una pipeline di skill-mining; le lacune nelle specifiche innescano nuove domande nella fase di interrogazione. L'economia sottostante è decisiva: ogni lezione viene pagata una sola volta, poi retrocessa da rilevamento probabilistico costoso a prevenzione deterministica gratuita.

Williams identifica due nemici del guadagno composto. Primo, il degrado delle skill (skill rot): gli artefatti obsoleti forniscono disinformazione con autorevolezza; la contromisura è un controllo di verifica settimanale che estrae affermazioni verificabili (comandi, percorsi, versioni) e ne segnala l'attualità. Secondo, il ratchet del modello (model ratchet): dopo ogni release, riaudire il codice esistente con i modelli più avanzati per individuare ciò che le versioni precedenti avevano mancato — un meccanismo a cricchetto che non consente arretramenti.

Il capitolo culmina nell'unità di conto corretta. Piuttosto che tracciare i token per sviluppatore, i programmi di successo misurano il costo per modifica mergiata e verificata. Questa riformulazione trasforma il modo di leggere la spesa: i costi della fase di prosecuzione non sono spreco ma investimento. Quattro indicatori rivelano un ciclo compromesso: una spesa concentrata nella fase Build segnala skill mancanti; una prosecuzione sempre più costosa segnala lezioni mai reintegrate; ripetuti superamenti del limite di iterazioni segnalano specifiche deboli; e una traiettoria di costo piatta segnala un fallimento del sistema. La tesi si riassume in poche parole: "un costo piatto è un fallimento". Un sistema sano vede il proprio costo per modifica diminuire in modo misurabile man mano che le skill si accumulano e gli strati di lint si ispessiscono.