Gli agenti locali vogliono budget di contesto

Gli agenti locali vogliono budget di contesto. Questa è la tesi, e diventa più importante quando i workflow AI locali o ibridi passano dalla demo convincente all’uso quotidiano.

Una finestra di contesto più grande sembra un upgrade semplice. L’agente vede più documenti, più cronologia, più output dei tool, più codice e più istruzioni. Ma il contesto non è un cassetto in cui buttare tutto senza conseguenze. È un vincolo operativo. Ogni token aggiunto compete con un altro token, usa memoria, può aumentare la latenza e può rendere più difficile capire perché l’agente ha fallito.

La documentazione di Ollama definisce la context length come il numero massimo di token a cui il modello ha accesso in memoria. Collega anche i valori di default alla VRAM, indica che web search, agenti e coding tool dovrebbero usare almeno 64.000 token, e avverte che contesti più grandi richiedono più memoria. È una base sufficiente per smettere di trattare la context length come uno slider di preferenza e iniziare a trattarla come un budget di workflow. La fonte operativa è la documentazione ufficiale di Ollama sulla context length.

Il contesto non è memoria gratis

Il problema non è volere una finestra più ampia. Molti workflow agentici ne hanno davvero bisogno. Un agente di coding può dover leggere il brief, alcuni file, l’output dei test, i risultati dei tool e una spiegazione finale della patch. Un agente di ricerca può dover gestire pagine recuperate, tracce di ricerca, estratti di fonte, vincoli dell’utente e risposta strutturata. Un assistente locale per il supporto può dover usare policy di prodotto, riassunto dell’ordine, messaggi recenti e regole di escalation.

L’errore è pensare che una finestra più grande elimini la necessità di decidere cosa merita di entrarci.

Una finestra da 64k o 128k può rendere i team pigri in modo molto preciso. Smettono di chiedersi se prompt, retrieval, trace dei tool e contratto di risposta stiano facendo ciascuno il proprio lavoro. Aggiungono chunk invece di migliorare la precisione del retrieval. Conservano log completi invece di sintetizzare lo stato operativo. Lasciano che l’agente si porti dietro ambiguità vecchie invece di forzare un checkpoint. La finestra cresce, ma il workflow diventa meno ispezionabile.

Per questo l’argomento di RAG: contratti di retrieval, non finestre più grandi vale anche oltre il RAG classico. Se l’agente non sa spiegare perché un documento è entrato nel contesto, più capacità gli dà solo più spazio per mescolare prove utili, materiale scaduto e rumore plausibile. Il modello può comunque rispondere bene in superficie, ed è proprio lì il rischio.

Un budget di contesto riporta al centro la domanda giusta: su cosa è autorizzato a spendere attenzione questo workflow?

Cosa deve contenere un budget di contesto?

Un buon budget di contesto sta in una pagina. Non deve essere un foglio token teorico per ogni run possibile. Deve descrivere un workflow reale, con input realistici e un percorso di fallback esplicito.

Si parte dal tipo di task. “Rispondere a domande sulle policy” è troppo generico. “Scrivere una risposta sull’idoneità al rimborso usando l’estratto policy più recente, il riassunto dell’ordine e due messaggi precedenti” è più utile. Il task più stretto dice quali input meritano budget.

Poi si elencano le corsie del contesto. Un budget pratico per un agente locale di solito include sei corsie.

Prima corsia: istruzioni di sistema e sviluppatore. Devono includere ruolo, confini, formato di output, regole sui tool e comportamento di rifiuto o escalation. Se queste istruzioni vengono schiacciate da documenti e trace, l’agente può avere i fatti ma perdere disciplina operativa.

Seconda corsia: intento dell’utente e stato della conversazione. Non serve portarsi dietro tutta la chat in modo cieco. Spesso è meglio uno stato sintetico, soprattutto quando i turni vecchi contengono decisioni superate.

Terza corsia: input recuperati. Qui i team spendono troppo. Invece di “top 20 chunk”, definisci classi di documento, numero massimo di estratti, regole di freschezza e criteri di esclusione. Se serve più materiale di quanto il budget consenta, il problema non è solo il contesto: è il disegno del retrieval.

Quarta corsia: trace dei tool. Agenti che chiamano ricerca, shell, database o API interne possono riempire la finestra con log. Nel contesto deve entrare la prova che serve alla risposta finale, non ogni riga prodotta dal tool. Per la governance, il trace completo può stare fuori dal prompt, in osservabilità, mentre il modello riceve una traccia di lavoro compressa.

Quinta corsia: spazio di output. È quella che molti dimenticano. Se il modello riempie la finestra con input, resta troppo poco spazio per ragionare, citare, strutturare o produrre una patch. Un budget deve riservare token alla risposta finale attesa.

Sesta corsia: fallback. Quando il budget viene superato, l’agente non deve infilare altro materiale nel prompt in silenzio. Deve scegliere un comportamento noto: chiedere uno scope più stretto, sintetizzare lo stato intermedio, fare un secondo passaggio, scalare a una persona o fermarsi se manca una fonte obbligatoria. È lo stesso approccio operativo descritto in I workflow AI vogliono corsie di escalation.

Come testare il budget prima della release?

Non basta testare il caso felice. Un budget di contesto serve proprio perché mostra dove il workflow si rompe.

Prepara tre fixture. La prima è un caso normale che deve stare comodo nel budget. La seconda è un caso limite che quasi lo riempie. La terza è un caso in overflow che deve attivare il fallback. Se tutti e tre i casi passano perché l’agente produce una risposta plausibile, il test è troppo debole.

Per ogni fixture, guarda quattro cose.

Controlla l’inclusione. Il materiale obbligatorio è entrato nel contesto? Se la risposta finale dipende da una policy, da un file o da un dato cliente, quel materiale deve essere visibile nel contesto operativo o sintetizzato in modo esplicito.

Controlla l’esclusione. Il materiale irrilevante è rimasto fuori? Conta quanto l’inclusione. I fallimenti da contesto lungo spesso nascono dal rumore plausibile, non solo dai dati mancanti.

Controlla la forma del trace. L’output dei tool arriva come prova utilizzabile o come dump grezzo? Gli agenti locali sono particolarmente esposti a questo errore perché il team può pensare che il compute locale renda accettabile lo spreco. Lo spreco resta spreco se nasconde la ragione della risposta.

Controlla la riserva di output. Il modello ha spazio per produrre l’artefatto richiesto? Se vuoi un memo decisionale, una spiegazione di diff o una risposta sicura per il cliente, devi riservare spazio a quella forma.

Questa disciplina fa parte della governance runtime. Gli agenti in produzione vogliono guardrail perché la capacità del modello non basta a rendere un agente pronto per la produzione. Lo stesso vale per il contesto. Un valore alto non è un guardrail. È un limite di capacità da governare.

Quando conviene accorciare invece di allargare?

A volte ha senso aumentare il contesto locale. Se il workflow richiede davvero molte prove, l’hardware lo regge e l’agente supera i test di confine, una finestra più grande può essere giustificata.

Ma molti team dovrebbero accorciare prima di allargare.

Accorcia quando il retrieval è rumoroso. Una finestra più grande non corregge un contratto di fonte debole. Permette solo al retrieval debole di portare più disordine.

Accorcia quando l’agente ripete assunzioni vecchie. Portare più chat history può preservare contesto, ma può anche preservare confusione. Sintetizza le decisioni, elimina i turni superati e rendi esplicito l’intento corrente.

Accorcia quando i trace dei tool sono verbosi. Il modello non ha bisogno di una risposta database completa se il task richiede solo tre campi. La risposta completa può essere salvata altrove.

Accorcia quando il formato di risposta è instabile. Se il modello non produce in modo affidabile l’output richiesto, non spendere tutto il budget sugli input. Riserva spazio alla risposta e stringi il contratto.

Accorcia quando latenza o pressione sulla memoria rendono il workflow fragile. La documentazione di Ollama è chiara: più contesto richiede più memoria. Su hardware locale questo non è un dettaglio astratto. Influenza cosa può girare insieme al modello, se il modello resta su GPU e se il workflow sembra affidabile.

Scrivi il budget prima di muovere lo slider

La call to action è semplice: prima di aumentare la context length di un agente locale, scrivi un budget di contesto di una pagina per un workflow.

Dai un nome al task. Elenca le corsie. Metti limiti indicativi accanto a istruzioni, stato utente, input recuperati, trace dei tool e spazio di output. Definisci il fallback quando il budget viene superato. Aggiungi tre fixture: normale, limite, overflow. Poi esegui l’agente e guarda cosa entra davvero nel contesto.

Sembrerà più lento che spostare uno slider. È anche il modo in cui un agente locale diventa operabile.

Il punto non è tenere il contesto piccolo per principio. Il punto è renderlo responsabile. Gli agenti locali vogliono budget di contesto perché la context length non è capacità da sola. È una superficie operativa scarsa, dove prove, istruzioni, memoria, trace e risposta competono. Se non la metti a budget tu, la spenderà l’agente al posto tuo.