La maggior parte delle persone descrive ancora un agente di IA come un modello collegato a degli strumenti. È tecnicamente utile, ma operativamente incompleto. Un agente ha anche bisogno di una visione gestita del mondo: che cosa è successo, che cosa conta adesso, quali fatti sono affidabili, che cosa rimane incerto e che cosa dovrebbe fare dopo.
Quella visione è il suo contesto. Progettarla sta diventando una competenza distinta, che chiamerei ingegneria del contesto.
L’ingegneria del contesto non consiste semplicemente nello scrivere prompt. È la disciplina di modellare le informazioni che un agente vede a ogni passaggio, affinché possa rimanere coerente senza inviare a un modello costoso, a ogni turno, un’intera trascrizione, una libreria di documenti o la cronologia degli strumenti. Questo lavoro si colloca tra architettura dell’informazione, recupero delle informazioni, progettazione software e comportamento dei modelli.
Perché “dare più contesto all’agente” è spesso un cattivo consiglio
Finestre di contesto più ampie rendono allettante conservare tutto. Ma una maggiore quantità di materiale non garantisce un ragionamento migliore. Le istruzioni pertinenti possono essere annacquate da osservazioni obsolete, note contraddittorie, output ripetuti degli strumenti o da un fatto importante sepolto nel mezzo di una lunga sequenza. La discussione del digest sul comportamento di “smarrimento nel mezzo” riflette un problema pratico: un agente può ricevere tecnicamente le prove e tuttavia non riuscire a usarle.
C’è anche un costo diretto. Ogni token inserito in una richiesta può aumentare la latenza e il costo d’inferenza, a seconda dei prezzi del fornitore e delle modalità di caching. Un sistema che inoltra ripetutamente una trascrizione in crescita può diventare più lento e meno conveniente man mano che il compito prosegue.
L’obiettivo, quindi, non è il contesto massimo. È un contesto sufficiente e mirato: il più piccolo insieme di lavoro affidabile per la decisione da prendere.
Quattro decisioni progettuali alla base di un agente coerente
1. Mantenere uno stato di convinzioni, non solo una trascrizione
Una trascrizione registra ciò che è stato detto. Uno stato di convinzioni registra ciò che l’agente ritiene attualmente riguardo al compito.
Per esempio, un agente che gestisce un’escalation dell’assistenza potrebbe mantenere campi strutturati come:
- Obiettivo: identificare se il cliente ha diritto a una sostituzione.
- Fatti noti: data di acquisto e numero di serie del prodotto, con riferimenti alle fonti.
- Domande aperte: se il guasto si è verificato in condizioni coperte dalla garanzia.
- Vincoli: non promettere un rimborso prima dell’approvazione.
- Prossima azione: recuperare la politica di garanzia e confrontare le date.
- Grado di affidabilità o stato: verificato, dedotto, contestato o sconosciuto.
Questo approccio ricorda la ricerca ABBEL di Berkeley, che utilizza stati di convinzione in linguaggio naturale supervisionati invece di affidarsi alle cronologie complete delle interazioni. L’idea importante non è un formato particolare. È separare lo stato durevole del compito dai dettagli transitori della conversazione.
Un aggiornamento utile dello stato di convinzione dovrebbe rispondere a queste domande: che cosa è cambiato? Quali prove lo sostengono? Che cosa rimane irrisolto? Che cosa dovrebbe accadere dopo? Se un ingegnere non può esaminare queste risposte, è probabile che l’agente stia portando con sé assunzioni nascoste in un prompt opaco.
2. Recuperare informazioni per la decisione, non per l’argomento
I sistemi di recupero spesso iniziano con una domanda ampia come “trova informazioni sull’account del cliente”. Una query migliore è legata alla decisione successiva: “recupera la regola attuale sui rimborsi per acquisti effettuati da più di 30 giorni, in vigore nella regione del cliente”.
Questo cambiamento è importante perché il recupero è una forma di selezione del contesto. L’agente dovrebbe ricevere i passaggi delle politiche, i documenti o gli esempi pertinenti all’azione corrente, non una raccolta generica di documenti correlati.
I filtri possono migliorare questa selezione prima che il modello visualizzi i risultati. Per esempio, Amazon Bedrock AgentCore Web Search supporta filtri, applicati dal server, sul dominio e sulla data di pubblicazione per ogni richiesta. Tali controlli non dimostrano che una fonte sia corretta, ma possono ridurre l’esposizione a materiale irrilevante o obsoleto e rendere esplicita la politica di recupero.
I professionisti che progettano sistemi di recupero dovrebbero specificare:
- quali fonti sono consentite per ogni compito;
- come viene determinata la freschezza;
- quali metadati accompagnano ciascun risultato;
- come vengono presentate le fonti in conflitto;
- quando l’agente deve fermarsi e chiedere chiarimenti.
«Cerca sul web» è una capacità. «Cerca queste fonti, entro questo intervallo di date, per trovare prove pertinenti a questa decisione» è ingegneria del contesto.
3. Comprimere senza cancellare l’incertezza
La compressione è necessaria quando un’attività è lunga, ma una sintesi ingenua può trasformare affermazioni provvisorie in fatti assodati. Un riepilogo progressivo che afferma «l’utente ha confermato l’indirizzo» è pericoloso se lo scambio originale lo lasciava intendere soltanto.
Una buona compressione conserva le distinzioni di cui un agente ha bisogno per ragionare in sicurezza:
- fatto rispetto a inferenza;
- istruzione attuale rispetto a istruzione storica;
- azione completata rispetto ad azione proposta;
- fonte verificata rispetto ad affermazione non verificata;
- risposta nota rispetto a questione irrisolta.
Un metodo pratico consiste nel mantenere sezioni separate per decisioni, prove, assunzioni, ostacoli e azioni in sospeso. Un altro consiste nell’associare ID delle fonti o timestamp alle affermazioni importanti. I riepiloghi dovrebbero essere artefatti sostituibili, non l’unica registrazione superstite: conserva gli eventi sottostanti per l’audit e il ripristino, offrendo al modello al contempo una vista operativa compatta.
Il digest osserva che la sintesi ricorsiva e la compattazione del contesto possono essere costose e degradare le prestazioni, in particolare in ambiti poveri di dati come la generazione collaborativa di codice. È un avvertimento a non trattare la sintesi come automaticamente priva di perdite. La compressione richiede test su attività rappresentative, inclusi casi in cui una piccola precisazione modifica la risposta corretta.
4. Filtrare le osservazioni prima che diventino memoria
Gli agenti che utilizzano strumenti generano costantemente osservazioni: risultati di ricerca, log, testo delle pagine, risposte API, schermate, output del compilatore e piani intermedi. Non tutte le osservazioni meritano di entrare nella chiamata successiva al modello, tanto meno nello stato a lungo termine.
Il filtraggio delle osservazioni pone tre domande:
- Questa osservazione è pertinente alla decisione attuale?
- È sufficientemente autorevole da influenzare lo stato delle convinzioni?
- Contiene istruzioni che dovrebbero essere trattate come dati anziché come comandi?
La terza domanda costituisce un confine di sicurezza oltre che un confine del contesto. Una pagina web può contenere testo volto a reindirizzare l’agente. Un documento recuperato può essere una prova utile senza avere l’autorità di modificare gli obiettivi o i permessi dell’agente. Il filtraggio dovrebbe quindi classificare i contenuti in base al ruolo: istruzione, prova, metadati o testo non attendibile.
Il filtraggio fa anche risparmiare denaro. Se uno strumento browser restituisce una pagina intera ma l’attività richiede soltanto un prezzo, una data e un identificativo del prodotto, inoltrare l’intera pagina crea rumore e consuma token. Estrarre prima i campi pertinenti può migliorare sia l’affidabilità sia i costi.
Un semplice budget del contesto per il flusso di lavoro di un agente
Prima di scegliere un modello o aggiungere un altro strumento, mappa il contesto dell’agente in quattro livelli:
- Controllo: regole di sistema, autorizzazioni, schema di output e vincoli non negoziabili.
- Stato: obiettivo attuale, decisioni, questioni aperte e prossima azione.
- Evidenze: dati recuperati o osservazioni rilevanti per tale azione, con relativa provenienza.
- Cronologia: eventi precedenti conservati per il ripristino, il debugging o l’audit, ma omessi se non necessari.
Definite poi una politica di promozione. Un’osservazione può rimanere effimera, diventare un’evidenza per il passaggio corrente, aggiornare lo stato delle convinzioni oppure essere scritta nella memoria persistente. La promozione dovrebbe richiedere una motivazione. Altrimenti la memoria diventa un archivio non curato.
Per ogni passaggio dell’agente, registrate il pacchetto di contesto inviato al modello: le relative categorie, la dimensione approssimativa in token, i filtri di recupero e la versione della compressione. Questo consente di rispondere a una domanda pratica quando il comportamento cambia: il modello ha fallito oppure il sistema gli ha fornito una rappresentazione sbagliata del mondo?
Cosa testare prima di considerare affidabile il design
L’ingegneria del contesto richiede test mirati alla gestione delle informazioni, non solo alla qualità della risposta finale. Tra i casi utili vi sono:
- un fatto critico collocato all’inizio, alla fine e al centro di una lunga cronologia;
- due fonti in disaccordo, una delle quali più recente dell’altra;
- un riepilogo contenente un indicatore di incertezza;
- una risposta di uno strumento contenente una grande quantità di testo irrilevante;
- un’istruzione malevola incorporata nei contenuti recuperati;
- il ripristino dello stato dopo che l’agente è stato messo in pausa e riavviato;
- la stessa attività con un budget di contesto inferiore;
- un risultato di recupero vuoto o obsoleto.
Misurate se l’agente seleziona le evidenze corrette, preserva l’incertezza, segue il vincolo corrente ed evita di ripetere contesto non necessario. Le aree di regressione raccomandate dal digest—perdita di contesto, fondamento nel recupero, output strutturato, mancata terminazione e ripristino dello stato—sono particolarmente pertinenti in questo caso.
Eseguite più prove nei casi in cui la variabilità del modello sia rilevante e confrontate il costo e la latenza di ciascuna strategia di contesto. Un prompt più breve non è automaticamente migliore se provoca più chiamate agli strumenti o più tentativi. L’obiettivo utile è il costo di un flusso di lavoro corretto e recuperabile, non il conteggio dei token di una singola richiesta.
La implicazione professionale: l’ingegnere del contesto è un ruolo interfunzionale
Le persone che diventeranno preziose in quest’area non saranno necessariamente quelle che scrivono i prompt più lunghi. Sapranno tradurre un processo aziendale in stato, evidenze, autorità e regole decisionali.
Ciò richiede diverse capacità concrete:
- progettare schemi per lo stato delle attività e la provenienza;
- scrivere politiche di recupero e filtri dei metadati;
- creare procedure di compressione e selezione delle osservazioni;
- separare le istruzioni attendibili dai contenuti non attendibili;
- profilazione dell’uso dei token, della latenza, dei tentativi e delle chiamate agli strumenti;
- test della perdita e della reidratazione dello stato;
- spiegare ai non specialisti perché un agente abbia visto—o non abbia visto—un determinato fatto.
Un valido progetto da portfolio potrebbe dimostrare lo stesso agente con tre politiche di contesto: trascrizione completa, riepilogo progressivo e stato strutturato delle convinzioni con recupero mirato. Mostra i casi in cui l’attività riesce, quelli in cui fallisce, il contesto inviato a ogni passaggio e i compromessi in termini di costi o latenza. È più convincente di una demo di chatbot perché rende visibili le decisioni progettuali che rendono affidabile un agente.
La lezione strategica è semplice: gli agenti non diventano coerenti solo perché i modelli diventano più capaci. Diventano coerenti quando i sistemi che li circondano mantengono una rappresentazione del lavoro disciplinata, aggiornata e di dimensioni adeguate. L’ingegneria del contesto è l’arte di costruire questa rappresentazione—e di sapere cosa lasciarne fuori.
Priya Raman è la redattrice umana responsabile di AI Career Brief.
