Costruire un assistente AI che ricorda, spiega e chiede permesso
Le decisioni dietro Yarta, un assistente personale self-hosted progettato intorno a memoria, provenienza e controllo delle azioni.
Molti assistenti AI iniziano dalla stessa superficie: una casella di testo, una cronologia e un modello che risponde. Io volevo capire cosa succede dopo la chat.
Cosa deve ricordare un sistema personale? Come distingue un fatto duraturo da una frase detta per caso? Può usare lo stesso contesto dal web, da Telegram e dal terminale senza costruire tre identità diverse? E soprattutto: quando può agire da solo?
Yarta è il laboratorio con cui sto rendendo concrete queste domande. Non è un chatbot generico e non è un SaaS multiutente. È un assistente single-owner, self-hosted, con un solo cervello e più interfacce sottili intorno.
Il problema non era generare una risposta
Collegare un modello a una chat è la parte visibile, ma non la più interessante. Un assistente che accompagna il lavoro nel tempo deve affrontare almeno quattro problemi distinti:
- continuità — ricordare ciò che conta oltre la singola conversazione;
- provenienza — sapere da dove arriva ogni informazione;
- controllo — separare ciò che può osservare da ciò che può modificare;
- spiegabilità — rendere ispezionabile il percorso tra evento, memoria e azione.
Senza queste proprietà, una memoria lunga diventa soltanto una cronologia opaca. Un’automazione potente diventa invece un rischio difficile da diagnosticare.
Un cervello, molte superfici
L’architettura attuale usa PostgreSQL e pgvector come memoria canonica. Intorno a questo nucleo esistono più punti di accesso, ciascuno pensato per un contesto differente.
| Superficie | Ruolo |
|---|---|
| Web app | Chat, revisione della memoria, progetti, approvazioni e osservabilità |
| Telegram | Conversazioni rapide e notifiche dove sono già presente |
| CLI | Interazione diretta da terminale e flussi per lo sviluppo |
| Worker | Lavori asincroni, retry e attività che non devono vivere nel ciclo di una richiesta |
Le interfacce non possiedono memorie indipendenti. Producono eventi e attraversano lo stesso core. Questo evita che l’assistente impari una versione di me su Telegram e ne mostri un’altra sul web.
Memoria naturale, non accumulo indiscriminato
Una conversazione contiene fatti, intenzioni momentanee, ipotesi, preferenze e rumore. Salvare tutto allo stesso livello rende il recupero peggiore, non migliore.
La prima versione di Yarta estrae memoria automaticamente e la rende consultabile. Ogni elemento può mantenere contesto, sensibilità, relazione con un progetto e traccia della sua origine. Dalla console posso cercarlo, correggerlo o eliminarlo.
La direzione successiva è una pipeline più simile a un ciclo di consolidamento:
eventi → episodi → fatti → pattern
↓ ↓
compressione revisione
Gli eventi sono ciò che accade. Gli episodi raggruppano una sequenza dotata di senso. I fatti rappresentano informazioni più stabili. I pattern emergono solo quando esiste abbastanza evidenza per non confondere una coincidenza con un’abitudine.
Chiamo questa fase dream cycle: un processo asincrono che consolida, comprime, indicizza e, quando necessario, pota la memoria. È una direzione architetturale, non una scusa antropomorfa. Serve a separare l’acquisizione immediata dalla decisione su cosa meriti di restare.
Imparare e agire sono due permessi diversi
Per un assistente personale è ragionevole raccogliere contesto utile durante una conversazione. Non è ragionevole trasformare ogni frase in un’azione esterna.
Yarta tratta gli effetti sul mondo come un confine esplicito. Una sessione riceve capability precise; le azioni sensibili richiedono policy o approvazione; il worker conserva lo stato delle richieste che non possono essere risolte immediatamente.
Questo permette di evitare due estremi:
- un sistema bloccato da una conferma dopo ogni messaggio;
- un agente che interpreta una frase ambigua come autorizzazione permanente.
Il principio è semplice: capire può essere automatico, modificare deve essere autorizzato.
I progetti devono sopravvivere alle chat
Una chat ha un inizio e una fine. Un progetto no: accumula decisioni, documenti, errori, persone e cambi di direzione.
Per questo i progetti stanno diventando oggetti di prima classe, collegati ma non subordinati alle conversazioni. Il loro contesto può essere aggiornato da più superfici e recuperato senza dover ricostruire ogni volta la cronologia completa.
Questa distinzione cambia anche il modo in cui lavoro con gli agenti. Un agente non riceve soltanto “tutta la chat”: riceve il sottoinsieme di memoria, strumenti e capability coerente con il compito.
La velocità ha reso visibile il debito
La prima versione è nata in sedici giorni: nove fasi, ottantatré piani e 386 commit. Quei numeri raccontano un metodo ad alta intensità, sostenuto da agenti per ricerca, implementazione, test e verifica.
La velocità ha prodotto un sistema ampio, ma ha anche mostrato dove una struttura iniziale smette di scalare. Aggiungere funzioni a una pipeline sincrona rende difficile capire perché un evento sia stato elaborato, quale memoria abbia influenzato la risposta e dove si sia verificato un errore.
Per questo la versione successiva non parte da nuove automazioni. Parte da eventi e osservabilità:
- ogni superficie produce eventi con un’identità chiara;
- l’elaborazione asincrona può essere ripetuta e ispezionata;
- modello, costo, latenza ed errore diventano parte della traccia;
- memoria e azioni mantengono una catena causale leggibile.
L’orchestrazione operativa arriva dopo. Prima devo poter spiegare cosa è successo.
Cosa sto imparando davvero
Costruire Yarta mi ha insegnato che l’AI engineering non coincide con la scelta del modello. È progettazione di stato, permessi, code, fallback, valutazione e interfacce per correggere il sistema quando sbaglia.
Le domande più importanti restano aperte:
- quando un ricordo smette di essere utile?
- quanta iniziativa è desiderabile prima che l’assistente diventi invadente?
- come si misura la qualità della memoria senza premiare soltanto la quantità?
- quale spiegazione basta a fidarsi di un’azione proposta?
Yarta non pretende di essere la risposta definitiva. È un ambiente sotto il mio controllo in cui queste domande lasciano tracce, possono essere misurate e, soprattutto, possono essere corrette.