Context Engineering: perché alle applicazioni AI non basta un buon prompt

La qualità di un sistema di intelligenza artificiale non dipende soltanto dal modello scelto. Conta ciò che il modello vede quando deve produrre una risposta o decidere l’azione successiva: istruzioni, documenti, dati, strumenti, memoria, stato del processo e risultati delle operazioni già compiute. Progettare e governare questo insieme dinamico di informazioni è il compito del Context Engineering.

Per alcuni anni buona parte dell’attenzione si è concentrata sul Prompt Engineering. Era una conseguenza naturale del modo in cui venivano utilizzati i primi modelli generativi: una persona formulava una richiesta, il modello riceveva un testo e produceva una risposta. Migliorare l'istruzione, aggiungere esempi e precisare il formato dell’output potevano modificare sensibilmente il risultato.

Le applicazioni AI attuali hanno però superato questo schema. Interrogano archivi aziendali, richiamano API, usano strumenti, conservano memoria e svolgono attività articolate in più passaggi. Un agente può iniziare il lavoro con una richiesta dell’utente, consultare una base documentale, eseguire una query, analizzare il risultato, aggiornare un piano e scegliere un altro strumento. Prima di ciascuna inferenza bisogna decidere quali elementi rendere disponibili al modello e quali lasciare fuori.

Dalla formulazione delle istruzioni alla costruzione del contesto

L’espressione Context Engineering si è diffusa rapidamente nel giugno 2025. In un post su X, Tobi Lütke, CEO di Shopify, la propose come definizione più appropriata della capacità di fornire a un LLM tutto ciò che rende plausibilmente risolvibile un compito. Successivamente Andrej Karpathy, ricercatore e divulgatore membro del gruppo fondatore di OpenAI e già direttore dell’AI di Tesla, rilanciò l’espressione, descrivendola come il lavoro necessario per riempire la finestra di contesto con le informazioni giuste per il passaggio successivo.

Nel 2026, Karpathy lavora nuovamente nella ricerca di frontiera, questa volta in Anthropic. La sequenza è stata ricostruita all'epoca da Simon Willison, che osservò come la nuova espressione potesse descrivere meglio la complessità delle applicazioni LLM rispetto all'immagine, ormai riduttiva, di qualcuno che perfeziona una domanda in una chat.

Il fenomeno non nasce naturalmente con il nome. Retrieval-Augmented Generation, function calling, memoria, cronologia delle conversazioni e system prompt esistevano già. Il nuovo termine segnala invece che queste tecniche non possono più essere progettate separatamente. Concorrono tutte alla costruzione dello stato informativo sul quale il modello deve ragionare in un determinato momento.

Nel luglio 2025, LangChain, un ecosistema software usato per sviluppare applicazioni e agenti basati su LLM, ha organizzato le principali strategie in quattro famiglie: scrivere il contesto e conservarlo all’esterno della finestra del modello; selezionare quello pertinente; comprimerlo per trattenere soltanto ciò che serve; isolarlo, distribuendolo tra stati, ambienti o agenti differenti. Nel settembre dello stesso anno, Anthropic ne ha data una formulazione ancora più precisa: il Context Engineering è la selezione e il mantenimento dell’insieme ottimale di token disponibili al modello durante l’inferenza.

Che cosa vede realmente un modello

In un’applicazione enterprise, il contesto può essere composto da elementi di natura molto diversa:

• le istruzioni di sistema e quelle specifiche del compito;
• la richiesta dell'utente e la cronologia dell'interazione;
• esempi del comportamento o del formato atteso;
• documenti recuperati mediante ricerca semantica, lessicale o ibrida;
• record provenienti da database e applicazioni aziendali;
• metadati, tassonomie e relazioni di un knowledge graph;
• descrizioni degli strumenti e relativi parametri;
• risultati ottenuti dagli strumenti;
• stato del workflow e piano delle attività;
• memoria relativa all’utente, al processo o a precedenti esecuzioni;
• identità, autorizzazioni, policy e vincoli applicabili;
• risultati intermedi prodotti da altri agenti.

Ecco perché non tutti questi elementi devono essere caricati insieme. Una descrizione di centinaia di strumenti, per esempio, può occupare una parte considerevole della finestra e rendere più difficile la scelta dello strumento appropriato. Un risultato grezzo di una query può contenere decine di migliaia di token, quando al modello servono soltanto poche anomalie. Una lunga cronologia può conservare decisioni superate o informazioni successivamente corrette.

Il Context Engineering governa quindi l’intero ciclo: individuare le fonti, recuperare i contenuti, verificarne la pertinenza, trasformarli in una rappresentazione utilizzabile, stabilirne l’ordine, controllarne la provenienza e decidere quando sintetizzarli, sostituirli o rimuoverli. Questa attività si ripete a ogni fase dell’esecuzione. Il contesto di un agente non è un pacchetto preparato una volta per tutte, ma una working memory che cambia con il procedere del lavoro.

Il diagramma seguente illustra come le informazioni estratte dagli input siano elaborate e trasformate per alimentare il modello e guidarne le inferenze. Gli output vengono a loro volta utilizzati per aggiornare la memoria o alimentare nuove richieste.

Perché più contesto non significa necessariamente più qualità

La crescita delle finestre supportate dai modelli potrebbe far pensare che il problema sia destinato a risolversi caricando semplicemente molte informazioni. Le evidenze disponibili, però, invitano alla cautela.

Lo studio “Lost in the Middle”, pubblicato su Transactions of the Association for Computational Linguistics, mostra come le prestazioni possano degradare quando l'informazione rilevante si trova nel mezzo di un contesto lungo. I risultati migliori tendono a apparire quando l'informazione è all’inizio o alla fine. Studi successivi hanno evidenziato progressi nei modelli più recenti, ma anche la persistenza di bias legati alla posizione e alla distanza tra informazioni da combinare.

La capacità della finestra dichiara quanti token un modello può ricevere, ma non garantisce che possa utilizzarli tutti con la stessa precisione. All’aumentare del contesto crescono anche il costo dell’inferenza e, normalmente, la latenza. Si aggiungono problemi applicativi: dati irrilevanti possono distrarre il modello; istruzioni incompatibili possono entrare in conflitto; un errore prodotto in un passaggio può essere reinserito nel contesto e condizionare quelli successivi.

Soluzioni pratiche per il Context Engineering

In risposta a queste complessità, Anthropic suggerisce di cercare il più piccolo insieme di token ad alta rilevanza capace di produrre il comportamento desiderato. Microsoft Research affronta lo stesso problema collegando la potatura del contesto a tecniche di effetto sul modello.

L’approccio del Context Engineering non si limita quindi al semplice allungamento della finestra. Si