Che cos'è il context engineering? La competenza che separa le demo AI dall'AI che funziona è più facile da usare quando il concetto è collegato a una decisione reale, anziché trattato come l'ennesima parola d'ordine dell'AI. Questa guida di AI Tools Radar si concentra sull'idea operativa, sui compromessi che contano e sulle domande da porsi prima di adottare uno strumento o un flusso di lavoro.
Nel giugno 2025, Andrej Karpathy ha pubblicato una definizione che da allora è diventata il riferimento per una disciplina emergente: il context engineering è «la delicata arte e scienza di riempire la finestra di contesto con esattamente le informazioni giuste per il passaggio successivo».
Questa formulazione è stata importante perché ha dato un nome a qualcosa che i professionisti facevano già senza un'etichetta. Ogni applicazione AI seria, ogni agente in produzione, ogni flusso di lavoro che produce davvero risultati coerenti comporta decisioni deliberate sulle informazioni che il modello vede quando viene eseguito. L'insieme di queste decisioni è il context engineering.
Il prompt engineering, al contrario, è ciò a cui la maggior parte delle persone pensa quando immagina di «lavorare con l'AI». Scrivi istruzioni migliori, formuli le cose con chiarezza, aggiungi esempi. Il prompt engineering è reale e utile, ma affronta solo un livello del problema e spesso quello meno importante nei sistemi in produzione.
Il context engineering è la disciplina più ampia. Non riguarda solo ciò che chiedi al modello, ma tutto ciò che il modello sa quando risponde: le istruzioni con cui opera, gli strumenti che può chiamare, la cronologia della conversazione, i documenti recuperati per supportare il compito e la memoria di chi sei e di ciò su cui hai lavorato. Disporre correttamente questi elementi, nella combinazione giusta e al momento giusto, è ciò che determina se un'applicazione AI funziona o fallisce.
Context engineering e prompt engineering: qual è la differenza reale.
La distinzione non è accademica. Ha conseguenze pratiche per chiunque sviluppi con l'AI o cerchi di usarla in modo affidabile.
Il prompt engineering si concentra sulla query. Come formuli la domanda? Quali esempi includi? Come strutturi l'istruzione per ottenere il formato di output desiderato? Il prompt engineering presuppone una configurazione relativamente statica: un modello, un utente, una richiesta.
Il context engineering si concentra sull'ambiente. Che cosa sa il modello prima che l'utente digiti qualcosa? Quali informazioni vengono recuperate e inserite? Come viene gestita la cronologia della conversazione? Quali strumenti sono disponibili? Quali vincoli sono incorporati nel sistema? Il context engineering considera la finestra di contesto del modello come una superficie progettuale attiva, non come una pagina bianca.
L'analisi del context engineering di LangChain riassume la differenza così: il prompt engineering riguarda il porre la domanda giusta; il context engineering riguarda il creare l'ambiente ottimale affinché il modello individui ed esegua la soluzione corretta, spesso senza che l'utente debba nemmeno chiederla.
Nell'uso informale dell'AI, il prompt engineering è di solito sufficiente. Apri ChatGPT, chiedi qualcosa e perfezioni la formulazione se la risposta non è corretta. Va bene.
Nei sistemi AI in produzione, il prompt engineering è il minimo indispensabile. L'applicazione distribuita mediana nel 2026 include recupero, chiamate a strumenti, gestione della cronologia delle conversazioni, stato strutturato, instradamento condizionale e talvolta coordinamento tra più modelli. Ciascuno di questi è una decisione di contesto. La qualità di tali decisioni determina la qualità di ogni output prodotto dal sistema.
Una finestra di contesto non è soltanto il testo che digiti. In qualsiasi applicazione AI ben progettata, il contesto assemblato per una data chiamata al modello contiene in genere diversi livelli distinti:
Prompt di sistema Le istruzioni persistenti che definiscono ruolo, vincoli e comportamento del modello. Chi è il modello? Che cosa può fare? Che cosa non deve mai fare? Un prompt di sistema ben progettato non è un paragrafo di indicazioni vaghe: è un insieme accuratamente mantenuto di regole e ruoli che modellano ogni risposta.
Cronologia della conversazione La registrazione di quanto è stato detto fino a quel momento. Quanta cronologia conservare, come comprimerla quando diventa lunga e cosa riassumere rispetto a cosa preservare parola per parola sono decisioni di progettazione attive. Troppa cronologia spreca spazio di contesto; troppo poca fa perdere il filo di compiti complessi in più passaggi.
Documenti recuperati Informazioni recuperate da una fonte di conoscenza esterna e inserite nel contesto al momento dell'inferenza. Si tratta della generazione aumentata dal recupero (RAG), una delle primitive più importanti del context engineering. La qualità del recupero, la dimensione dei segmenti, la classificazione per pertinenza e l'ordinamento dei contenuti recuperati influenzano tutti la qualità dell'output.
Definizioni degli strumenti Le interfacce che permettono al modello di eseguire azioni: chiamare un'API, eseguire codice, cercare sul web, scrivere in un database. Il modo in cui gli strumenti sono descritti, i parametri che espongono e gli strumenti disponibili in un dato contesto sono decisioni di context engineering.
Memoria Informazioni persistenti sull'utente, sul progetto o sulle interazioni passate. La memoria a breve termine può essere costituita dagli ultimi scambi; quella a lungo termine può includere preferenze dell'utente, decisioni precedenti e conoscenza accumulata sul lavoro in corso. L'analisi del context engineering di Weaviate descrive la memoria come il livello che permette ai sistemi AI di diventare davvero personalizzati nel tempo, anziché ripartire da zero a ogni sessione.
Stato e dati strutturati Per i flussi di lavoro con agenti che attraversano più passaggi, fanno parte del contesto da gestire attentamente anche lo stato corrente del compito, gli output dei passaggi precedenti e qualsiasi dato strutturato di cui il modello abbia bisogno per ragionare.
L'arte del context engineering consiste nell'assemblare correttamente questi livelli per ogni chiamata specifica: scegliere cosa includere, cosa comprimere, cosa recuperare e cosa lasciare fuori, affinché il modello disponga esattamente di ciò che gli serve e di nulla che attenui il segnale.
Perché il context engineering è diventato la competenza critica.
Tre cambiamenti hanno reso il context engineering più importante del prompt engineering per gran parte del lavoro AI serio.
L'ascesa dell'AI agentica. Quando un modello viene eseguito una sola volta in risposta a un'unica domanda, il prompt engineering conta di più. Quando un modello opera in un ciclo, compie azioni, riceve risultati e decide cosa fare dopo, il contesto evolve a ogni passaggio. La qualità dell'agente dipende quasi interamente dal fatto che il contesto di ogni passaggio contenga le informazioni giuste per prendere la decisione giusta. L'analisi di Deepset identifica questo come il fattore centrale: man mano che i sistemi AI diventano più autonomi, la progettazione del contesto diventa la sfida ingegneristica dominante.
Finestre di contesto più lunghe, stesso problema di scarsità. I modelli ora supportano finestre di contesto da 1 milione di token. Sembra che questo risolva il problema, ma non è così. Una finestra da un milione di token piena di informazioni irrilevanti produce risultati peggiori di una finestra da 100.000 token contenente esattamente le informazioni giuste. Più capacità non elimina il bisogno di selezionare; alza la posta. Un context engineering disattento su larga scala significa più rumore, non meno.
Il divario tra demo e produzione. È facile creare una demo AI impressionante: curi manualmente il contesto, selezioni gli input più favorevoli e la esegui una volta. È difficile creare un sistema AI che funzioni con costanza per migliaia di utenti, su migliaia di input e stati diversi. La differenza riconduce quasi sempre al context engineering. La demo ha funzionato perché qualcuno ha fatto manualmente buone scelte di contesto; il sistema in produzione fallisce perché quelle scelte non sono mai state sistematizzate.
C'è un livello di context engineering che la maggior parte degli strumenti e dei framework ignora quasi completamente: il tuo contesto personale.
I prompt di sistema, le definizioni degli strumenti e i documenti recuperati sono tutti problemi ingegneristici che i team possono risolvere a livello di applicazione. Ma esiste una categoria di contesto specifica per te: la ricerca che svolgi da sei mesi, le riunioni avute con i clienti, le decisioni prese dal tuo team nell'ultimo trimestre, la conoscenza accumulata nella tua particolare situazione lavorativa. Nessuna applicazione AI viene fornita con questo contesto. Non può farlo: è tuo.
Ecco perché molti strumenti AI risultano frustranti per il lavoro della conoscenza serio. Il modello è capace, l'infrastruttura è solida, ma ogni sessione parte da zero e la distanza tra «ciò che il modello sa del mondo» e «ciò che il modello sa del tuo lavoro» è il divario che limita ogni output che ricevi.
Per la maggior parte delle persone, il passaggio dal prompt engineering al context engineering avviene in tre fasi.
Fase 1: progettazione deliberata del sistema. Smetti di trattare il prompt di sistema come un ripensamento. Definisci chiaramente che cos'è il modello, che cosa non è, cosa dovrebbe fare sempre e cosa non dovrebbe mai fare. Tratta il prompt di sistema come codice: versionalo, testa le modifiche, mantienilo.
Fase 3: gestione dello stato per compiti in più passaggi. Quando un compito si estende su più passaggi o più chiamate al modello, traccia esplicitamente lo stato. Che cosa è stato deciso? Che cosa è stato prodotto? Che cosa deve ancora accadere? Trasmetti quello stato in modo deliberato invece di sperare che il modello lo ricostruisca dalla sola cronologia della conversazione.
Il principio alla base di tutte e tre le fasi è lo stesso: la qualità dell'output del modello è funzione della qualità del suo contesto di input. Progettare quel contesto è il lavoro.
Il context engineering è solo per sviluppatori? No. Il termine viene dall'ingegneria del software, ma la pratica si applica a chiunque usi regolarmente strumenti AI. Decidere quali informazioni includere prima di porre una domanda a un assistente AI, costruire una cartella di documenti pertinenti da incollare in una sessione o usare una base di conoscenza per accumulare note di lavoro sono tutte forme di context engineering, anche senza scrivere una riga di codice.
Qual è la differenza tra RAG e context engineering? Il RAG (generazione aumentata dal recupero) è un componente del context engineering: la parte che recupera documenti pertinenti e li inserisce nel contesto. Il context engineering è la disciplina più ampia che include anche la progettazione del prompt di sistema, la gestione della memoria, la definizione degli strumenti, la gestione della cronologia delle conversazioni e il tracciamento dello stato nei flussi di lavoro in più passaggi.
Una finestra di contesto più grande rende il context engineering meno importante? No. Finestre di contesto più grandi offrono più capacità, ma non riducono l'importanza di ciò che vi inserisci. Un contesto dispersivo da 1 milione di token produce risultati peggiori di un contesto mirato da 100.000 token. La disciplina di selezionare, ordinare e comprimere le informazioni diventa più importante, non meno, man mano che la capacità cresce.
Qual è il rapporto tra context engineering e agenti AI? Il context engineering è fondamentale per la progettazione degli agenti. Un agente è affidabile solo quanto il contesto che riceve a ogni passaggio. La qualità del prompt di sistema, le definizioni degli strumenti, lo stato recuperato e la gestione della memoria determinano se un agente prende buone decisioni oppure divaga, allucina o entra in un ciclo. Le applicazioni agentiche sono il punto in cui le conseguenze di un context engineering carente risultano più evidenti.
Il context engineering non è una tendenza. È la disciplina che permette alle applicazioni AI di funzionare con il livello di qualità di cui gli utenti hanno davvero bisogno. Il passaggio dal «porre domande migliori» al «progettare ambienti informativi migliori» è il passaggio dall'usare l'AI al costruire con l'AI, e dal tollerare risultati incoerenti al pretendere risultati affidabili.
Il test pratico è verificare se questo approccio migliora una parte ripetibile del lavoro senza nasconderne fonti, costi o modalità di fallimento. Inizia con un'attività rappresentativa, mantieni un controllo umano nei punti in cui gli errori contano e rivaluta il risultato quando modelli e prodotti cambiano.
Uniamo fonti primarie, documentazione dei prodotti e scenari d'uso reali per aiutarti a capire se uno strumento è adatto al tuo flusso di lavoro.