Capitolo 6 — Memoria, stato e human-in-the-loop: l'agente che vive nel tempo
Gli agenti visti finora nascono e muoiono in una sessione. Ma i sistemi utili vivono nel tempo: ricordano, riprendono, e sanno quando fermarsi a chiedere. Tre problemi, tre discipline.
La memoria. Il contesto è volatile: a fine sessione, tutto sparito. Perché l'agente "ricordi" — le tue preferenze, le decisioni prese, lo stato dei progetti — serve memoria esterna: file di note che l'agente legge e aggiorna, un database, riassunti progressivi delle sessioni passate. E la domanda di design non è "come memorizzare tutto" ma "cosa merita di essere ricordato": una memoria che accumula indiscriminatamente diventa rumore — è il context rot su scala biografica. (Se ci pensi: recuperare il ricordo giusto al momento giusto è di nuovo un problema da Livello 3.)
Lo stato. Un workflow di venti minuti che muore al minuto diciotto per un errore di rete deve poter riprendere, non ricominciare. Quindi lo stato — a che punto siamo, cosa è fatto, cosa manca — vive fuori dal modello: checkpoint su file o database dopo ogni passo compiuto. È la differenza tra un processo affidabile e una roulette.
Lo human-in-the-loop. La domanda non è filosofica, è progettuale: in quali punti esatti serve un umano? Il pattern fondamentale: l'agente propone, l'umano approva, l'agente esegue. E c'è una riga rossa non negoziabile: le azioni irreversibili — inviare email, cancellare dati, muovere denaro — passano da un'approvazione umana, sempre. Il punto di conferma si progetta nel flusso fin dall'inizio; aggiungerlo dopo il primo incidente è il modo costoso di impararlo.
L'esperimento del giorno. Prendi il tuo workflow migliore e rendilo adulto: checkpoint di stato su file dopo ogni passo (e prova davvero a ucciderlo a metà e riprenderlo), più un punto di approvazione prima dell'azione finale. Poi completa il progetto del livello: il tuo server MCP su uno strumento vero, e un workflow multi-step che lo usa — con verifiche, approvazione umana e log completo.