Siamo solo a marzo 2026 e anche quest’anno, in questi pochi mesi, il campo dell’AI ha cambiato pelle più volte: nuovi framework, nuovi modelli, nuovi concetti. Eppure il prompt engineering è ancora lì, rilevante come quando GPT-3.5 è uscito nel 2022 e ha introdotto al mondo i Large Language Models.
Con l’evoluzione dei modelli, sono evoluti anche gli strumenti per controllarli. Non si trattava più solo di fare domande a ChatGPT: accedendo al modello “grezzo”, si poteva configurarne il comportamento attraverso il system prompt. È lì che vive il prompt engineering, nella configurazione permanente del modello, strutturata in sezioni classiche:
- Ruolo: chi è il modello, il tono che usa, le competenze che ha;
- Obiettivo: il compito che l’agente deve svolgere;
- Chain-of-Thought (per i modelli non-reasoning): i passi per raggiungere quell’obiettivo;
- Few-shots: esempi opzionali su come comportarsi in determinati scenari;
- Formato di Output: come strutturare la risposta.
Funziona, finché non funziona più. Quando costruisci un progetto AI reale basandoti solo sul prompt engineering, le crepe cominciano ad apparire. Una delle più documentate è la perdita di attenzione su alcune sezioni del system prompt, studiata come il problema del “lost in the middle“. Un’altra è la tendenza del modello a dimenticare informazioni già fornite nelle conversazioni precedenti. Le context window, infatti, sono finite, e riempire il prompt con tutto quello che potrebbe servire non è una strategia: è una scommessa.
Context Engineering: i token giusti al momento giusto
C’è chi la chiama l’evoluzione del prompt engineering. C’è chi dice che è un insieme di building block di cui il prompt engineering è solo uno. L’obiettivo, però, è lo stesso: fornire i token giusti nella context window del modello esattamente quando servono.
Detto così sembra semplice. Nella pratica, coinvolge le tecnologie più complesse e recenti disponibili oggi per i sistemi AI. Quattro sono i building block principali su cui si costruisce un sistema di context engineering solido: il RAG, per recuperare informazioni rilevanti da grandi volumi di dati; la gestione della memoria, per mantenere lo stato tra interazioni diverse; i tool, per estendere le capacità dell’agente verso il mondo esterno; e le skill, per iniettare istruzioni specifiche solo quando servono. Ognuno risponde a un problema preciso, e insieme definiscono cosa significa davvero controllare il contesto di un modello.
RAG: come interrogare grandi quantità documentali
Immagina che il modello non abbia nessuna conoscenza pregressa dei manuali tecnici di un’azienda o di tutti i contratti o dei diversi bandi di concorso di una certa amministrazione. Se vuoi sapere, ad esempio, come effettuare la procedura di reset di un certo dispositivo o quali requisiti sono richiesti in un bando di concorso o se una clausola è presente in un certo contratto, l’approccio “tradizionale” ti costringerebbe a fornire centinaia di pagine di manuali, documentazione tecnica o documenti legali, rischiando di saturare la context window ancora prima di arrivare alla domanda.
C’è un modo migliore. Prima cerchi nei documenti i passaggi rilevanti che parlano di reset, dei requisiti di un concorso o della clausola specifica, e poi fornisci solo quelli come contesto al modello.
È questo il concetto alla base della Retrieval-Augmented Generation (RAG), introdotta da Meta Research nel 2020. Trasformando qualsiasi mole documentale in piccoli chunk di testo e vettorizzandoli, puoi recuperare esattamente la sezione che contiene l’informazione necessaria e inserirla nel prompt, senza dover caricare l’intero archivio documentale.
Il RAG è la tua interfaccia verso grandi volumi di informazione. Invece di caricare tutto in anticipo sperando per il meglio, recuperi solo ciò che è rilevante per l’interazione corrente. Precisione, non volume.
Memory Management: un cervello senza memoria
I modelli linguistici (LLM) sono stateless per default. Questo significa che ogni chiamata API riparte da zero, e la continuità della conversazione diventa un problema di architettura, non del modello. Se hai bisogno che un agente AI gestisca un compito in più passi, come prenotare un volo e poi un hotel, il sistema deve mantenere lo stato di queste interazioni correlate nel tempo.
La memoria di una conversazione può essere organizzata in modi diversi, alcuni dei quali si ispirano direttamente a concetti della psicologia cognitiva:
Memoria a breve termine
- Working Memory (Prompt + Conversation History): insieme al system prompt, vengono inviati al modello gli ultimi 10-20 messaggi scambiati tra l’agente AI e l’utente. È il contesto immediato della conversazione.
Memoria a lungo termine
La memoria a lungo termine riguarda tutto ciò che deve persistere oltre la conversazione attiva:
- Memoria semantica: responsabile dei fatti persistenti sull’utente, può essere implementata tramite knowledge graph o ricerca RAG su informazioni rilevanti. Un esempio pratico è iniettare nel prompt un oggetto JSON con i dati del profilo utente, come età, nome e indirizzo, al momento dell’inferenza.
- Memoria episodica: riguarda gli eventi e le interazioni passate tra utente e assistente. Si può implementare tramite few-shot learning nel prompt: al modello viene mostrato un esempio concreto, “utente chiede di aprire un ticket → chiama il tool “
registrazione_ticket“, così impara il comportamento senza doverlo dedurre da zero
Tools: dalla risposta giusta all’azione giusta
Immagina un agente di lead generation per Userbot. L’utente arriva in chat e chiede cosa fa il prodotto. L’agente recupera la risposta dalla knowledge base aziendale tramite il tool userbot_knowledge_base (RAG), trovando il contesto più rilevante tra documentazione, casi d’uso e schede prodotto. Fino a qui, conoscenza pura.
Quando l’utente scrive “vorrei una demo”. In quella frase, l’agente riconosce immediatamente l’intenzione commerciale e cambia modalità: non risponde e basta, inizia a raccogliere i dati necessari, nome, azienda ed email. L’agente sa già cosa fare perché il system prompt, attraverso la memoria episodica, ha già collegato quell’intenzione a quell’azione precisa. Raccolti i dati, scatta la chiamata al tool create_lead e il contatto viene registrato. Per l’utente è stata una chat. Per il sistema, un processo completato.
È questa la differenza che i tool introducono: non più un agente che sa le cose, ma un agente che può farle. Invece di affidarsi solo alla conoscenza acquisita durante il training, un agente con tool può interrogare database esterni, effettuare ricerche in tempo reale, eseguire codice, chiamare API o interagire con servizi terzi.
I tool vengono definiti accanto alla chiamata al modello come schemi strutturati, con nome e descrizione di ciascuno. Da lì, il modello decide autonomamente quando invocarli in base alla richiesta dell’utente.
Skills: il manuale di istruzioni
Introdotte da Anthropic, le skill aggiungono un ulteriore livello di contesto, pensato specificamente per gli agenti che ragionano. La differenza fondamentale rispetto a un system prompt statico è che l’agente accede a una skill solo quando serve, in risposta a una richiesta specifica dell’utente o quando emergono dettagli rilevanti solo in certi scenari o procedure complesse.
Invece di caricare tutte le istruzioni possibili nella context window fin dall’inizio, degradando l’attenzione e aumentando i costi, le skill permettono all’agente di recuperare dinamicamente un blocco focalizzato di istruzioni nel momento giusto. È la differenza tra un esperto che consulta il manuale solo quando si trova davanti a un caso non-routinario e uno che cerca di memorizzare l’intero manuale prima di ogni conversazione.
Il contesto è tutto
Il prompt engineering ha aperto la porta, ma il context engineering definisce cosa succede dopo averla varcata.
RAG, memoria, tool e skill non sono ottimizzazioni marginali: sono la differenza tra un agente che risponde e uno che agisce, tra un sistema che funziona in demo e uno che regge in produzione. Ognuno di questi building block risolve una parte del problema. Insieme, definiscono una disciplina.
Non si tratta di dare al modello più informazioni. Si tratta di dargli quelle giuste, nel momento giusto, nella forma giusta. È lì che si vede la differenza tra un sistema che impressiona in demo e uno che regge in produzione.
