Context engineering: perché un buon prompt non basta per lavorare con l’AI

Immaginate di affidare un lavoro a un nuovo collaboratore. Gli spiegate benissimo che cosa deve fare, poi gli consegnate tre preventivi superati, una presentazione del 2022, un verbale senza data e una cartella chiamata “Definitivo_vero_ultimo”. Quando sbaglia, gli rimproverate di non aver capito la richiesta.

Con l’intelligenza artificiale rischiamo di fare qualcosa di simile. Dedichiamo molta attenzione alla frase da scrivere nella chat e meno ai materiali che dovrebbero permettere di svolgere il compito. Un’istruzione impeccabile, però, non risolve una contraddizione tra due documenti dei quali abbiamo dimenticato di indicare la validità.

Questa riflessione prende spunto dall’articolo Effective context engineering for AI agents, pubblicato da Anthropic il 29 settembre 2025. Il tema è la progettazione del contesto disponibile agli agenti AI: istruzioni, informazioni e risultati delle azioni, selezionati e aggiornati durante il lavoro.

Che cos’è il context engineering

Il context engineering riguarda la gestione delle informazioni che un modello riceve mentre svolge un compito. Il prompt engineering si concentra sulla formulazione delle istruzioni; il context engineering considera anche documenti, cronologia e strumenti. Anthropic lo presenta come un’evoluzione del prompting, particolarmente rilevante per gli agenti che eseguono più passaggi.

La mia lettura pratica è questa: quando delego all’AI, devo preparare un incarico completo. Che cosa deve produrre? Quali dati deve utilizzare? Quale documento prevale? Quali informazioni mancano? Come controllerò il risultato?

È una prospettiva che si collega al mio metodo G.O.L., Guidare, Obiettivo, Limiti. A quelle istruzioni affiancherei una verifica dei materiali: abbiamo fornito all’assistente ciò che gli serve per rispettarle?

Una finestra di contesto grande non garantisce una lettura perfetta

Il lavoro Lost in the Middle: How Language Models Use Long Contexts, di Nelson F. Liu e colleghi, ha mostrato che, nei modelli e nei compiti studiati, la posizione delle informazioni influenzava le prestazioni. Le risposte erano spesso migliori quando il dato utile si trovava all’inizio o alla fine dell’input, peggiori quando era nel mezzo.

Un altro studio, RULER: What’s the Real Context Size of Your Long-Context Language Models?, di Cheng-Ping Hsieh e colleghi, ha valutato capacità che vanno oltre il recupero di un singolo dettaglio. Nei modelli analizzati, l’allungamento del contesto poteva accompagnarsi a cali importanti delle prestazioni.

Si tratta di ricerche del 2023 e del 2024: non sono una pagella dei chatbot disponibili oggi. Suggeriscono però una precauzione sensata: verificare come il modello usa i materiali sul nostro compito, anziché dedurlo soltanto dalla quantità di testo che può accettare.

Questo non significa che dobbiamo accorciare tutto. Se chiediamo un confronto completo tra due contratti, eliminare le clausole più scomode per “fare pulizia” sarebbe un disastro. L’obiettivo che propongo è rendere riconoscibili le informazioni necessarie, conservando l’accesso agli originali.

Un esempio: preparare un corso aziendale senza confondere i documenti

Supponiamo di dover progettare un corso di tre ore sull’AI per un gruppo commerciale. Abbiamo una mail del cliente, gli appunti della call, un questionario e programmi di corsi precedenti.

La richiesta “Agisci come un formatore esperto e prepara un corso coinvolgente” lascia aperte troppe decisioni. Un programma precedente potrebbe prevedere una giornata intera, un pubblico diverso o strumenti che il nuovo cliente non usa.

Io preparerei il lavoro in questo modo:

Materiale	Funzione nel nuovo incarico
Brief confermato dal cliente	Stabilisce pubblico, durata, obiettivi e vincoli concordati.
Questionario dei partecipanti	Descrive competenze iniziali e bisogni, senza modificare gli accordi commerciali.
Programma precedente	Offre esempi riutilizzabili; durata e condizioni appartengono al vecchio incarico.
Appunti della call	Segnalano ipotesi e punti ancora da confermare.

La distinzione decisiva è tra un dato approvato e un’idea ancora in discussione. Se nella call qualcuno ha proposto cinque ore, ma il brief finale ne conferma tre, voglio che l’assistente segnali il conflitto e segua il brief. Non che faccia una media creativa di quattro ore.

Questo schema è una mia applicazione operativa del tema, da adattare al proprio lavoro: proposte commerciali, piani editoriali, report, procedure interne.

Archivio, recupero delle informazioni e contesto sono cose diverse

Un archivio può contenere tutto lo storico di un’organizzazione. Per preparare una proposta specifica, invece, vorrei recuperare i documenti pertinenti e capire quale versione usare.

Il paper Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, di Patrick Lewis e colleghi, descrive un approccio che combina un modello generativo con il recupero di informazioni da una memoria esterna. È il riferimento originario della RAG, Retrieval-Augmented Generation.

In questa prospettiva, la RAG può contribuire a costruire il contesto, ma non esaurisce il problema: dopo aver trovato un documento, bisogna ancora decidere come utilizzarlo. Nel nostro esempio, recuperare il vecchio programma è utile per gli esercizi; copiarne le condizioni commerciali sarebbe un errore.

Per questo, nel mio archivio di lavoro, darei ai materiali una scheda essenziale: titolo, data, stato, progetto di appartenenza e funzione. Un nome come “Programma approvato, cliente X, ottobre 2026” offre un’indicazione molto più comprensibile di “File nuovo 7”.

Per gli agenti conta anche come funzionano gli strumenti

Quando l’assistente può cercare file o interrogare altri servizi, il contesto dipende anche dalle informazioni restituite da quegli strumenti. Nell’articolo Writing effective tools for AI agents, using AI agents, Anthropic raccomanda strumenti con scopi chiari e risposte pertinenti. Segnala inoltre che funzioni sovrapposte possono complicare le scelte dell’agente.

Applicato al nostro corso, vorrei una ricerca che restituisse il programma richiesto, la data e il suo stato. Se la risposta presenta soltanto un titolo, come distinguo una bozza da una versione approvata?

Prima di aggiungere un nuovo collegamento all’assistente, mi chiederei quindi: quale passaggio del lavoro rende possibile? Quali informazioni restituisce? Come verificheremo che siano quelle corrette?

Come mantenere il filo nei lavori lunghi

Per attività prolungate, Anthropic descrive tre strategie: compattare la conversazione, conservare note strutturate fuori dalla finestra di contesto e distribuire compiti mirati a sottoagenti. Sono approcci da scegliere in base al lavoro, non passaggi obbligatori per ogni richiesta.

Per il progetto del corso, io inizierei da una scheda di avanzamento: requisiti confermati, decisioni prese, dubbi aperti, documenti usati e prossimo passo. Se la durata cambia, aggiorno quella scheda e indico quale decisione è stata superata.

La farei controllare anche al responsabile del progetto. Una sintesi sbagliata, conservata con grande efficienza, rimane sbagliata.

Un prompt da provare subito

Ecco una richiesta da usare dopo aver allegato i materiali del nostro esempio:

Aiutami a progettare un corso di tre ore sull’AI per il team commerciale.

Prima di scrivere il programma, prepara una tabella con: documento, data indicata, informazioni utili, ruolo della fonte e possibili contraddizioni. Se data o stato non sono presenti, segnala “non indicato”.

Il brief confermato dal cliente stabilisce i requisiti. Usa il questionario per adattare il livello; i programmi precedenti sono esempi, senza valore per durata o condizioni del nuovo incarico. Gli appunti della call possono contenere proposte non approvate.

Non inventare informazioni mancanti. Fammi le domande necessarie a risolvere i dubbi che impediscono di costruire il programma.

Dopo il chiarimento, proponi una scaletta di 180 minuti, con obiettivo e attività per ogni modulo. Indica a quali materiali si collegano le scelte e distingui le tue proposte dai requisiti del cliente.

Questo prompt rende esplicite le regole del nostro incarico. Il suo valore va verificato sul risultato: riconosce le incongruenze? Rispetta il tempo disponibile? Inventa requisiti?

Un esercizio: stesso prompt, materiali organizzati diversamente

Per un laboratorio, proporrei di preparare due insiemi di documenti con le stesse informazioni. Nel primo lasciamo titoli vaghi e versioni indistinte. Nel secondo aggiungiamo date, stato e funzione delle fonti. Usiamo la stessa richiesta in conversazioni separate, con lo stesso modello e le stesse impostazioni disponibili.

Prima di partire, definiamo i criteri: requisiti rispettati, contraddizioni individuate, dati inventati e correzioni necessarie. Ripetiamo il confronto, perché una singola risposta riuscita non dimostra un vantaggio stabile. È un test pratico locale, non una prova scientifica generale.

Per accompagnare la riflessione sul prompting, qui trovi il mio intervento Tutti dobbiamo imparare a usare i prompt.

Prima di correggere il prompt, controlliamo il briefing

La competenza che mi interessa portare in azienda comprende anche questo: riconoscere le fonti, chiarire gli accordi e accorgersi di ciò che manca. Il context engineering offre un modo utile per ragionare su queste responsabilità quando lavoriamo con l’AI.

Alla prossima risposta insoddisfacente, suggerisco una verifica concreta: l’assistente aveva accesso al documento giusto? Sapeva che era quello approvato? Gli avevamo spiegato come trattare gli altri?

Magari il prompt va riscritto. Magari, prima, va sistemata la cartella “Definitivo_vero_ultimo”.

Vuoi sperimentare questo approccio con il tuo gruppo di lavoro? Scopri il mio corso di prompt engineering e contattami per costruire un laboratorio sui vostri casi reali.