Un agente che ricorda incollando l'intera cronologia nel prompt successivo non ha memoria. Ha una bolletta crescente, un tetto rigido di token, e una curva di latenza che peggiora a ogni turno. La vera memoria è una decisione di storage: cosa persisti, dove lo metti, e come recuperi solo la fetta rilevante al momento dell'inferenza. Questo è un problema di database, e trattarlo come un problema di prompt è il motivo per cui gli agenti che fanno bella figura in demo crollano alla seconda settimana.

La cosa seducente del riempire il contesto è che all'inizio funziona. All'inizio di una sessione la cronologia è breve, tutto entra, e l'agente sembra ricordare. Poi la conversazione cresce, il prompt cresce con essa, e succedono tre cose insieme: il costo sale perché reinvii tutto a ogni turno, la latenza sale perché il modello legge di più ogni volta, e alla fine raggiungi il limite della finestra di contesto e i fatti più vecchi cadono silenziosamente dall'inizio. Il guasto non è un bug che si può correggere con una patch. È l'architettura.

Due tipi di memoria, due tipi di storage

"Memoria" è in realtà due esigenze diverse, e confonderle è dove i progetti vanno storti.

Memoria di sessione e di lavoro: uno store chiave-valore

I turni recenti, lo stato attuale del task, le preferenze a breve termine dell'utente, questi si cercano tramite una chiave nota: un session ID, uno user ID, un thread ID. Vuoi letture e scritture veloci su quella chiave e un time-to-live così che le sessioni scadute si esauriscano da sole. Questa è una tabella DynamoDB, non una ricerca vettoriale. Partiziona per sessione o utente, mantieni lo stato corrente come un item, imposta un TTL, e rileggilo all'inizio di ogni turno. Nessun embedding, nessuna similarità, solo un lookup veloce con chiave di "dove eravamo rimasti".

Memoria semantica a lungo termine: uno store vettoriale

I fatti che un agente dovrebbe ricordare tra le sessioni, decisioni precedenti, preferenze apprese, scambi passati rilevanti, non si cercano per chiave. Si cercano per significato: "cosa so che è rilevante per questo nuovo messaggio". Questa è una ricerca semantica su embedding, che è a cosa serve uno store vettoriale. Su AWS la scelta pragmatica è Aurora Serverless v2 con pgvector: i tuoi embedding vivono accanto ai dati relazionali, li interroghi con SQL, e non devi far girare un database separato e specializzato solo per questo.

Il pattern: recupera, non accumulare

Una volta che la memoria è un database, ogni turno smette di appendere e inizia a interrogare. Il ciclo diventa:

on each turn:
  1. read session state by key      (DynamoDB: where were we)
  2. embed the new user message
  3. semantic search long-term store (pgvector: what is relevant)
  4. assemble a bounded prompt:
       system + tools
       + top-k retrieved memories
       + recent turns from session state
       + new message
  5. call the model
  6. write new facts back to the stores

Il prompt ora è limitato indipendentemente da quanto duri la relazione con l'utente. Una conversazione al millesimo turno invia un prompt della stessa dimensione del decimo, perché recuperi la manciata rilevante di memorie invece di portarle tutte. Costo e latenza restano piatti invece di salire. È la stessa disciplina di retrieval che fa funzionare il RAG, applicata alla cronologia dell'agente stesso invece che a un corpus di documenti.

Cosa devi decidere, che un prompt nasconde

Spostare la memoria in un database forza scelte che il riempimento del contesto ti lasciava ignorare, e quelle scelte sono l'ingegneria vera:

  • Cosa vale la pena ricordare. Non ogni turno è una memoria. Scrivi fatti e decisioni durature, non chiacchiere, altrimenti il tuo store si riempie di rumore che il retrieval poi porta a galla.
  • Quando dimenticare. TTL sullo stato di sessione, e una policy per far invecchiare o sostituire i fatti a lungo termine, così una vecchia preferenza non prevale su una corretta.
  • Quanto recuperare. Top-k è una manopola. Troppo poco e l'agente dimentica; troppo e sei di nuovo a un prompt gonfio in cui il passo di retrieval non aggiunge valore.
  • Coerenza tra i due store. Memoria di sessione e memoria semantica possono essere in disaccordo. Decidi chi vince quando succede.

Il punto chiave

Riempire il contesto non è memoria, è rimandare una decisione di storage finché la bolletta dei token e il tetto del contesto non la prendono al posto tuo. Dividi il problema: stato di sessione veloce con chiave in DynamoDB, richiamo semantico a lungo termine in pgvector su Aurora, e un passo di retrieval per turno che assembla un prompt limitato da entrambi. Nel momento in cui la memoria diventa un database con un passo di retrieval invece di un prompt in eterna crescita, costo e latenza smettono di scalare con la lunghezza della conversazione, e sei tu a decidere cosa ricorda l'agente invece di lasciare che sia la finestra a decidere cosa dimentica.

Da leggere ora

Per il lato database e infrastruttura del far girare Aurora e DynamoDB su scala, le note di campo sul cloud sono su ercan.cloud, e l'hub è su ercanermis.com.