Context engineering

 

Negli ultimi mesi, chi lavora con i modelli linguistici ha iniziato a notare uno spostamento sottile ma significativo: il problema non è più cosa scrivere nel prompt, ma cosa mettere nel contesto. È la differenza tra dare un'istruzione ben formulata e costruire l'intero ambiente informativo in cui un modello deve operare — memoria, strumenti, cronologia, vincoli, stato del sistema. Si parla ormai apertamente di context engineering come disciplina distinta dal prompt engineering, e la distinzione non è solo terminologica.

🔹 1. Il prompt come istruzione, il contesto come ambiente

Un prompt ben scritto ottimizza una singola interazione. Il contesto, invece, è tutto ciò che il modello "vede" prima di rispondere: documenti recuperati, risultati di strumenti, conversazioni pregresse, regole di sistema, persino la cronologia di errori già commessi in quella sessione. Con l'adozione crescente di agenti che lavorano su compiti lunghi — scrivere codice, orchestrare pipeline, gestire flussi multi-step — il contesto smette di essere statico e diventa qualcosa da progettare e mantenere nel tempo, non da scrivere una volta sola.

🔹 2. Il problema reale: la finestra di contesto non è memoria infinita

Anche con finestre di contesto molto ampie, riempirle indiscriminatamente peggiora le prestazioni: informazioni irrilevanti competono per l'attenzione del modello con quelle rilevanti, e il rumore ha un costo cognitivo misurabile in accuratezza. Da qui nascono tecniche di compattazione (riassumere lo stato invece di accumularlo), retrieval mirato (recuperare solo ciò che serve al passo corrente) e context pruning (rimuovere attivamente ciò che non serve più). Chi costruisce sistemi agentici oggi passa più tempo a decidere cosa escludere dal contesto che cosa includere.

🔹 3. Un parallelo che aiuta: la gestione della memoria nei sistemi operativi

Per chi ha basi di sistemi operativi, l'analogia è naturale: un modello con contesto illimitato ma mal gestito assomiglia a un processo senza garbage collection — funziona, finché non degrada. Le tecniche di context engineering ricalcano problemi già noti: cosa tenere in "memoria attiva", cosa spostare in uno storage esterno recuperabile su richiesta (un vector database, in pratica una forma di swap), e quando è il momento di fare un "compattamento" dello stato per liberare spazio utile.

🔹 4. Cosa cambia per chi progetta questi sistemi

• Il debugging si sposta dal "perché il prompt non funziona" al "perché il contesto in quel turno conteneva l'informazione sbagliata, mancante o duplicata".
• La progettazione richiede di pensare esplicitamente a cicli di vita: cosa entra nel contesto, quando viene aggiornato, quando viene scartato.
• Gli strumenti (tool calling, retrieval, memoria persistente) diventano parte della superficie di progettazione tanto quanto il prompt stesso — non componenti accessori.

✅ Conclusione

Il prompt engineering non è diventato inutile: resta la sintassi con cui si comunica un'intenzione. Ma la disciplina che sta assorbendo l'attenzione dei team più maturi è un'altra — più vicina all'architettura dei sistemi che alla scrittura. Per chi lavora già con agenti o pipeline complesse, vale la pena iniziare a trattare il contesto come una risorsa da gestire con la stessa disciplina riservata, in passato, alla memoria o alla cache: finita, costosa, e va usata con criterio.