Il tuo agente IA dimentica tutto: i trucchi MCP che risolvono il gonfiore del contesto

Il problema che nessuno pubblicizza

Ogni demo di un agente di coding IA mostra la stessa cosa: un terminale pulito, un'istruzione chiara e un risultato ordinato. Nessuno ti mostra la terza ora, quando l'agente ha letto quaranta file, eseguito una dozzina di suite di test e riempito il suo context window con l'output rumoroso di ogni comando che abbia mai eseguito. A quel punto l'agente non diventa più intelligente. Diventa più ottuso, smemorato e incline a ripetere con sicurezza un lavoro che ha già finito.

Questo è il problema meno appariscente e più universale del coding agentico. Il contesto è la memoria di lavoro dell'agente, ed è finita. Tutto ciò che l'agente legge compete per lo stesso spazio, e la maggior parte di ciò che legge è spazzatura: log di build, stack trace, elenchi di directory, il testo completo di file di cui gli serviva una sola riga. La finestra si riempie di sedimenti, e il ragionamento che rendeva utile l'agente in primo luogo viene schiacciato fuori.

Gli strumenti che risolvono questo non sono quelli che vincono i confronti dei benchmark. Sono impiantistica. E in ottobre è stata l'impiantistica a scalare la classifica delle tendenze di GitHub.

L'idea dietro il sandboxing dell'output degli strumenti

Uno dei progetti più interessanti emersi è uno strato di ottimizzazione del contesto per agenti di coding, che attacca il problema alla radice. Il suo numero di punta è una riduzione di circa il 98 per cento nel volume di output degli strumenti che arriva al modello.

Il meccanismo è concettualmente semplice. Invece di lasciare che l'output grezzo di un comando si riversi dritto nella conversazione, lo esegui in un sandbox e passi al modello solo ciò che gli serve del risultato: un riassunto, uno stato di uscita, le righe precise che hanno corrisposto a una query. La trascrizione completa resta a disposizione perché il modello la recuperi di proposito, ma non occupa la finestra nel caso in cui sia rilevante.

È la stessa disciplina che un buon ingegnere applica per abitudine. Non incolli un intero log in una chat quando il punto è una singola riga di errore. Gli agenti, lasciati a se stessi, fanno esattamente il contrario.

C'è una bolletta attaccata a questo, ed è perciò che il tooling non è una pura finezza ingegneristica. Un context window non è gratis. Ogni token che il modello deve elaborare costa denaro e tempo, e ogni token che deve ricordare costa attenzione. Uno strumento che scarica centomila token di output di build in una sessione ti addebita due volte: una per i token e di nuovo per il degrado del giudizio del modello quando il segnale è sepolto. La riduzione del 98 per cento è in realtà una correzione di qualità mascherata da risparmio.

Una memoria che sopravvive alla sessione

L'altra metà del problema è che gli agenti dimenticano tra le sessioni, non solo al loro interno. Chiudi il terminale e il contesto è sparito. Lo riapri domani e l'agente non ha idea di cosa hai deciso, quale approccio hai scartato o perché il codice è come è. Spieghi di nuovo, l'agente deriva di nuovo, e da qualche parte una decisione viene presa due volte.

Gli strumenti di memoria persistente in questo campo adottano approcci diversi. Uno dei più visibili cattura ciò che l'agente fa durante una sessione, lo comprime con un modello e inietta le parti rilevanti nelle sessioni future. Il messaggio è poco appariscente e corretto: un agente che ricorda la forma del tuo progetto vale più di un agente marginalmente più intelligente su un singolo compito. I principali fornitori di modelli si sono mossi nella stessa direzione, aggiungendo manopole che permettono a un subagent di compattare il proprio context prima della conversazione padre, proprio per non trascinare l'intera cronologia della sessione in un compito che non ne ha bisogno.

La domanda di progettazione interessante qui è cosa ricordare. Ricorda tutto e hai ricostruito il problema originale in una forma più lenta. Ricorda troppo poco e la memoria è inutile. I progetti che stanno prendendo slancio sono quelli che ricordano in modo selettivo, sulla teoria che un buon riassunto dell'ultimo mese batte un resoconto perfetto dell'ultima ora.

Il routing come strategia di contesto

Il terzo pezzo del puzzle è il routing: decidere, prima che un compito venga eseguito, quale modello e quali strumenti gli servono, così non viene caricato di capacità che non userà mai. Un modello a cui sono state annunciate diciassette integrazioni diverse spende contesto su tutte e diciassette anche se il compito ne richiede una sola. Imporre il routing su tutte le piattaforme suona come un dettaglio infrastrutturale. In realtà è una decisione di budget di contesto travestita.

Qui il problema smette di sembrare un problema di cache e inizia a sembrare progettazione di sistemi. Il context window dell'agente è una risorsa, come lo sono la memoria e il disco, e gli strumenti che lo trattano come tale sono quelli che mantengono gli agenti coerenti su lavori lunghi. Non è un caso che i progetti di sandboxing, memoria e routing convergano: sono tre viste della stessa scarsità.

Il pattern del subagent è l'esempio più chiaro. Quando un agente genera un aiutante per un lavoro ristretto, quell'aiutante non ha bisogno di ereditare l'intera conversazione. Passargli un contesto pulito con solo il compito in corso è più economico e più preciso, ed è perciò che gli harness più recenti lasciano che un subagent compatti il proprio context prima del genitore. Il genitore conserva la cronologia lunga; il figlio riceve una scrivania fresca. I team che hanno fatto girare agenti su refactoring lunghi una settimana di solito arrivano da soli a questa regola, spesso dopo aver visto un subagent sprecare l'intera finestra a rileggere una conversazione che non gli serviva.

Perché arriva adesso

Nessuno di questi problemi è nuovo. Gli agenti perdono contesto dal primo che sia mai girato. Quello che è cambiato è che ora ci si aspetta che gli agenti girino per ore, attraverso molte sessioni, su un lavoro che conta. Un giocattolo non perde nulla quando dimentica. Uno strumento su cui un team fa affidamento per un refactoring lungo una settimana perde moltissimo.

Il mercato l'ha notato. Due anni fa, «il nostro agente ha una finestra di contesto da 200k» era un argomento di vendita. Ora la domanda utile è quale frazione di quella finestra è spesa in segnale. I fornitori che lo capiscono stanno rilasciando controlli di compattazione e isolamento del contesto dei subagent. La comunità sta rilasciando l'impiantistica che rende sopportabile il resto.

La conclusione poco appariscente

È tentador leggere le notizie sugli agenti di ottobre come una storia di modelli più intelligenti e plugin più ingegnosi. La storia più silenziosa e più duratura riguarda l'igiene. Gli agenti sono diventati abbastanza utili da girare a lungo, e i lunghi periodi espongono ogni debolezza nel modo in cui gestiscono la propria memoria.

I progetti che scalano le classifiche delle tendenze sono quelli che accettano una verità banale: il collo di bottiglia del lavoro autonomo è raramente l'intelligenza grezza. È la capacità di restare sul compito senza annegare nelle proprie note. Sistema la memoria, metti il rumore in un sandbox, instrada le capacità, e un modello solo competente all'improvviso sembra eccellente. Sbaglia queste cose e persino un modello di frontiera passerà il pomeriggio a rileggere un file di log che ha già letto cinque volte.