Il contesto di una conversazione non è un archivio

Un agente che lavora a lungo accumula due cose molto diverse: la conversazione, che è volatile e limitata, e le decisioni, che dovrebbero sopravvivere alla conversazione. Confonderle è l’origine di quasi tutti i guasti di questo dominio.

Sulla Copilot CLI il limite è visibile. Il context window contiene istruzioni di sistema, messaggi, risposte e output dei tool, con una capienza fissa che dipende dal modello. Quando si avvicina alla saturazione parte automaticamente la compaction: la cronologia completa viene mandata al modello e sostituita da un riassunto strutturato con obiettivi, azioni svolte, dettagli tecnici, file importanti e prossimi passi. Puoi anticiparla con /compact e misurare quanto spazio resta con /context. La documentazione è esplicita su un punto che conviene ricordare: i dettagli fini — la formulazione esatta, l’output completo di un comando, decisioni minori prese all’inizio — possono non sopravvivere alla sintesi. Ogni compaction genera un checkpoint numerato nel workspace, e le compaction non si possono annullare.

/context                  # quanto spazio resta nel context window
/compact                  # compattazione manuale (annullabile con Esc)
/session checkpoints 2    # rileggere il secondo checkpoint

Da qui la regola operativa: se una decisione conta, non lasciarla nel contesto. Le istruzioni durevoli vivono in file versionati come AGENTS.md o .github/copilot-instructions.md. Sul cloud agent un registro condiviso esiste già ed è gratuito: l’agente crea un branch, scrive i messaggi di commit e fa push, e la pull request con i suoi commenti diventa la storia leggibile del lavoro. Nei GitHub Agentic Workflows, dove ogni esecuzione è un workflow di Actions compilato in un file .lock.yml, lo stesso ruolo lo giocano i safe outputs: risultati validati che diventano issue, commenti o pull request nel repository.

Riprendere senza rifare

Sul Copilot SDK il meccanismo esplicito è la session persistence: cronologia della conversazione, stato dei tool e contesto di pianificazione vengono salvati su disco e ricaricati più tardi, insieme ai checkpoint, al file di piano e agli artefatti prodotti. La condizione è una sola, e va imparata: devi fornire tu un sessionId a createSession(). Se non lo fai, l’SDK genera un identificatore casuale che non è riprendibile. È l’errore tipico di chi crea una sessione nuova a ogni richiesta e poi si stupisce che l’agente ricominci l’analisi da capo.

Con resumeSession() recuperi la sessione e puoi anche riconfigurarla al volo — model, systemMessage, availableTools, mcpServers, customAgents. Attenzione a cosa non torna: le credenziali del provider vanno rifornite e lo stato in memoria dei tool non viene ripristinato. Vale anche distinguere disconnect(), che libera memoria lasciando i dati su disco, da deleteSession(), che cancella tutto in modo irreversibile. Sulla CLI l’equivalente è /resume, e /chronicle interroga la cronologia delle sessioni per ricostruire che cosa hai fatto e cercarci dentro per parola chiave.

Accorgersi della deriva e correggere la rotta

La deriva si riconosce dai sintomi, non da un allarme: l’agente tocca file fuori dal perimetro concordato, riapre una scelta già chiusa, oppure produce output che contraddice quanto sta scritto in un checkpoint. Gli strumenti di verifica sono quelli già citati più il diff delle modifiche sul cloud agent, da guardare prima di finalizzare.

Per correggere mentre l’agente lavora, le due superfici si comportano in modo diverso e l’esame ci gioca sopra. Sul Copilot SDK esiste il campo mode con due valori: steering in modalità "immediate" inietta il messaggio nel turno corrente, mentre l’accodamento in modalità "enqueue", che è il default, lo mette in coda e lo elabora dopo la fine del turno, in ordine di arrivo, dando a ciascun messaggio un turno proprio. Lo steering è dichiaratamente best-effort: se l’agente ha già avviato una chiamata a un tool, l’effetto arriva dopo il completamento di quella chiamata, pur restando nello stesso turno. Sulla Copilot CLI non esiste nessuna coda separata: qualunque prompt inserito mentre Copilot sta ragionando è trattato come steering nel contesto del task attivo, ed è utilizzabile anche come feedback quando rifiuti la richiesta di permesso su un tool. Sul cloud agent, infine, la correzione passa dai commenti: menzioni @copilot in un commento e conviene raggruppare i rilievi con Start a review invece di inviarli uno alla volta.

Condividere lo stato senza avvelenarlo

Lo stato si condivide in tre modi distinti. Le remote sessions dell’SDK collegano la sessione a Mission Control e producono un URL condivisibile da cui seguirla da GitHub web e mobile. Le cloud sessions la eseguono su compute ospitato da GitHub, indicando il repository nelle opzioni cloud.repository.owner e cloud.repository.name; per riprenderle basta resumeSession() senza ripassare l’opzione cloud. Le Copilot Spaces raccolgono il contesto di un task, e Copilot Memory conserva fatti sul repository — con citazioni al codice che li sostiene — e preferenze personali, condivisi fra cloud agent, code review e CLI.

Restano i due guasti opposti. Il contesto in conflitto è avere due fonti che dicono cose diverse: le istruzioni si sommano tutte e la precedenza va dalle personali a quelle di repository (prima path-specific, poi repository-wide, poi AGENTS.md) a quelle di organizzazione, ma la documentazione stessa invita a non creare set contrastanti, perché la precedenza risolve la formalità e non l’ambiguità. Il contesto stantio è una fonte sola che non è più vera: una nota nello Space o un fatto in memoria che descrive un’architettura superata. I fatti non usati decadono da soli e i proprietari del repository possono cancellarli, ma la sola fonte che si aggiorna in automatico è quella basata su GitHub. Tutto il resto lo devi rivedere tu.