Finestra di contesto: dare agli agenti AI le informazioni giuste

Se un agente funziona in demo ma perde il filo nel lavoro reale, prima di aggiungere istruzioni conviene controllare che cosa arriva al modello. Il context engineering permette di gestire i 5 input che entrano nella finestra di contesto a ogni passaggio: istruzioni, strumenti, informazioni recuperate, memoria e cronologia. L'obiettivo è fornire elementi sufficienti per la prossima azione corretta, riducendo il materiale irrilevante che l'agente si porta dietro.

Che cos'è il context engineering?

Il context engineering, o ingegneria del contesto, consiste nel decidere che cosa vede un modello quando deve prendere la prossima decisione. Rientrano in questo lavoro le istruzioni scritte, gli strumenti tra cui può scegliere, le evidenze restituite da quegli strumenti, i ricordi caricati e la parte di conversazione conservata.

La finestra di contesto è lo spazio di lavoro del modello per una richiesta. Un token è un'unità di testo o di altro contenuto elaborata dal modello. Un documento salvato nel sistema è un'informazione disponibile; il suo contenuto diventa contesto attivo solo quando l'applicazione o l'agente lo carica.

Questa distinzione spiega un problema frequente in produzione. Un agente può avere accesso alla policy corretta e rispondere comunque sulla base di una vecchia conversazione, perché la policy in vigore non è mai arrivata al modello nel momento della decisione. D'altra parte, caricare tutte le policy può introdurre eccezioni non pertinenti e versioni superate.

Nel suo articolo tecnico del 29 settembre 2025, Anthropic descrive questa attività come «selezionare con cura e mantenere l'insieme ottimale di token (informazioni) durante l'inferenza di un LLM». La distinzione è tra scrivere istruzioni e gestire l'insieme più ampio di informazioni fornite durante l'esecuzione. L'articolo di Anthropic sul context engineering.

Nell'articolo del 2 luglio 2025, LangChain parla di «riempire la finestra di contesto con le informazioni giuste a ogni passaggio del percorso di un agente». Suddivide il lavoro in scrittura, selezione, compressione e isolamento: salvare lo stato utile, recuperare il materiale pertinente, accorciare ciò che resta e separare le indagini indipendenti. L'articolo di LangChain sul context engineering.

Sul piano pratico cambia ciò che si progetta. Un singolo prompt può rimanere fisso. La richiesta successiva di un agente, invece, cambia ogni volta che legge un file, riceve il risultato di uno strumento, completa un sotto-compito o scopre che un'ipotesi precedente era sbagliata. Serve quindi un criterio per costruire quella richiesta lungo tutta l'attività.

Documentazione verificata il 13 ottobre 2026: i comportamenti degli strumenti descritti di seguito sono stati controllati sulla documentazione corrente di Anthropic e OpenAI. L'esempio svolto illustra una possibile progettazione; non è un benchmark di produzione.

Context engineering vs prompt engineering: che cosa cambia?

Il prompt engineering migliora l'istruzione; il context engineering migliora l'intera richiesta che la contiene. Servono entrambi.

Per un agente di programmazione, fare prompt engineering può voler dire sostituire «sistema la registrazione» con «scopri perché i nuovi tentativi di registrazione inviano email di benvenuto duplicate; proponi una correzione minima e un test di regressione». Il context engineering stabilisce poi quali file della registrazione, log dei tentativi, regole del progetto e risultati precedenti fornire all'agente prima che proponga la correzione.

Un'istruzione scritta benissimo non rimedia ai log caricati dall'ambiente sbagliato. Un estratto di log scelto con cura non rimedia a un'istruzione che non chiarisce se l'agente debba diagnosticare il problema, modificare il codice o eseguire il deploy.

La competenza decisiva: stabilire i confini del contesto

Per ogni informazione bisogna decidere quando deve entrare nel contesto e quando può uscirne. Le regole permanenti del progetto, lo stato temporaneo del compito e le evidenze grezze hanno tempi di conservazione diversi.

Una convenzione di programmazione va nelle istruzioni persistenti. «Il ramo dei nuovi tentativi non è ancora stato testato» va nelle note di consegna del compito in corso. La risposta completa di un provider va in un file di evidenze accessibile, caricandone i campi rilevanti quando incidono sulla decisione.

Ecco perché anche la generazione aumentata dal recupero di informazioni, o RAG, copre solo una parte del lavoro. La RAG recupera materiale di supporto per il modello. Restano da scegliere le istruzioni, gli strumenti, la cronologia da conservare e il contenuto da restituire dopo il recupero.

Context engineering per agenti AI: gli interventi principali

Si parte dalla fonte più consistente di contesto irrilevante nel passaggio che fallisce. Non serve introdurre tutti i meccanismi insieme. Un debugger sommerso dai log richiede un primo intervento diverso da quello di un assistente che continua a dimenticare i vincoli del progetto.

Compattare la cronologia attorno alle decisioni, oltre che agli argomenti

Claude Code, l'agente di programmazione di Anthropic, offre /context per esaminare l'uso del contesto e /compact per accorciare una conversazione. La gestione automatica rimuove gli output meno recenti degli strumenti e, se necessario, riassume la conversazione. La documentazione avverte esplicitamente che le istruzioni dettagliate fornite nelle fasi precedenti possono andare perse. Gestione del contesto in Claude Code.

La compattazione deve avere uno scopo. Nell'indagine sulle email di benvenuto, si può usare /compact Preserve the current goal, change boundaries, relevant file paths, observed evidence, failed hypotheses, and the next unresolved question. Il comando fornisce indicazioni specifiche per il compito; non garantisce che ogni dettaglio venga conservato.

Prima di proseguire, bisogna verificare che il riepilogo distingua ancora tra osservato, dedotto e non verificato. «Esaminati i nuovi tentativi di invio delle email» è un'etichetta tematica. «L'accettazione da parte del provider è confermata; resta da esaminare il percorso della conferma locale» descrive uno stato su cui si può agire.

La compattazione comporta una perdita di informazioni. Le evidenze originali devono rimanere accessibili e le regole permanenti devono stare nelle istruzioni del progetto, così un passaggio successivo può recuperare i dettagli necessari.

Recuperare le evidenze quando servono

Si recupera la fonte che risponde alla prossima domanda, ampliando la ricerca solo se il risultato non basta. Nell'articolo tecnico, Anthropic descrive questo approccio come la conservazione di riferimenti leggeri e l'uso di strumenti per caricare le informazioni al momento del bisogno. Contesto just-in-time.

In Claude Code, gli strumenti di lettura dei file e la shell consentono di lavorare così. Si può chiedere all'agente di individuare il gestore dei nuovi tentativi, leggere quel gestore e il codice che lo chiama, quindi esaminare la sequenza di errori corrispondente. Quando è abilitato lo strumento dedicato Grep, questo può restituire percorsi dei file, contenuti corrispondenti o conteggi al posto di file interi. Riferimento degli strumenti di Claude Code.

Se si sviluppa un proprio agente, conviene restituire un riferimento alla fonte, un estratto pertinente e metadati sufficienti a definirne l'ambito: ambiente, identità del record, versione o data di validità. Una chiamata successiva allo strumento potrà aprire il materiale circostante.

Il recupero può tralasciare evidenze rilevanti. Serve una regola per ampliare la ricerca. Se una ricerca circoscritta non trova nulla, si modifica l'ambito o la query prima di concludere che l'informazione non esiste. Se l'estratto non permette di stabilire se si applica un'eccezione, si carica anche il resto della sezione.

Ridurre i risultati degli strumenti prima che entrino nella conversazione

Lo strumento dovrebbe restituire ciò che serve per la prossima decisione, lasciando un modo per recuperare i dettagli omessi. Per gli strumenti con output prolissi, Anthropic consiglia filtri, paginazione, selezione di intervalli e troncamento, accompagnati da indicazioni utili quando i risultati vengono accorciati. Le indicazioni di Anthropic per progettare gli strumenti.

Claude Code applica una versione concreta di questo schema agli output molto lunghi dei comandi shell riusciti: superato il limite del contenuto inserito direttamente nella conversazione, fornisce il percorso di un file salvato e un'anteprima, così l'agente può cercare nel file o leggerlo quando serve. La gestione documentata dei comandi falliti è diversa: non bisogna quindi presumere che ogni errore troncato includa il percorso di un file da cui recuperarlo. Gestione dell'output della shell.

Per l'agente che indaga sulla registrazione, un risultato utile dei log contiene l'evento corrispondente, l'operazione precedente, l'errore e la posizione nella fonte. Le richieste riuscite e ripetitive possono restare nel file di log. Il codice di errore e l'identità dell'evento devono rimanere esatti: una descrizione generica come «qualcosa è andato in timeout» può cancellare proprio l'indizio che determina la correzione.

Troncare alla cieca può eliminare l'eccezione decisiva. Bisogna rendere visibile l'omissione e fornire una query di approfondimento o un riferimento al file. Prima di tagliare le evidenze contraddittorie, si elimina il rumore ripetitivo.

Usare subagenti senza fork per indagini con un contesto pulito

I subagenti di Claude Code possono svolgere un'indagine circoscritta in una finestra di contesto separata e restituirne il risultato. Un subagente senza fork parte dalla propria definizione e dal compito assegnato; un fork della conversazione eredita la cronologia del genitore. Entrambi separano il lavoro successivo, ma solo il primo parte da un contesto pulito. Subagenti e fork.

Un incarico delegabile potrebbe essere: «Esamina il percorso dei nuovi tentativi di invio delle email. Non modificare i file. Restituisci i percorsi rilevanti, le evidenze di consegna duplicata, le spiegazioni alternative e la prossima verifica». Occorre includere i vincoli necessari al subagente, senza dare per scontato che conosca la conversazione principale.

Il risultato deve essere abbastanza circoscritto da poter essere usato: conclusioni, riferimenti alle evidenze e incertezze. Se il subagente restituisce l'intera cronologia delle proprie letture, non fa che riportare l'eccesso di materiale nella conversazione principale.

I subagenti effettuano richieste proprie e consumano risorse. Possono ripetere lavoro già svolto se l'incarico omette una decisione già presa dall'agente principale. Sono utili quando l'indagine è separabile e i suoi output intermedi non devono essere conservati nel contesto principale. I ragionamenti strettamente collegati vanno tenuti insieme. Per la configurazione, si rimanda alla guida ai subagenti di Claude Code.

Assegnare ai file di memoria una funzione limitata e stabile

CLAUDE.md è un file di istruzioni del progetto, non il posto in cui incollare tutte le conversazioni concluse. Claude Code dispone anche di una memoria automatica per gli appunti appresi durante il lavoro. La documentazione distingue entrambe dalle configurazioni che impongono vincoli tecnici: scrivere un divieto in un file di memoria non rende un'azione tecnicamente impossibile. La memoria di Claude Code.

Per un piccolo team di prodotto, il file permanente dovrebbe contenere le regole specifiche del repository, i comandi effettivi di build e test, i limiti delle modifiche e i rimandi ai riferimenti di approfondimento. Lo stato temporaneo dell'indagine va in una nota separata dedicata al compito. Per la struttura del file, si veda CLAUDE.md come memoria del team.

C'è un limite poco evidente: importare un documento lungo in CLAUDE.md significa caricare anche quel contenuto. Spostare testo nei file importati può migliorare l'organizzazione senza ridurre il contesto attivo. Per le istruzioni necessarie solo in una parte del repository, si possono valutare le regole documentate con ambito limitato ai percorsi. Per i workflow riutilizzabili, le skill di Claude Code normalmente mostrano prima le descrizioni e caricano le istruzioni complete quando vengono invocate. Importazioni della memoria e regole per ambito, caricamento delle skill.

I file persistenti possono conservare ipotesi superate con la stessa efficacia con cui conservano conoscenze utili. Vanno rimossi gli incidenti risolti e i comandi sostituiti. Per i fatti soggetti a cambiamento, si annota una fonte o una revisione. Per approfondire la distinzione tra sessione, contesto di lavoro e archiviazione durevole, si rimanda alla guida alla memoria degli agenti.

Come applicano queste tecniche Claude Agent SDK e Codex

Questi meccanismi sono disponibili in strumenti specifici; resta all'applicazione il compito di scegliere le evidenze e delimitare il lavoro. La gestione automatica del contesto non può stabilire quale informazione aziendale il workflow abbia dimenticato di recuperare.

Claude Agent SDK: integrare il ciclo dell'agente nell'applicazione

Claude Agent SDK mette a disposizione delle applicazioni Python e TypeScript gli strumenti, il ciclo di esecuzione dell'agente e la gestione del contesto alla base di Claude Code. È adatto a integrare un agente in un prodotto o in un'automazione che si gestisce direttamente. Panoramica di Agent SDK.

Quando la finestra si avvicina al limite, l'SDK compatta automaticamente la cronologia meno recente ed emette un evento di sistema compact_boundary. Registrare quell'evento insieme agli esiti dei compiti permette di individuare i fallimenti che compaiono dopo il riepilogo. I subagenti senza fork dell'SDK mantengono il lavoro intermedio nelle proprie conversazioni e restituiscono il messaggio finale. Il ciclo dell'agente nell'SDK, subagenti dell'SDK.

Il caricamento delle istruzioni del progetto va configurato in modo esplicito. Le opzioni predefinite attuali di query() abilitano le fonti utente e di progetto. Se si specifica settingSources in TypeScript o setting_sources in Python, occorre includere project quando serve il CLAUDE.md del progetto; un array vuoto ne impedisce il caricamento. A determinarlo sono le fonti delle impostazioni, non la scelta del preset di prompt di sistema claude_code. Caricamento delle istruzioni nell'SDK.

Anche un ciclo di esecuzione efficace ha bisogno di una strategia di recupero specifica per il dominio. Un agente di assistenza deve comunque sapere come si identifica il cliente corrente, quale policy si applica e quali evidenze sono necessarie prima di agire.

Codex: separare le istruzioni del repository dalla chat in corso

Codex di OpenAI legge le istruzioni di AGENTS.md prima di iniziare il lavoro. Combina le indicazioni globali con i file del progetto lungo il percorso dalla radice del repository alla directory di lavoro; le indicazioni caricate più avanti prevalgono sulle precedenti e AGENTS.override.md ha la priorità nella propria directory. Istruzioni di progetto in Codex.

Questa gerarchia permette di tenere le regole generali di build alla radice e quelle specialistiche vicino al lavoro pertinente. Codex CLI offre anche /compact per riassumere la chat visibile e /init per creare una struttura iniziale del file di istruzioni. Prima di considerarla autorevole, bisogna verificarla rispetto al proprio repository. Comandi di Codex.

Un file di istruzioni del repository non registra automaticamente il compito in corso. Obiettivo attuale, risultati confermati, lavoro ancora da svolgere e posizioni delle evidenze vanno salvati separatamente. Dopo un riavvio o una compattazione, la richiesta successiva dovrebbe rendere disponibile questo stato senza riprodurre l'intera indagine.

Un esempio di context engineering: alleggerire il contesto di un agente

Si riduce il materiale attorno alla decisione, conservando ciò da cui la decisione dipende. Consideriamo un ipotetico agente di programmazione incaricato di indagare su email di benvenuto duplicate dopo nuovi tentativi di registrazione. I nomi dei file e le evidenze che seguono illustrano il progetto; non sono risultati di un sistema in produzione.

Il materiale iniziale, sovraccarico, comprende l'intero manuale del team tecnico, ampie porzioni del repository, log di servizi non pertinenti, tutti gli scambi di debug precedenti e strumenti per attività amministrative estranee al compito. Il lavoro effettivo è più circoscritto: trovare il percorso che genera l'invio duplicato, proporre la modifica minima e individuare un test di regressione. Le modifiche allo schema sono fuori ambito.

1. 1

   Conservare il compito attivo e i vincoli permanenti

   Le richieste concorrenti nella trascrizione vanno sostituite con l'obiettivo corrente e i criteri di accettazione. Il divieto di modificare lo schema deve rimanere visibile. Si rendono disponibili gli strumenti del repository necessari al compito, escludendo da questa esecuzione le definizioni degli strumenti amministrativi non pertinenti. Le convenzioni stabili del repository vanno nel file di istruzioni appropriato; le osservazioni temporanee restano nella nota del compito. L'intero manuale non va inserito in un'importazione caricata automaticamente.

2. 2

   Sostituire i file in blocco con una mappa delle evidenze

   Si conservano i riferimenti a signup-handler.ts, welcome-job.ts, al test dei nuovi tentativi e al file di log pertinente. Questi nomi sono esemplificativi. Il gestore e il worker si leggono quando rispondono alla prossima domanda, esaminandone le dipendenze quando necessario. La mappa rende raggiungibili le evidenze; non sostituisce la loro lettura.

3. 3

   Filtrare il risultato dello strumento attorno al problema

   Si richiedono l'evento di registrazione interessato e la sequenza dei relativi tentativi. Supponiamo che il record ipotetico mostri l'accettazione da parte del provider, seguita da una conferma locale mancante e da un altro tentativo accodato. Si conservano questa sequenza, l'identità dell'evento e la posizione nella fonte. Le richieste riuscite non pertinenti restano nel log originale. Va mantenuta l'incertezza sull'effettiva consegna al secondo tentativo.

4. 4

   Isolare una ricerca circoscritta

   A un subagente senza fork si assegna il compito di trovare dove è implementata la prevenzione degli invii duplicati, fornendo l'ambito del lavoro e i percorsi pertinenti. Si chiedono posizioni ed evidenze, con una dichiarazione esplicita se la ricerca è rimasta incompleta. Il risultato torna all'agente principale; le letture esplorative del subagente restano fuori dalla conversazione principale.

5. 5

   Compattare l'indagine in un passaggio di consegne utile

   Si conservano l'obiettivo corrente, le evidenze note, le spiegazioni scartate, la domanda irrisolta e l'azione successiva. Deve rimanere chiara la distinzione tra un nuovo tentativo accodato e una consegna duplicata confermata. La trascrizione originale va archiviata, così l'agente può recuperare un dettaglio anziché procedere per supposizioni.

6. 6

   Costruire la richiesta successiva con il materiale rimasto

   Si caricano il compito, le regole permanenti, l'estratto pertinente del gestore, la sequenza filtrata degli eventi e il risultato del subagente. L'azione successiva è esaminare il percorso della conferma e quello di prevenzione dei duplicati, quindi proporre il test di regressione. Se l'azione richiede altre evidenze, si caricano; non si riallega per abitudine l'intero archivio.

La nota del compito risultante potrebbe essere questa:

Obiettivo: spiegare le email di benvenuto duplicate dopo nuovi tentativi di registrazione e proporre una correzione minima con un test di regressione.
Vincolo: lasciare fuori ambito le modifiche allo schema.
Evidenze: la sequenza di log selezionata mostra l'accettazione da parte del provider, una conferma locale mancante e un altro tentativo accodato. Conservare il riferimento all'evento e la posizione del log originale.
Da chiarire: se il nuovo tentativo accodato abbia portato alla consegna e dove intervenga la prevenzione degli invii duplicati.
Prossima verifica: esaminare i percorsi della conferma e della prevenzione dei duplicati nel gestore e nel worker indicati.

Questa nota ipotetica lascia visibile l'incertezza. Quando formula la diagnosi, il modello riceve anche l'estratto che la supporta.

Il risultato è un insieme di contenuti più piccolo, senza affermare una riduzione dei token. Il numero esatto di token dipende dalla richiesta effettiva e dal tokenizer. Una spesa inferiore e tassi di completamento migliori vanno misurati; l'esempio stabilisce che cosa eliminare e che cosa conservare.

Un modello per il passaggio di consegne

La nota del compito può usare questi campi, compilati con evidenze reali dell'esecuzione:

• Obiettivo e condizione di completamento: la richiesta attuale e ciò che permetterebbe di considerarla conclusa.
• Vincoli: i limiti che il passaggio successivo deve mantenere.
• Fatti accertati: ogni risultato abbinato alla posizione della fonte e alla revisione o all'ambito pertinente.
• Incertezze: ciò che resta dedotto, contraddittorio o non esaminato.
• Prossima azione: la verifica successiva e il punto da cui recuperarne le evidenze.

La nota va aggiornata quando cambia un risultato. Aggiungere ogni nuovo pensiero senza correggere quelli precedenti ricrea il problema iniziale in un file più piccolo.

Finestra di contesto e costi: servono verifiche diverse

Va ottimizzato il costo di un risultato accettato, non la lunghezza di una singola richiesta. Una conversazione principale più piccola può accompagnarsi a più chiamate dei subagenti, più richieste di recupero o più tentativi falliti.

Due limiti documentati per le istruzioni mostrano perché contano le unità di misura. Il limite predefinito complessivo dei documenti di progetto in Codex è di 32 KiB, cioè 32 × 1,024 = 32,768 byte. È un limite in byte, non un budget di token. Claude Code consiglia di mantenere ogni CLAUDE.md sotto le 200 righe: è un'indicazione di scrittura, non un limite rigido della finestra di contesto. Nessuno dei due numeri permette di prevedere un risparmio. Limite delle istruzioni di Codex, indicazioni di scrittura di Claude Code.

Per un workflow di produzione, si registrano i costi dell'agente principale, dei subagenti, della compattazione, del recupero e dei nuovi tentativi. Poi si calcola:

Costo per compito accettato = costo totale del workflow su tutti i tentativi ÷ compiti che soddisfano i criteri di accettazione.

Per un budget mensile, agli addebiti per l'uso del modello si sommano quelli per strumenti, recupero, archiviazione e hosting. Non esiste un prezzo mensile unico del context engineering, né si può sostenere un risparmio in dollari senza conoscere il carico di lavoro e le tariffe applicabili del provider.

La cache rende il confronto più complesso. La cache dei prompt di OpenAI riutilizza i prefissi corrispondenti delle richieste già assemblate. La compattazione può modificare quel prefisso e ridurre il riuso della cache, anche se la richiesta diventa più breve. Conviene mantenere stabili, quando possibile, le istruzioni riutilizzabili e confrontare il costo totale prima e dopo la modifica. Un calo del tasso di cache hit, da solo, non dimostra che l'ottimizzazione sia fallita. Prompt caching di OpenAI.

La guida alla diagnostica del prompt caching di GPT-6 aiuta a distinguere i problemi causati dai prefissi che cambiano da quelli dovuti a contenuti superflui. Una cache rende meno costosa l'elaborazione degli input ripetuti; non decide se quegli input siano pertinenti al compito.

Buone pratiche di context engineering: da dove intervenire

Si interviene quando la traccia di esecuzione mostra un problema di contesto, scegliendo la modifica minima che lo risolve. La traccia è la sequenza registrata di richieste, chiamate agli strumenti e risultati, compreso ciò che il modello ha visto prima di ogni decisione.

Per chi sviluppa, il punto da esaminare è il passaggio immediatamente precedente all'azione sbagliata. Se mancano le evidenze, si corregge il recupero. Se sono sepolte sotto output ripetitivi, si filtra il risultato dello strumento. Se la discussione precedente prevale sul compito attuale, si correggono lo stato del compito e il passaggio di consegne. Se un'indagine separabile sommerge la conversazione principale, la si isola.

Per chi gestisce il sistema, occorre definire un esito accettato e conservare fallimenti rappresentativi da usare nella valutazione. Sugli stessi compiti si confrontano qualità del completamento, affermazioni prive di supporto, nuovi tentativi, latenza e costo totale. Si modifica una regola di gestione del contesto alla volta, così il risultato resta interpretabile. Le tracce esistenti possono servire a costruire casi di valutazione offline.

Per chi acquista, le domande da porre sono se il prodotto mostri il contesto e i risultati degli strumenti alla base di una risposta, conservi i riferimenti alle fonti dopo il riepilogo e permetta di controllare le istruzioni persistenti. È difficile diagnosticare una funzione di «memoria» se non si può vedere che cosa viene caricato.

Meglio rinviare l'aggiunta di nuovi meccanismi quando un workflow breve e circoscritto è già affidabile. Potrebbero bastare un'istruzione più chiara o un messaggio di errore dello strumento migliore, senza introdurre un servizio di memoria o una rete di subagenti. Se il problema dipende da permessi errati, logica applicativa difettosa o dati sorgente non disponibili, bisogna intervenire direttamente su quella causa: la sola cura del contesto non può risolverlo.

Che cosa si sopravvaluta del context engineering?

Una finestra di contesto più ampia, più memoria e più agenti aumentano le capacità disponibili; non dimostrano che le decisioni siano migliori. La domanda utile è se aiutino quel workflow a portare le informazioni giuste al passaggio successivo.

«Metti tutto nel prompt» evita di scegliere, ma introduce materiale in competizione. «Riassumi tutto» seleziona in modo troppo aggressivo se cancella l'eccezione importante. «Fallo gestire a un subagente» aiuta solo quando il compito può essere delegato senza perdere decisioni essenziali.

L'errore più costoso è confondere una richiesta più breve con un sistema validato. Un agente che risponde a basso costo usando la policy sbagliata continua a sbagliare. Una buona strategia di gestione del contesto dovrebbe rendere la risposta più facile da verificare: la regola applicabile è visibile, le evidenze di supporto hanno una fonte e le incertezze irrisolte rimangono esplicite.

Le domande di chi sviluppa un agente che perde il filo

Il context engineering può correggere un agente che funziona in demo ma fallisce in produzione?

Può intervenire su evidenze mancanti, istruzioni superate, output eccessivi degli strumenti e perdita dello stato del compito. Prima va esaminata la richiesta che fallisce. Uno strumento difettoso, una logica applicativa errata o un compito oltre le capacità del modello richiedono una soluzione specifica. La modifica va valutata in base agli esiti accettati su compiti rappresentativi.

Per iniziare servono un database vettoriale o un framework multiagente?

No. Si parte da istruzioni di progetto esplicite, recupero mirato di file o documenti, risultati degli strumenti circoscritti e un passaggio di consegne sul compito. Si aggiunge la ricerca semantica quando è necessaria per trovare il materiale pertinente, oppure un subagente quando un'indagine autonoma trae vantaggio da un contesto separato.

Come capire se il contesto è stato ridotto troppo?

Bisogna verificare che per la prossima decisione siano ancora disponibili la regola applicabile, le evidenze di supporto, l'ambito di validità e le eccezioni importanti. Se l'agente deve indovinare un fatto rimosso, il contesto è troppo scarno. Va mantenuta una fonte recuperabile, ampliando la lettura quando l'estratto non risolve la questione.

Da fare lunedì: prendere un'esecuzione fallita già disponibile ed esaminare la richiesta che precede la prima azione sbagliata. Classificarne i contenuti come istruzioni permanenti, stato del compito attivo, evidenze necessarie ora o materiale che può restare archiviato. Applicare la modifica minima corrispondente, poi confrontare l'esito e il costo totale del workflow sugli stessi casi di valutazione.

Iscriviti alla newsletter per ricevere guide pratiche allo sviluppo e alla gestione di agenti utili.