Context engineering: dare all'agente solo ciò che serve
Più contesto non significa risposte migliori. Nel 2026 il mestiere è gestire ciò che l'agente vede — non accumularlo.
Luciano Cipriano
7/2/20263 min read
Ciao a tutti,
Ben arrivati su WikiLuc.
Per un po' ho pensato, come molti, che la soluzione fosse "dai più contesto al modello": finestre più grandi, più documenti, più cronologia. Poi, mettendo in produzione agenti che lavorano su task lunghi, ho visto l'opposto succedere sotto i miei occhi — più riempivo il contesto, più le risposte peggioravano, rallentavano, costavano. La lezione del 2026 è controintuitiva: il mestiere non è dare di più all'agente, è dargli esattamente il necessario. Si chiama context engineering, ed è diventato una disciplina a sé.
Di cosa parliamo oggi:
Perché più contesto non equivale a risposte migliori
Le tecniche chiave: sliding window, summarization, offloading
La frontiera del layer unificato (contesto + retrieval + compressione)
Come gestire in pratica agenti che lavorano a lungo
Partiamo dal problema.
Più contesto non è meglio
Cosa intendiamo per context engineering
Il context engineering è la disciplina di decidere, a ogni passo, cosa entra nella finestra di contesto dell'agente e cosa no. Sembra banale, non lo è. Un modello con una finestra enorme non garantisce risultati migliori: oltre una certa soglia, l'informazione rilevante si annacqua in quella irrilevante, il modello "si perde nel mezzo", la latenza sale e il costo pure. Riempire il contesto è facile; curarlo è dove sta il valore.
È lo stesso principio per cui un buon brief a un collega non è quello che gli scarica addosso tutto ciò che sai, ma quello che gli dà i tre elementi che gli servono per decidere. La differenza tra i due, su un agente che gira migliaia di volte al giorno, si misura in accuratezza, secondi e fattura.
Più contesto dai a un agente, meglio ragiona — fino al punto in cui lo affoghi.
Le tecniche che funzionano
Nel 2026 tre tecniche si sono affermate per gli agenti long-running, e vale la pena nominarle con precisione.
La sliding window mantiene in contesto solo la finestra recente di interazione, lasciando scorrere via il resto.
La summarization gerarchica comprime ciò che è passato in riassunti a più livelli, così l'agente conserva il senso senza trascinarsi ogni dettaglio.
Il memory offloading sposta fuori dal contesto attivo ciò che non serve adesso, recuperandolo solo quando torna rilevante.
Sono tre risposte alla stessa tensione: la finestra è una risorsa scarsa e costosa, e va gestita come tale. Non è un caso che queste tecniche assomiglino a come gestiamo la memoria di un computer — cache, compressione, paging. Stiamo reinventando, per gli agenti, principi che l'informatica conosce da decenni.
La frontiera: un layer unico
Il punto verso cui si stanno muovendo i team che spediscono agenti affidabili è l'unificazione. Oggi contesto, retrieval (il recupero dei documenti giusti) e compressione sono spesso sistemi separati, gestiti con logiche diverse. La frontiera è un layer unico e indirizzabile che li combina: un'unica interfaccia che decide cosa l'agente vede in ogni momento, integrando ciò che ricorda, ciò che recupera e ciò che comprime. È la naturale evoluzione: quando una funzione diventa critica, smette di essere una somma di pezzi e diventa un sottosistema coerente.
Le domande operative da farsi
Sto dando al mio agente tutto il contesto che posso, o solo quello che gli serve per il passo che sta compiendo?
Per i task lunghi, ho una strategia esplicita — sliding window, summarization, offloading — o lascio crescere il contesto finché non si rompe?
Gestisco contesto, retrieval e compressione come sistemi separati, o sto convergendo verso un layer unico?
Sono le domande che oggi separano un prototipo da un agente che regge in produzione, e che presto saranno la base del mestiere. La direzione è chiara: man mano che gli agenti affrontano task sempre più lunghi e autonomi, saper curare il contesto diventerà importante quanto scegliere il modello. Chi inizia ora a trattare il contesto come una risorsa da ingegnerizzare, e non da riempire, arriverà preparato a un mondo in cui gli agenti lavoreranno per ore senza perdersi.
Notizie da tenere d'occhio
Sliding window, summarization, offloading
Le tecniche di gestione del contesto diventano standard per gli agenti long-running.
Perché importa: sono ciò che permette a un agente di lavorare a lungo senza degradare.Verso un layer unico contesto+retrieval+compressione
La frontiera è unificare ciò che oggi sono sistemi separati.
Perché importa: semplifica l'architettura e rende la gestione del contesto governabile.Il "lost in the middle" è un problema reale
Finestre enormi non garantiscono che il modello usi bene l'informazione.
Perché importa: smonta l'idea che basti una context window più grande per risolvere tutto.
Una cosa da provare
🔧 Un audit del contesto di un tuo agente — Prendi un task reale e guarda cosa finisce davvero nella finestra a ogni passo. Quasi sempre scoprirai ridondanze e informazione morta che puoi tagliare. Misura accuratezza, latenza e costo prima e dopo: è il modo più concreto per capire perché il context engineering vale il tempo che richiede.
Il context engineering è la prova che, con gli agenti, la disciplina conta più della potenza bruta: non vince chi dà di più al modello, ma chi gli dà meglio. La cura con cui un team decide cosa l'agente vede a ogni passo è ciò che deciderà se i suoi agenti lavoreranno a lungo restando lucidi, o affogheranno nel rumore che noi stessi gli abbiamo versato addosso.
Grazie per aver letto questo articolo fammi sapere cosa ne pensi!
Ci vediamo presto qui su WikiLuc!