Tre orizzonti di memoria, non uno

Quando si parla di memoria di un agente conviene tenere separati tre orizzonti, perché si amministrano in modo diverso e vivono su superfici diverse.

Il primo è la memoria di breve termine, cioè il context window: l’insieme di informazioni che il modello può considerare mentre genera una risposta. Nella Copilot CLI vi confluiscono system prompt, custom instructions, definizioni dei tool di sistema e dei tool MCP, messaggi e output dei tool; il comando /context ne mostra la ripartizione, compreso lo spazio libero. Quando l’occupazione si avvicina all’80% scatta la compaction: la cronologia viene sostituita da un riassunto strutturato che conserva obiettivi, azioni compiute, dettagli tecnici, file toccati e passi successivi. È comodo ma non gratuito, perché i dettagli fini possono perdersi nel riassunto.

Il secondo orizzonte è la memoria che sopravvive alla singola sessione. Nel Copilot SDK si chiama session persistence: se fornisci un tuo sessionId la sessione diventa ripristinabile con resumeSession, e lo stato finisce su disco sotto ~/.copilot/session-state/ (checkpoint della conversazione, stato di pianificazione dell’agente, artifact prodotti). Senza un id esplicito l’SDK ne genera uno casuale e la sessione non si può riprendere. Le chiavi API non vengono mai scritte su disco e lo stato in memoria dei tool non è persistito: con BYOK devi ripassare la configurazione provider al ripristino.

Il terzo orizzonte sono le fonti esterne che si portano dentro come contesto: l’indice semantico del repository (repository indexing), i Copilot Spaces che raccolgono repository, codice, issue, pull request, testo libero e file caricati, i server MCP, e le custom instructions in .github/copilot-instructions.md, nei file *.instructions.md o in AGENTS.md. Non sono memoria dell’agente: sono materiale che qualcuno ha deciso di mettergli davanti.

Copilot memory: che cosa ricorda e chi può dimenticarlo

Copilot memory è il meccanismo, in public preview, che fa persistere conoscenza fra sessioni, e distingue due tipi di voce.

I repository-level facts riguardano il repository: convenzioni di codice, decisioni architetturali, comandi di build, regole specifiche del progetto. Sono condivisi con chi ha accesso al repository, nascono dal lavoro di utenti con permesso di scrittura che hanno la funzionalità attiva, portano con sé citazioni e vengono validati rispetto al branch corrente prima di essere applicati.

Le user-level preferences sono preferenze personali, dichiarate o dedotte, su come l’utente vuole interagire con Copilot, e restano legate a chi le ha generate. Se ricevi Copilot da più organizzazioni devi selezionare una default billing entity, altrimenti le preferenze personali non vengono generate.

Attenzione a quali superfici la usano: la documentazione indica il cloud agent, Copilot code review e la Copilot CLI, e precisa che la CLI applica i repository-level facts più le user-level preferences dell’utente che ha avviato l’operazione, mentre code review usa soltanto i repository-level facts. Non dedurne che lo stesso valga per i GitHub Agentic Workflows: quella superficie non compare nell’elenco.

Sui permessi la divisione è netta, e conviene impararla per ruolo. L’utente gestisce le proprie preferenze da Copilot settings, sezione Memory, e da lì può portare la funzionalità su Disabled. Chi amministra il repository rivede e cancella i repository-level facts dalle impostazioni del repository, voce Copilot > Memory. L’amministratore di organizzazione o enterprise abilita prima la policy Copilot Memory (per l’enterprise da AI controls > Copilot, per l’organizzazione da Copilot > Policies), e può esportare le preferenze in formato JSONL oppure cancellarle, per singolo utente o in blocco. Export, delete e opt-out di un utente compaiono nell’audit log. È il punto che l’esame ama chiedere: nei piani gestiti l’amministratore abilita e poi l’utente può fare opt-out, non il contrario.

Ritagliare la memoria sul compito

Più memoria non vuol dire risposte migliori. Ogni fatto ricordato e ogni istruzione occupano spazio nella stessa finestra in cui devono entrare il codice e gli output dei tool, e avvicinano la soglia di compaction; una memoria troppo larga aumenta anche la probabilità che l’agente applichi al modulo sbagliato una convenzione valida altrove. Per questo la documentazione chiede che le custom instructions siano brevi, autoconsistenti e applicabili alla maggior parte delle richieste, dato che viaggiano con ogni messaggio; per il contesto che serve solo a un progetto è più sensato uno Space. Ricorda anche che content exclusion limita ciò che Copilot può leggere ma non copre tutte le superfici, quindi non trattarlo come un lucchetto universale.

Scadenza, potatura, azzeramento

Tieni distinti tre meccanismi che vengono spesso confusi.

  • Scadenza automatica: un fatto o una preferenza che non viene usato viene cancellato dopo un periodo di inutilizzo (la documentazione indica ventotto giorni, ma la funzionalità è in preview: verifica alla fonte). L’uso con validazione riuscita azzera il contatore.
  • Potatura implicita: la validazione rispetto al branch corrente evita che un fatto diventato falso venga applicato.
  • Azzeramento esplicito: cancellazione manuale delle voci di memory; nella CLI /compact, i checkpoint numerati e /resume, o semplicemente una sessione nuova quando cambi compito; nell’SDK deleteSession rimuove i dati dal disco, mentre disconnect libera solo le risorse in memoria e lascia la sessione ripristinabile.

Nella CLI i tre comandi che servono per ispezionare e ridurre il contesto sono:

/context
/compact
/session checkpoints

Due confusioni tipiche, entrambe da evitare all’esame. La prima: l’ambiente del cloud agent è effimero, gira su GitHub Actions e non sopravvive alla sessione, ma la sua scomparsa non cancella nulla di Copilot memory. La seconda: la cronologia locale di sessione che alimenta Chronicle, sotto ~/.copilot/session-state/ più il session store, sincronizzata per default sul tuo account GitHub, è uno storico interrogabile, non un insieme di fatti che l’agente inietta nel prompt.