Il context engineering e la pratica che consiste nel gestire consapevolmente cio che un AI agent detiene in un dato momento nella sua context window, cosi resta preciso e veloce su un compito lungo invece di derivare lentamente nella confusione. Il context window e la memoria di lavoro del modello: il system prompt, le tue regole, i file che ha letto, i tool disponibili, la conversazione fin qui. E finito, e il fatto piu importante al suo riguardo e che la qualita cala man mano che si riempie, non dolcemente, ma con una falesia. Il context engineering e il modo in cui tieni le cose giuste nella window e quelle sbagliate fuori: via la compaction, il retrieval, l'ordine e il prompt caching per padroneggiare i costi. Questa guida spiega cosa riempie la window, perche una window piena nuoce, e le tecniche che mantengono affidabile il lavoro agentico. Tutto qui e aggiornato a giugno 2026 e accompagna la lezione Context Engineering del corso 2.
Cosa detiene davvero il context window
Il context window e tutto cio che il modello puo vedere quando genera la sua prossima risposta, misurato in token (pezzi di testo, circa quattro caratteri per token). Per un coding agent, si riempie di piu del tuo ultimo messaggio: il system prompt che definisce l'agente, le tue regole CLAUDE.md o AGENTS.md, le definizioni di ogni tool e server MCP connesso, ogni file che l'agente ha letto, ogni output di comando che ha visto, e tutta la conversazione fin qui. Tutto questo si contende lo stesso budget finito. Il modello mentale che conta: il contesto e una risorsa scarsa che spendi, e tutto cio che carichi (un server MCP chiacchierone, un file enorme, un lungo va e vieni) e budget che il compito reale non ha piu. Vedi il glossario sul context window per la definizione formale.
- Il system prompt e le tue regole CLAUDE.md / AGENTS.md, ricaricate a ogni turno.
- Le definizioni di tool e di server MCP, il che spiega perche connettere molti server e costoso.
- Ogni file letto e ogni output di comando, che si accumula in fretta durante un compito.
- Tutta la cronologia di conversazione; le sessioni lunghe portano tutto il loro passato.
Perche una window piena nuoce: la falesia di prestazioni
E tentante pensare che una context window piu grande voglia dire che non devi piu preoccuparti di nulla, ma e vero il contrario: la qualita del modello cala nettamente prima che la window sia tecnicamente piena, e cala bruscamente. Man mano che la window si riempie di file, cronologia e rumore, il modello ha piu da prendere in considerazione ed e piu suscettibile di perdere il filo, contraddire un'istruzione precedente o dimenticare un vincolo dall'inizio della conversazione. Questa e la "falesia di prestazioni", ed e per questo che una window da un milione di token non vuol dire che dovresti riversarci un milione di token. La lezione pratica e controintuitiva ma affidabile: un contesto piu piccolo e ben curato in genere supera uno piu grande e stipato. Il context engineering esiste precisamente per tenerti dal lato giusto di questa falesia.
- La qualita crolla prima che la window sia piena, e il crollo e una falesia, non una pendenza dolce.
- Una window stipata fa perdere al modello i fili, contraddirsi e lasciar cadere vincoli.
- Un grande contesto massimo e un tetto, non un obiettivo; non riempirlo perche puoi.
- Un piccolo contesto curato batte uno grande gonfiato, la regola centrale del context engineering.
Lost in the middle
Il "lost in the middle" e un comportamento ben documentato dei modelli linguistici: prendono in considerazione in modo piu affidabile l'informazione all'inizio e alla fine del loro contesto, e meno affidabilmente l'informazione sepolta nel mezzo. Un'istruzione cruciale o l'unico fatto pertinente, lasciato cadere nel mezzo di un lungo prompt o di una lunga conversazione, e cio che ha piu probabilita di essere ignorato. La conseguenza pratica plasma il modo in cui ordini il contesto. Metti le istruzioni piu importanti e il materiale piu pertinente dove il modello guarda: vicino all'inizio (le tue regole permanenti) e vicino alla fine (il compito immediato e il file chiave). Non supporre che il modello usi qualcosa solo perche e da qualche parte nella window. La posizione e una leva.
- I modelli prendono in considerazione meglio l'inizio e la fine del contesto, il mezzo peggio.
- Un'istruzione chiave sepolta nel mezzo del prompt ha piu probabilita di essere ignorata.
- Metti le regole permanenti vicino all'inizio e il compito immediato e il file chiave vicino alla fine.
- Essere nella window non vuol dire essere usato; la posizione determina l'attenzione.
Compaction, handover e reset
Quando una sessione dura a lungo, ti servono modi di sganciare peso senza perdere il filo. Tre tecniche fanno l'essenziale. La compaction riassume la conversazione fin qui in una forma compatta e continua, liberando la window; la trappola e che la compaction automatica lascia cadere silenziosamente dettagli che ti importavano, quindi pilotala dicendo all'agente cosa deve preservare prima della compaction. Un handover termina una sessione e ne comincia una fresca con un riassunto pulito e deliberato che scrivi tu, il che ti da un contesto molto piu nitido che lasciare una sessione dilagare per ore. Un reset butta un contesto confuso e riparte con un prompt ristretto, il che e spesso piu rapido che riportare sui binari un agente deragliato con l'argomentazione. Sapere quando ricorrere a quale e il cuore pratico della competenza.
- Compaction: riassumere e continuare per liberare la window; pilotala perche tenga cio che conta.
- Handover: terminare la sessione e ripartire da capo con un riassunto pulito che controlli.
- Reset: buttare un contesto confuso e ripartire con un prompt ristretto piuttosto che argomentare.
- I subagent aiutano anche: delega il lavoro rumoroso, cosi il suo output non atterra mai nella tua window principale.
Retrieval: far entrare solo cio che serve
La modalita di fallimento opposta della window stipata e che la buona informazione non arriva mai. Il retrieval e il modo in cui fai entrare esattamente il pezzo pertinente al bisogno, invece di precaricare tutto. Per un coding agent, e generalmente concreto e poco affascinante: lascia che l'agente cerchi nella codebase e legga solo i file che un compito tocca, invece di incollare tutto il repo; mostragli l'unica pagina di documentazione di cui ha bisogno; lascialo grep la funzione invece di caricare la directory. Il principio dietro i pattern retrieval-augmented e lo stesso, che sia un database vettoriale o un agente che esegue grep: recupera esattamente cio di cui il compito ha bisogno, quando ne ha bisogno, cosi la window mantiene segnale piuttosto che un mucchio pieno di speranza di materiale forse pertinente.
- Recupera il file, la documentazione o il record specifico di cui il compito ha bisogno, non tutto cio che e potenzialmente pertinente.
- Lascia che un coding agent cerchi e legga al bisogno, invece di precaricare tutto il repo.
- Il retrieval mantiene la window piena di segnale, il che mantiene il modello dal lato giusto della falesia.
- La stessa idea scala fino alla ricerca vettoriale; l'obiettivo resta pertinente-al-bisogno, non tutto-per-sicurezza.
Prompt caching: padroneggiare il costo di un grande contesto
Un grande contesto stabile e costoso, perche il modello ritratta ognuno dei suoi token a ogni richiesta, e paghi quei token di input ogni volta. Il prompt caching risolve il lato costo: marchi un prefisso stabile (il tuo system prompt, le tue regole, le tue definizioni di tool, un grande documento di riferimento) come cachabile, e le richieste successive che cominciano con gli stessi identici byte lo leggono dalla cache invece di ricalcolarlo. Sull'API Claude, il risparmio a giugno 2026 e chiaro: una scrittura di cache costa circa 1,25 volte un token di input normale per la durata standard di cinque minuti (o 2 volte per l'opzione di un'ora), e una lettura di cache costa solo circa 0,1 volte, un decimo del prezzo. Un prefisso in cache si ammortizza quindi in poche riutilizzazioni. La cache e una cache di prefisso, quindi l'ordine conta: metti il tuo contenuto stabile per primo e il tuo contenuto mutevole per ultimo, e un solo token modificato prima del breakpoint forza una riscrittura completa. Il caching non riduce la quantita di contesto che il modello prende in considerazione, solo cio che paghi per inviarlo, quindi completa la curation piuttosto che sostituirla.
- Il caching riusa lo stato codificato di un prefisso stabile, cosi non viene ricalcolato a ogni richiesta.
- Sull'API Claude (giugno 2026): scritture di cache circa 1,25x l'input (standard 5 minuti, 2x per 1 ora), letture di cache circa 0,1x.
- E una cache di prefisso: tieni il contenuto stabile per primo e quello mutevole per ultimo, altrimenti forzi una riscrittura.
- Il caching abbassa i costi, non l'attenzione; continui a curare la window. Vedi il glossario sul prompt caching.
Una checklist pratica di context engineering
Assembla le idee in abitudini che esegui senza pensarci. Niente di tutto questo richiede strumenti speciali; e disciplina su cosa carichi e quando pulisci. Un compagno in arrivo e lo strumento di stima di token e contesto di questo campus, con cui incollerai testo e vedrai quanto riempie una window di modello prima di inviarlo; per ora, le regole qui sotto ti portano.
- Tieni le regole permanenti in CLAUDE.md o AGENTS.md, e tieni quel file corto; si carica a ogni turno.
- Carica i file di cui il compito ha bisogno, non tutto il repo; lascia che l'agente recuperi al bisogno.
- Metti l'istruzione piu importante vicino all'inizio e il compito immediato vicino alla fine.
- Fai compaction, un handover o un reset quando una sessione diventa lunga o confusa; non lasciarla dilagare.
- Metti in cache i grandi prefissi stabili per padroneggiare i costi, con il contenuto stabile per primo.
- Delega il lavoro accessorio rumoroso a un subagent, cosi il suo output resta fuori dalla tua window principale.