Context engineering: cos'è e come si applica agli agenti AI
Il context engineering decide cosa entra nella finestra di contesto di un modello. Sbagliarlo costa il 39% di accuratezza sui task multi-turno.
In questo pezzo
Il context engineering è la pratica di decidere quali informazioni stanno nella finestra di contesto di un modello a ogni chiamata: il system prompt, le definizioni dei tool, i documenti recuperati, la cronologia del compito in corso e tutto quello che l'agente ha scritto in memoria in una sessione precedente. Il prompt engineering lavora su come chiedi. Il context engineering lavora su cosa il modello sa nel momento in cui risponde.
Serve a chi ha agenti in produzione: lavoro a più passi, tool collegati, sessioni che durano ore e non secondi. Un classificatore a turno singolo non ne ha bisogno. Un agente che apre quaranta file, chiama sei tool e gira per novanta minuti ci si gioca tutto. Anthropic descrive l'obiettivo come trovare il gruppo più piccolo di token ad alto segnale che produce il risultato voluto.
La versione da trenta secondi
I modelli non leggono la finestra di contesto in modo uniforme. Se il dato che conta finisce in mezzo a centomila token di output dei tool, l'accuratezza del recupero cala. Se la sessione va avanti abbastanza a lungo, l'agente continua a rispondere alla versione del compito che aveva ipotizzato venti turni prima. Il context engineering è l'insieme delle mosse che tengono la finestra piccola, ordinata e aggiornata: recuperare al momento giusto, compattare quando si riempie, scrivere lo stato fuori dalla finestra, passare il lavoro separabile ad agenti che partono con una finestra pulita.
Perché il prompt engineering non basta più?
I prompt continuavano a migliorare e gli agenti continuavano a rompersi negli stessi punti. La ragione si misura. Ricercatori di Microsoft Research e Salesforce Research hanno simulato oltre duecentomila conversazioni su sei compiti di generazione: i modelli perdono in media il 39% delle prestazioni quando un'istruzione completa arriva a pezzi, distribuita su più turni, invece che tutta insieme (Laban e altri, 2025). La perdita viene dall'inaffidabilità, cresciuta del 112%, non dalla capacità, scesa del 15%. I modelli più grandi non hanno retto meglio: GPT-4.1, Claude 3.7 Sonnet e Gemini 2.5 Pro peggiorano tutti. La sintesi del comportamento nel paper è secca: quando un modello prende la strada sbagliata all'inizio, poi non torna indietro.
Il secondo risultato riguarda la lunghezza, non i turni. Chroma ha testato diciotto modelli su recupero e replica di testo, compiti quasi banali su input brevi, e ha visto l'affidabilità scendere man mano che l'input cresceva (Context Rot, 2025). Conta anche la posizione: quello che sta all'inizio e alla fine della finestra viene trattato meglio di quello che sta in mezzo. Il nome che è rimasto in giro è context rot, e il kit per replicare i test è pubblico.
Nessuno dei due problemi si risolve con il prompt. Riscrivere un'istruzione non ripara un passaggio di recupero che ha restituito il documento sbagliato, e nessuna formulazione recupera un agente che venti turni prima si è agganciato a un'ipotesi errata. La soluzione sta a monte, in cosa entra nella finestra e quando ne esce.
Cosa c'è davvero nella finestra di contesto di un agente
- System prompt. Ruolo, vincoli, formato di uscita, regole della casa. Di solito statico, di solito la cosa più economica da mettere in cache.
- Definizioni dei tool. Ogni schema collegato costa token a ogni chiamata, che l'agente usi quel tool oppure no. Venti tool sono una tassa che si paga di continuo.
- Dati recuperati. Documenti, righe di database, risposte API, contenuti di file. Il blocco più grosso e più volatile.
- Cronologia del compito. La trascrizione dei passi fatti, delle chiamate ai tool e degli output ricevuti. Cresce sempre, se non intervieni.
- Memoria. Quello che l'agente ha annotato in una sessione precedente e rilegge adesso.
Il prompt engineering tocca il primo punto. Il context engineering tocca tutti e cinque, più l'ordine in cui arrivano e il momento in cui ciascuno viene tolto.
Come si applica, in pratica
Recupero al momento giusto
Si caricano gli identificatori, non i contenuti. L'agente tiene percorsi di file, query salvate e link, e chiama un tool per tirare giù il contenuto quando gli serve davvero. Claude Code funziona così: il file CLAUDE.md entra all'inizio, glob e grep recuperano i sorgenti durante l'esecuzione. Il costo è un giro in più per ogni lettura, quindi latenza. Il guadagno è una finestra che resta piccola su un compito che tocca duecento file. Del file abbiamo parlato nella guida al CLAUDE.md.
Compattazione
Quando la finestra si avvicina al limite, si riassume la sessione e si riparte dal riassunto. La parte difficile è scegliere cosa tenere. L'indicazione di Anthropic è conservare le decisioni di architettura, i bug ancora aperti e i dettagli implementativi, e buttare gli output dei tool che l'agente ha già consumato. Se compatti troppo, perdi il vincolo che serviva al passo quaranta. Se compatti troppo tardi, l'agente sta già peggiorando da un'ora.
Appunti strutturati
Lo stato si scrive su file, fuori dalla finestra, e si rilegge. Una lista di cose da fare, un registro di quello che è emerso, una traccia delle decisioni. Così la finestra si può azzerare senza perdere il filo, perché il filo sta su disco. C'è un effetto collaterale che conviene: l'esecuzione diventa verificabile, e spiegare a un cliente perché l'agente ha fatto una certa cosa smette di essere un'ipotesi.
Sotto-agenti con finestra pulita
Si passa un compito stretto e separabile a un agente nuovo, che si brucia il proprio contesto e restituisce un riassunto. L'agente principale resta leggero. È l'architettura dietro quasi tutti gli agenti di ricerca in produzione. Costa più token in totale e aggiunge una superficie di coordinamento da debuggare, quindi va bene sul lavoro davvero indipendente, non come impostazione predefinita. I pattern che reggono la produzione stanno nel pezzo sui sistemi multi-agente.
Quanto costa e quanto fa risparmiare
Due numeri rendono concreta l'economia della cosa. Il team di Manus, piattaforma di agenti in produzione, riporta un rapporto medio fra token in ingresso e in uscita di circa 100 a 1: quasi tutta la fattura è contesto, non generazione. Riporta anche 0,30 dollari per milione di token in ingresso con cache contro 3,00 dollari senza cache su Claude Sonnet, dieci volte tanto (Manus, 2025). I listini cambiano, quindi conviene verificare le tariffe correnti prima di fare conti, ma la forma del divario è rimasta quella.
Il tasso di cache hit diventa così una metrica di prima fascia, non un'ottimizzazione da rimandare. E rende costose scelte piccole. Un timestamp in cima al system prompt invalida la cache da quel token in poi, a ogni chiamata, per tutta la vita dell'agente. Prefissi stabili, cronologia in sola aggiunta e serializzazione JSON deterministica sono abitudini che costano poco e si vedono in fattura. Gli stessi conti visti dal lato del billing stanno nel pezzo sul costo dei token, la meccanica della cache nell'articolo sulle API Anthropic in Next.js.
Quando non serve
La disciplina si ripaga quando le esecuzioni sono lunghe, i tool sono tanti, oppure lo stesso agente viene chiamato migliaia di volte al giorno. Sotto quella soglia bastano un prompt scritto bene e un passaggio di recupero, e le ore di sviluppo rendono di più altrove. Una chat di supporto con un tetto di dieci messaggi non ha bisogno di compattazione. Un classificatore non ha bisogno di un file di memoria.
Due limiti da dichiarare. Il context engineering non ripara un indice fatto male: se il vector store restituisce i tre documenti sbagliati, una gestione attenta della finestra consegna i tre documenti sbagliati in modo più efficiente. E non elimina la valutazione. Quasi tutte le mosse qui sopra sono compromessi con un parametro da tarare, e l'unico modo per sapere dove metterlo è misurare il successo dei compiti su esecuzioni lunghe, non sulla demo.
Disciplina vera o etichetta nuova?
Un po' e un po'. Il rapporto State of Context Management 2026 di DataHub riporta che l'82% dei responsabili IT e dati dice che il prompt engineering da solo non regge più l'AI su larga scala, e il 95% considera il context engineering importante per far girare agenti su larga scala (DataHub, 2026). I sondaggi di un fornitore su una categoria tendono a scoprire che quella categoria conta, quindi i numeri vanno presi con le pinze. Il movimento sotto è reale e si vede nella ricerca più che nel marketing: i punti di rottura si sono spostati da come formuli una richiesta a cosa il modello aveva in mano quando ha risposto. Il nome del ruolo è nuovo. Il lavoro è progettazione del recupero, cache e gestione dello stato, cioè quello che i backend fanno da vent'anni con altri nomi.
Concetti vicini
- La finestra di contesto come budget di token, la versione quotidiana della stessa disciplina dentro un agente di sviluppo.
- Le skill, dove la divulgazione progressiva tiene le capacità fuori dalla finestra finché non servono.
- I pattern multi-agente, per quando una sola finestra pulita non basta.
La lezione pratica è più piccola del rumore che ci gira intorno. Tratta la finestra di contesto come una risorsa scarsa, ordinata, costosa e con un responsabile; misura cosa la riempie; togli le cose a scadenza invece di aspettare che il modello cominci a sbagliare. Quasi tutti i problemi di affidabilità che vediamo sugli agenti in produzione sono problemi di approvvigionamento, e l'approvvigionamento si sistema.
Domande frequenti
Il context engineering è la stessa cosa del RAG?+
No. Il RAG è una tecnica dentro il context engineering. Il RAG risponde alla domanda su da dove arriva un documento. Il context engineering risponde a cosa entra nella finestra, in che ordine, in quale momento, e cosa esce quando la finestra si riempie. Un agente può fare un RAG impeccabile e sbagliare lo stesso, perché si porta dietro sessanta turni di output di tool ormai inutili accanto al documento recuperato. Nel sondaggio DataHub il 77% degli intervistati dice che il RAG da solo non basta per gli agenti su larga scala, e coincide con quello che raccontano i team quando le esecuzioni si allungano.
Se i modelli hanno finestre da un milione di token, perché non riempirle?+
Perché capienza e attenzione utile sono due cose diverse. Chroma ha testato diciotto modelli e ha visto l'affidabilità calare al crescere dell'input, anche su compiti di recupero che a lunghezze brevi sono banali. Quello che sta all'inizio e alla fine della finestra viene trattato meglio di quello che sta in mezzo. Una finestra grande dà margine per i momenti in cui serve, non il permesso di buttarci dentro tutto. I team che la usano come magazzino vedono i costi salire e l'accuratezza scendere insieme.
Come faccio a capire se il context engineering sta funzionando?+
Tre misure coprono quasi tutto. Il tasso di cache hit dice se il prefisso è stabile e la cronologia è in sola aggiunta, e si riflette sulla fattura. Il tasso di successo misurato su esecuzioni lunghe, non su singoli turni, dice se la compattazione sta buttando via qualcosa che serviva. Il conteggio di token per task completato, seguito nel tempo, intercetta il gonfiore lento che arriva quando definizioni di tool e istruzioni di sistema si accumulano. Se in un mese le tre misure si muovono nella direzione giusta, il lavoro sta funzionando.
Chi si occupa di context engineering in un team di prodotto?+
Nei team che vediamo finisce quasi sempre in mano al backend o al platform engineer che gestisce il runtime dell'agente, non a una figura dedicata. Il lavoro è progettazione del recupero, cache, serializzazione e gestione dello stato: ingegneria backend ordinaria applicata a un vincolo nuovo. Assumere uno specialista prima di avere un agente in produzione è prematuro. Serve invece, da subito, un responsabile scritto per il system prompt e per lo schema dei tool, perché entrambi vanno alla deriva in fretta quando tre persone li modificano senza una revisione.
Servizi correlati
Studio
Inizia un progetto.
Scriviamo riguardo a ciò che costruiamo. Raccontaci cosa vuoi costruire tu.