Context Engineering: Cos'è e Come Lo Uso per Costruire Agenti IA Migliori

Indice

Pubblicato nel luglio 2026.

TL;DR: Il prompt engineering riguarda la scelta delle parole; il context engineering riguarda l’architettura delle informazioni. Hai una finestra di contesto finita e ogni token è un compromesso. Struttura il contesto dell’agente in quattro livelli: il prompt di sistema, la cronologia della conversazione, il contenuto recuperato e gli output degli strumenti. Trattare la finestra come un budget, non come una tela bianca, ha migliorato l’affidabilità più che cambiare modello.

[Nota dell’operatore] Gestisco più di 30 agenti in produzione. Il miglioramento che ha fatto la differenza maggiore nell’ultimo anno non è un modello migliore né un framework più sofisticato — è essere più deliberati su cosa entra nella finestra di contesto e cosa rimane fuori. Il context engineering è ora la competenza principale che cerco quando valuto il lavoro sugli agenti.

La maggior parte delle persone parla ancora del “prompt engineering” come della competenza critica per lavorare con l’IA. Il prompt engineering è reale e conta. Ma è un sottoinsieme di una disciplina più ampia — e trattarlo come il lavoro completo spiega perché molti agenti che sembrano buoni nelle demo crollano in produzione.

Perché il “prompt engineering” è diventato il quadro sbagliato

“Prompt engineering” implica che la leva chiave sia il testo che scrivi nel prompt di sistema o nel messaggio dell’utente. Dedica abbastanza tempo a elaborare le istruzioni giuste, la formulazione giusta, il formato giusto, e il modello farà quello di cui hai bisogno.

Questo è vero fino a un certo punto. Un prompt di sistema ben scritto è necessario. Ma il comportamento del modello è determinato da tutto ciò che si trova nella finestra di contesto — non solo dal tuo prompt di sistema. È influenzato da:

• La cronologia della conversazione (cosa è successo nei turni precedenti)
• I documenti o i dati che hai recuperato e iniettato
• I risultati delle chiamate agli strumenti che il modello ha visto finora
• Il conteggio dei token e la posizione di ogni pezzo di informazione

Se stai pensando solo alla formulazione del prompt e ignori il resto di ciò che riempie la finestra di contesto, stai ottimizzando un input lasciando gli altri non gestiti. Ecco perché “context engineering” è il quadro più preciso per il lavoro serio con gli agenti.

Cos’è realmente il context engineering

Il context engineering è la disciplina di decidere quali informazioni entrano nella finestra di contesto del modello, in quale ordine, in quale momento della conversazione.

La finestra di contesto è la memoria di lavoro del modello. È finita. Ogni token che ci metti dentro sposta qualcos’altro — o aumenta il costo. E a differenza della memoria di lavoro umana, il modello non ha modo di “cercare qualcosa” al di fuori di ciò che si trova nella finestra (a meno che non gli dia strumenti per farlo). Quello che vede è tutto ciò che ha.

Il context engineering è la pratica di trattare quella finestra come una risorsa da gestire deliberatamente:

• Cosa deve sapere il modello per completare questo passaggio?
• Cosa doveva sapere in un passaggio precedente ma non ha più bisogno di sapere?
• Cosa è stabile tra le esecuzioni vs. dinamico per richiesta?
• Dove nella finestra dovrebbe apparire ogni pezzo di informazione?

Queste non sono domande sulla formulazione del prompt. Sono domande di architettura dell’informazione. E le risposte guidano l’affidabilità dell’agente tanto quanto la selezione del modello.

I quattro livelli che progetto

Ogni agente che costruisco ha quattro livelli di contesto distinti. Penso a ciascuno di essi separatamente.

Livello 1: Il prompt di sistema

Questa è la base stabile e indipendente dal turno. Definisce chi è l’agente, cosa può fare, cosa non può fare e come dovrebbe gestire i casi limite.

L’errore che la maggior parte delle persone fa qui è scrivere il prompt di sistema una volta e considerarlo finito. In pratica, il prompt di sistema deve rispondere esplicitamente a tre domande:

1. A cosa serve questo agente? (Il modello ha bisogno di un ambito preciso, non di una missione vaga.)
2. Cosa dovrebbe fare quando l’input è ambiguo o incompleto?
3. Cosa non dovrebbe mai fare? (I vincoli negativi contano.)

Mantieni il prompt di sistema minimale. Ogni frase inutile è un overhead che compete con il contenuto dinamico dove avviene il ragionamento reale.

Un consiglio pratico: se stai usando Claude con l’API, usa cache_control sul tuo prompt di sistema. Un prompt di sistema grande e stabile in cache costa circa il 10% di quello che costerebbe uno non in cache per turno.

Livello 2: Cronologia della conversazione

In un agente multi-turno, la cronologia della conversazione è dinamica e cresce ad ogni turno. Senza gestione, diventa il principale driver dell’inflazione del contesto.

Il problema: i turni precedenti contengono informazioni di cui il modello non ha più bisogno. Tenerle tutte spreca token e può confondere il modello dandogli un contesto obsoleto da cui ragionare.

Cosa faccio:

• Troncare o riassumere i turni vecchi quando la cronologia supera una soglia.
• Conservare solo i risultati delle chiamate agli strumenti ancora rilevanti.
• Non lasciare mai che la cronologia cresca senza limiti in un agente a lunga durata.

Livello 3: Contenuto recuperato

Questo è il livello che separa gli agenti mediocri da quelli buoni. La maggior parte degli agenti ha bisogno di estrarre dati esterni in fase di esecuzione.

Due principi che applico:

Recuperare solo ciò che è rilevante per il passaggio corrente. Non iniettare un documento di 50 pagine quando il passaggio corrente ha bisogno solo di una sezione.

La posizione conta. Le informazioni all’inizio e alla fine del contesto vengono ponderate più pesantemente delle informazioni nel mezzo. Se c’è un pezzo di contenuto recuperato che il modello deve assolutamente usare, non seppellirlo nel mezzo di un’iniezione lunga.

Livello 4: Output degli strumenti

In un loop agentivo, il modello chiama strumenti e ottiene risultati. Questi risultati si accumulano. E a differenza della cronologia della conversazione, le persone raramente pensano a gestirli.

La soluzione è la stessa: dopo che il risultato di uno strumento ha servito il suo scopo, non hai bisogno di tenerlo nella finestra. In un agente multi-passaggio, porto avanti un riepilogo strutturato di “cosa abbiamo stabilito finora” piuttosto che l’output grezzo di ogni passaggio precedente.

Il budget di contesto: cosa includere e cosa tagliare

Uso un semplice modello mentale: la finestra di contesto è un budget e ogni token è una spesa. Prima di ogni turno dell’agente, mi chiedo:

• Cosa deve sapere il modello adesso per fare questo passaggio?
• Cosa posso tralasciare o riassumere senza perdere nulla di importante?
• Cosa è duplicato tra i livelli?

L’obiettivo è riempire la finestra con le informazioni al più alto segnale possibile ad ogni passaggio, non essere esaustivi.

Tre errori di context engineering che ho fatto in produzione

1. Timestamp fluttuanti nel prefisso stabile. Mettevo Data corrente: {{data}} in cima al mio prompt di sistema. Quella stringa cambia ogni giorno, il che invalidava silenziosamente la mia cache dei prompt ogni 24 ore. Sposta le informazioni volatili — timestamp, ID utente — alla fine del contesto, dopo il prefisso stabile.

2. Trattare gli output degli strumenti come solo-append. Eseguivo loop agentivi in cui ogni risultato di chiamata agli strumenti rimaneva nel contesto. Al turno 8, il modello stava ragionando da un contesto che era per l’80% output di strumenti obsoleti.

3. Saltare la valutazione sulle modifiche al contesto. Le modifiche al contesto sono modifiche al comportamento del modello. Ora eseguo lo stesso harness di valutazione sulle modifiche al contesto che eseguo sulle modifiche al prompt.

Il mio flusso di lavoro di context engineering in pratica

Prima di scrivere una singola riga di codice dell’agente, schizzo i livelli di contesto:

Prompt di sistema:       ~500 token, stabile, in cache
Budget cronologia:       ~2000 token max, riassunto dopo ogni passaggio
Contesto recuperato:     ~1000-3000 token per passaggio, solo frammenti rilevanti
Budget output:           solo passaggio corrente, riassunto in avanti

La questione della selezione del modello arriva dopo. Una volta che so quale context engineering devo fare, scelgo il modello più economico che mantiene il livello di affidabilità sotto la giusta configurazione di contesto.

FAQ

Qual è la differenza tra prompt engineering e context engineering?

Il prompt engineering si concentra sulla formulazione del tuo prompt di sistema e dei messaggi utente. Il context engineering è la disciplina più ampia: decidere quali informazioni entrano nell’intera finestra di contesto — inclusa la cronologia della conversazione, i dati recuperati e gli output degli strumenti — in quale ordine e a quale costo di token.

Quanto dovrebbe essere grande il mio prompt di sistema?

Il più piccolo possibile pur essendo specifico. Punto a meno di 800 token per la maggior parte degli agenti. Un prompt di sistema che cerca di anticipare ogni scenario finisce per essere troppo lungo per essere letto in modo affidabile dal modello.

Il context engineering conta di più per alcuni modelli rispetto ad altri?

Conta per tutti loro, ma la posta in gioco è più alta con i modelli più piccoli. Un grande modello frontier può a volte riprendersi da un contesto mal strutturato; un modello più piccolo con un budget più ristretto non può.

Come faccio a sapere se il mio context engineering funziona?

Tieni traccia delle stesse metriche che monitoereresti per qualsiasi cambiamento di affidabilità: tasso di successo sul tuo set di valutazione, costo per risultato positivo e distribuzione degli errori per passaggio.

Dovrei sempre comprimere o riassumere la cronologia?

Per agenti transazionali brevi: no. Per agenti multi-turno che eseguono più di 5-6 scambi: sì, sempre. La regola empirica che uso — una volta che il budget della cronologia supera il 30% del mio budget di contesto totale, comincio a riassumere.