Kiro Memory: cosa ricorda l'agente tra una sessione e l'altra e come si attiva

Kiro Memory è la funzione di Kiro IDE 1.4.0, uscita il 19 ottobre 2026, che permette all'agente di tenere a mente tra una sessione di chat e la successiva i comandi del repository, le correzioni ricevute e le preferenze di lavoro. Ne beneficia chi usa Kiro ogni giorno sugli stessi progetti e si trova a ripetere ogni volta le stesse istruzioni. Il punto da sapere subito è che la funzione è spenta: il 20 ottobre la 1.4.10 ha reso Off il valore predefinito dell'impostazione, quindi nessuna memoria si forma finché non la accendi.

Cosa salva Kiro Memory, e dove

Il changelog della 1.4 la descrive come un modo per conservare il contesto utile da una sessione all'altra: convenzioni del repository, correzioni, approcci già scartati. La documentazione precisa che una memoria non è la copia di una conversazione passata. È un record con titolo, descrizione e contenuto, che l'agente crea o aggiorna quando riconosce un'informazione riutilizzabile e che può richiamare più tardi quando è pertinente al lavoro in corso.

L'esempio che fa la documentazione è concreto. Kiro scopre che i test di integrazione falliscono finché il database locale non è popolato. In una sessione successiva ritrova quella memoria e popola il database prima di lanciare i test, senza che tu glielo ripeta.

Un dettaglio che cambia la gestione: le memorie sono salvate in locale per account utente, non per workspace. Non stanno nel repository, quindi non finiscono in un commit e non le vede il resto del team. Kiro IDE e Kiro CLI sulla stessa macchina condividono le memorie salvate, ma ogni applicazione ha la propria impostazione Memory. Accendere la funzione nell'IDE non la accende nella CLI. Le note che ho letto non spiegano come si configuri nella CLI, quindi qui parlo solo dell'IDE.

Come si attiva e le quattro modalità

L'impostazione si chiama Kiro Agent: Memory ed è un'impostazione utente: un valore messo nelle impostazioni del workspace non ha effetto. Questo evita che un repository clonato da fuori decida al posto tuo se l'agente debba imparare qualcosa. Le modalità sono quattro.

Accendere o spegnere Memory, o passare da e verso Use only, vale per le nuove sessioni. Il passaggio fra i due livelli di apprendimento ha effetto subito nelle sessioni locali già aperte. Se parti da zero, la scelta prudente è Use but don't learn: l'agente sfrutta quello che c'è e non scrive nulla senza una tua richiesta. Use and learn lo accendi quando hai visto per qualche giorno che cosa Kiro considera degno di nota.

C'è poi un vincolo di sicurezza che conta. In un workspace non attendibile Kiro può leggere le memorie ma non può aggiungerne, cambiarle o cancellarle da chat, anche con un livello di apprendimento selezionato. Una cartella scaricata da internet non può quindi usarti l'agente per scrivere istruzioni nella tua memoria locale.

Come si controlla e si cancella quello che ha imparato

Una memoria che non si può guardare è un rischio, e qui Kiro fa il minimo indispensabile bene. L'icona Memories nella barra delle attività apre una vista con le memorie globali e quelle dei repository aperti. Ognuna ha un tipo, Preference, Fact oppure Other, e una posizione, Global oppure il nome del repository. Puoi cercare per titolo o riassunto, filtrare per tipo e posizione, aprire una voce per leggerne contenuto e riassunto.

Per cancellare basta il clic destro sulla voce o la sua scheda, con conferma. La cancellazione funziona anche in Use only. Per cambiare il contenuto, invece, devi chiederlo a Kiro in chat, e servono un livello di apprendimento e un workspace attendibile.

Durante una sessione la chat mostra voci comprimibili come "Memory accessed (1)", "Memory created (1)" e "Memory updated (1)". Se le memorie occupano contesto, l'indicatore Context Usage nel campo di input aggiunge una riga Memory. Sono due segnali utili: ti dicono quando un comportamento dell'agente nasce da qualcosa che ha ricordato e non da quello che hai scritto nel prompt.

Memory o Steering: dove metto cosa

La documentazione è netta: Memory aggiunge contesto appreso e non sostituisce la conversazione, lo Steering o i materiali di riferimento. Se una regola deve valere sempre, va scritta nello Steering. È lo stesso ragionamento che vale per un file di istruzioni come CLAUDE.md: quello che è una regola del progetto sta in un file che il team legge e versiona, quello che è un'osservazione emersa lavorando può stare in una memoria. Ne parlo in quattro regole per far sbagliare meno un agente di coding, e per l'equivalente di Claude Code, che scrive note da sola fuori dal repository, c'è la memoria di Claude Code. Per il quadro generale su cosa mettere in una memoria e dove tenerla serve la memoria di un agente AI.

La mia opinione è che il valore sta nell'ispezionabilità, più che nell'apprendimento in sé. Un agente che impara di nascosto è un agente le cui scelte non riesci a spiegare. Qui la memoria ha un elenco, un tipo, una posizione e un cancella, e questo la rende gestibile. Il rovescio è che resta locale e personale: una convenzione che l'agente ha imparato da te non arriva al collega, e se è importante va promossa allo Steering a mano.

Cosa resta fuori dalle fonti

Le note di rilascio e la documentazione che ho letto non indicano piani, prezzi o limiti di quantità per le memorie. Non spiegano nemmeno perché il valore predefinito sia stato portato a Off nella 1.4.10, e non descrivono le impostazioni della CLI. Sono informazioni che non posso darti: prima di affidare a Kiro Memory un progetto con vincoli di riservatezza, verifica nella documentazione corrente.

La cosa da fare oggi è breve. Apri le impostazioni utente, cerca Kiro Agent: Memory e scegli Use but don't learn. Poi lavora normalmente per un paio di giorni, apri l'icona Memories e leggi quello che c'è. Ogni voce che ti sembra una regola vera del progetto spostala nello Steering, e cancella le altre.