L'infinito Context Window è un mito: gli Agenti dimenticano il mezzo

Il mito del context window infinito

Per circa un anno, la risposta predefinita a un agente AI che iniziava a fallire era stata di aumentare il suo context window. Se l'agente era sommerso dai suoi input, si pensava, basta alzare il limite dei token e lasciare che mantenga tutto. Elizabeth Fuentes Leone, sviluppatrice advocate presso AWS, vuole ritirare questa idea. Parlando nel podcast AI Engineer, ha definito l'infinito context window un mito e ha illustrato la ragione misurabile per cui fallisce: mentre un context window si riempie, il modello non legge in modo uniforme. Presta attenzione all'inizio dell'input e alla fine, e dimentica il mezzo.

"Abbiamo molti dati, ma se i dati sono super, super grandi, l'agente dimenticherà il mezzo nella curva", ha spiegato. "Ricorderà solo la prima parte e l'ultima parte che abbiamo inviato a quel context window". Questo modo di fallire è importante ora perché gli agenti stanno uscendo dalle demo e entrando in produzione, dove supervisionano applicazioni recuperando log, interrogando database e chiamando servizi esterni. Ogni recupero scrive più dati nel context window. Poiché gli agenti portano avanti le sessioni precedenti come memoria, la finestra cresce senza limiti finché il modello non degrada e inizia a hallucinare. La risposta di Fuentes Leone non è una finestra più grande, ma una disciplina architettonica che chiama "ingegneria del contesto".

Fuentes Leone definisce l'ingegneria del contesto in una frase: "dare al modello le informazioni di cui ha bisogno quando ne ha bisogno". L'implicazione va contro un istinto diffuso. L'agente non ha bisogno di tutto seduto nella sua finestra. Peggio, una finestra sovraffollata non è solo sprecone — è attivamente pericolosa. "A volte il context window avvelena l'agente perché puoi avere un'iniezione di prompt dentro il tuo context window", ha notato.

Quattro verbi per la strategia

Organizza le sue raccomandazioni sotto quattro verbi che fungono da scheletro dell'intero approccio:

• Externalizzare: sposta i dati massivi fuori dalla finestra.
• Selezionare: recupera solo il sottoinsieme rilevante.
• Comprimere: riduce la traccia token di ciò che rimane.
• Isolare: garantisce che il contesto di lavoro di un agente non diventi il rumore di un altro.

L'obiettivo che afferma è un context window costruito per risultati ottimali e un consumo ottimale di token. La metrica non è quanti token puoi spingere dentro, ma se i token presenti sono quelli che rispondono alla domanda dell'utente.

La svolta nell'understanding

Fuentes Leone data la svolta nell'understanding in modo esplicito. Intorno alla fine del 2025, la correzione prevalente per il sovraccarico del contesto era semplicemente aggiungere più token. Ora si sa che è sbagliato, perché la curva dell'attenzione è una proprietà strutturale di come i modelli elaborano input lunghi, non una limitazione che scompare quando si alza il limite dei token. "L'infinito context window è un mito", ha detto. "Ora, un sistema si rompe quando gli strumenti restituiscono una grande quantità di dati. Sovraccarico del context window, e l'agente inizia a hallucinare, e inizia a degradarsi".

Strands: il framework open-source

Il veicolo pratico per queste idee è Strands, un framework open-source per agenti mantenuto da AWS. Fuentes Leone lo descrive come agnostico rispetto ai modelli e gratuito, con Amazon Bedrock come predefinito ma con scambi a una riga per Ollama, Gemini, Anthropic o OpenAI. L'esperienza di sviluppo è progettata per rimuovere il solito onere di cablaggio: una singola riga di codice crea l'intero ciclo dell'agente, con il prompt di sistema e gli strumenti come unici altri input.

Al di sopra di questo ciclo, Strands invia tre manager di conversazione, che governano come la cronologia della conversazione a breve termine viene gestita all'interno del context window:

• Sliding-window manager: mantiene solo l'ultimo segmento di conversazione.
• Summarization manager: riepiloga la cronologia precedente.
• Hybrid manager: combina entrambi i metodi.

Esempio di configurazione

L'esempio di configurazione di Fuentes Leone utilizza un rapporto di riepilogo del 50% mantenendo gli ultimi quattro messaggi. "Quindi manterrà gli ultimi quattro messaggi e riassumerà l'altro 50 percento", ha detto. Su ogni invocazione all'interno di una sessione, il manager preserva gli ultimi quattro messaggi e riepiloga metà di tutto il resto.

Segnala lei stessa la limitazione: questo funziona bene finché non hai memoria che non vuoi perdere. È lì che il lavoro del manager di conversazione finisce e inizia un'architettura di memoria più ampia.

Memoria a lungo termine e grafici

Fuentes Leone separa la memoria per durata e struttura, e la distinzione importa perché i manager di conversazione governano solo uno dei tre livelli.

La memoria a breve termine è la cronologia recente della conversazione — il dominio in cui operano i manager a finestra scorrevole e di riepilogo. La memoria a lungo termine è ciò di cui hai bisogno quando inizia una nuova sessione e la memoria a breve termine è andata via. La sua prescrizione è un database vettoriale e nota che puoi memorizzare diversi tipi di memoria in esso con diversi prompt che interpretano la conversazione ed estraggono ciò che vuoi mantenere. La memoria relazionale usa grafi di entità — punta il pubblico verso il booth Neo4j per profondità — e supporta query di attraversamento che catturano come le cose si collegano.

I tre non sono mutualmente esclusivi. La combinazione raccomandata: memoria a lungo termine per la sessione corrente, recupero dalla memoria a lungo termine quando una sessione passata diventa rilevante, e memoria grafica sovrapposta per le relazioni che devono essere conservate in una forma diversa rispetto a un embedding vettoriale fornisce.

Architettura concreta: recupero dei log

L'esempio di recupero dei log è dove l'architettura diventa concreta. Il problema motivante: non vuoi mettere log grezzi nel context window su ogni invocazione. Il meccanismo di Fuentes Leone utilizza due strumenti e lo stato dell'agente.

Il primo strumento restituisce un batch di log. Il secondo strumento prende quei log, li scrive in archiviazione persistente e restituisce un ID. Quell'ID vive nello stato dell'agente e nel context window come puntatore alla memoria. Un terzo strumento legge i log e riferisce all'agente che sono a posto — l'agente non ha bisogno dei log grezzi per capire quello. Se l'agente ha bisogno dei log, passa l'ID e li recupera su richiesta.

Il guadagno architettonico è che il context window trasporta un identificatore invece di un payload. "Devi evitare il riempimento del contesto", ha detto Fuentes Leone. "Quindi non hai bisogno di includere tutto in cucina. Non devi includere tutto nel context window perché l'agente non ha bisogno di tutte le informazioni lì".

Multi-agente design e contaminazione

Quando un'applicazione cresce abbastanza complessa che gli strumenti da soli non sono sufficienti, Fuentes Leone raccomanda un design multi-agente — ma con un avviso allegato. Condividere il context window tra agenti non è un trucco; è un contaminante. "Ma condividi il context window tra gli agenti. È come aggiungere rifiuti agli altri agenti, perché non tutti gli agenti hanno bisogno dell'informazione tra loro", ha detto.

La sua soluzione utilizza lo stesso principio del puntatore nel caso dell'agente singolo, applicato al livello topologico. Crei un ID per la swarm di agenti e condividi il puntatore della memoria attraverso lo stato di invocazione tra gli agenti. Ogni agente recupera solo la fetta di informazioni di cui ha bisogno. Il context window rimane snello e la swarm evita la contaminazione incrociata.

È qui che la strategia a quattro parti fa il pieno cerchio. Externalizza sposta i dati di massa fuori dalla finestra. Seleziona recupera solo il sottoinsieme rilevante. Comprimi riduce la traccia token di ciò che rimane. Isola garantisce che il contesto di lavoro di un agente non diventi mai il rumore di un altro.

Modalità di fallimento non legate ai token

Due modalità di fallimento ricevono trattamento perché degradano gli agenti anche quando il context window è perfettamente gestito. Nessuno è un problema token nel senso stretto.

Agente che non smette mai

Il primo è l'agente che non smette mai. Fuentes Leone attribuisce i loop a risposte degli strumenti chiare e a troppi strumenti disponibili, e la sua rimedio è un limite sul numero di volte che uno strumento può essere invocato. Nel suo esempio di configurazione, ogni strumento può essere invocato solo tre volte, il che impedisce il loop eterno. I requisiti di progettazione che nomina sono una chiara risposta da ogni strumento e un limite di invocazione esplicito.

Latency

Il secondo fallimento è la latenza. Quando un agente invoca strumenti MCP o API esterne che non rispondono in tempo, l'applicazione può bloccarsi. Cita il tempo di attesa massimo di API Gateway di AWS come il tipo di limite rigido che fermerà un'applicazione outright. L'approccio sincrono significa che l'agente aspetta indefinitamente una risposta. Un handle asincrono cambia il pattern: invoca il servizio, salva il lavoro e recupera la risposta su un'invocazione successiva quando è pronto.

La sua bozza di implementazione utilizza FastAPI per creare il server MCP, con due strumenti: StartLogJob e CheckJobStatus. Dice che ha eseguito molti confronti tra l'handle asincrono e il sincrono.