Come Talorys esegue agenti AI stateful su serverless

Ecco la mia tesi controcorrente, e la difendo: un agente AI personale è un adattamento migliore per l'infrastruttura serverless che per il Raspberry Pi sotto la scrivania. Il progetto Talorys — un assistente personale open source che si installa nel tuo account Cloudflare con un singolo npx create-talorys@latest — è la prova più convincente finora che il problema dell'agente AI stateful su serverless stateless non solo è risolvibile, ma è un abbinamento naturale. E la community di Hacker News che discute se si possa definire "self-hosted" sta sbagliando argomento del tutto.

Ho passato anni a gestire infrastrutture e a ripulire i danni che lasciavano. Quello che uccide il software personale self-hosted non è il deploy, ma il terzo mese, quando il disco si riempie di log, il certificato TLS scade e non ti ricordi quale unit di systemd gestisce la pianificazione. Talorys aggira l'intera classe di guasti non avendo affatto un server. Tutto ciò che serve — chat, memoria, attività, promemoria programmati — gira sul piano gratuito di Cloudflare: Pages per il frontend, un Worker privato per le API, un Durable Object basato su SQLite per tutto lo stato e Workers AI per il modello. Costo mensile totale per un singolo utente: zero.

Il vero problema: gli agenti sono stateful, il serverless no

Un agente AI è un insieme di stato a lunga durata che finge di essere un'applicazione request-response. Ha bisogno della cronologia delle conversazioni, di memorie durature, di una lista di attività, di job pianificati che partono alle 7 del mattino che qualcuno sia connesso o meno, e di un posto dove mettere l'output degli strumenti mentre una catena in più passaggi è in esecuzione. Ogni pezzo di questo è ostile al modello serverless classico, dove la tua funzione è un pesce rosso: si sveglia, gestisce una richiesta e dimentica tutto.

La risposta standard dell'industria è ricostruire lo stato ai margini: Redis per i dati di sessione, Postgres per i record durevoli, una coda più uno scheduler per i cron, un database vettoriale per il richiamo semantico. Funziona, ma così hai ricostruito una server farm con servizi gestiti, con la relativa bolletta e la stessa superficie operativa. Ho visto team spendere più tempo di ingegneria a far collaborare cinque servizi stateful per un agente che a scrivere la logica dell'agente stessa. Come ho già sostenuto, gli agenti LLM sono semplicemente sistemi distribuiti — e i sistemi distribuiti sono il posto dove le buone intenzioni vanno a morire.

Talorys fa la scommessa opposta: mettere tutto lo stato in un unico posto. Un Durable Object, chiamato personal-agent, contiene l'intero mondo — conversazioni, memorie, attività, note, progetti, automazioni, sessioni, impostazioni e tracciamento dell'utilizzo — nel suo database SQLite incorporato. Nessun KV, nessun D1, nessun R2, nessun Vectorize. Il README è esplicito: nessuno di questi viene provisionato. Non è un caso, è l'architettura.

I Durable Object sono il trucco segreto

I Durable Object sono la primitiva più silenziosamente radicale del cloud computing oggi, e non è un'esagerazione. Un Durable Object è un pezzo di codice a istanza singola con storage transazionale e fortemente consistente, fisicamente colocato con esso. Quando arriva una richiesta indirizzata all'oggetto personal-agent, Cloudflare risveglia quell'oggetto — in millisecondi, anche da freddo — esegue il tuo codice sul suo SQLite locale e lo rimette in pausa quando diventa inattivo. Ottieni l'ergonomia di un processo server di lunga durata con il modello di fatturazione di una Lambda.

Per un agente personale single-user, le famigerate limitazioni di questo modello diventano punti di forza:

• Un solo scrittore è una funzionalità. Un utente significa un solo scrittore. Tutto l'incubo della concorrenza dello stato multi-tenant scompare; ottieni accesso serializzato e transazionale a tutto, gratis.
• La colocazione elimina la latenza. Le query di memoria dell'agente, le ricerche di attività e la cronologia delle conversazioni sono letture SQLite su disco locale, non round trip di rete verso un database in un'altra availability zone.
• Gli allarmi sostituiscono il cron. Gli alarm dei Durable Object permettono all'oggetto di programmare i propri risvegli. Promemoria, routine ricorrenti e riepiloghi giornalieri partono senza che nessuna macchina resti accesa: l'oggetto dorme, l'allarme lo sveglia, fa il suo lavoro e torna a dormire.
• L'ibernazione è gratuita. Il tempo di inattività non costa nulla. Un assistente personale inattivo 23 ore al giorno è esattamente il carico per cui è nata la tariffazione serverless.

Questa è l'intuizione che vorrei che più persone cogliessero da questo progetto. Se la tua applicazione è naturalmente single-tenant — uno strumento personale, uno spazio di lavoro per cliente, un coordinatore per dispositivo — il pattern "un Durable Object per tenant" ti dà qualcosa che una volta richiedeva un VPS: un piccolo computer concettualmente sempre in esecuzione, che non costa nulla quando è inattivo e non ha mai bisogno di un sysadmin. La storia della pianificazione da sola vale il prezzo del biglietto. Chiunque abbia gestito una macchina personale con cron sa come va a finire: la macchina si riavvia, il demone cron non torna su e scopri due settimane dopo che i tuoi promemoria si sono fermati in silenzio. Gli allarmi sono una pianificazione gestita dall'infrastruttura, e questo è un pensiero in meno di cui occuparsi.

Il modello di rete è migliore della maggior parte dei setup di produzione

Ecco la parte che mi ha fatto drizzare le orecchie, venendo da un background di sicurezza. Il Worker dell'agente in Talorys è distribuito con workers_dev: false e preview_urls: false. Non ha nessun URL pubblico. Il browser parla solo con un sito *.pages.dev; una Pages Function su /api/* inoltra le richieste al Worker tramite un service binding — il collegamento interno e privato di Cloudflare tra componenti di calcolo nello stesso account. Autenticazione e autorizzazione avvengono nel Worker, non nel frontend.

Pensa a cosa elimina. Nessun endpoint API pubblico da scansionare. Nessuna regola del firewall da configurare male. Nessun reverse proxy da dimenticare di aggiornare. La superficie d'attacco del backend dell'agente è, di fatto, "devi passare dal flusso di autenticazione del frontend". Ho esaminato deployment di produzione in aziende reali — con budget e team di sicurezza — che avevano una postura di rete meno restrittiva di questo side project. Lo schema di incidente più comune che ho visto negli ambienti cloud era un servizio interno "raggiungibile solo internamente" finché un giorno non lo era più, perché qualcuno aveva sbagliato la configurazione di un load balancer. Non puoi sbagliare un service binding fino a renderlo pubblico: l'URL semplicemente non esiste.

Anche l'installer merita una menzione. Calcola localmente l'hash della password del proprietario con PBKDF2-SHA256 e salva solo l'hash come secret di Cloudflare, genera un secret di sessione a 256 bit, assegna nomi univoci alle risorse e poi verifica il deployment in produzione — inclusa la verifica che le richieste non autenticate vengano effettivamente respinte — senza consumare quota di inferenza AI. Un controllo post-deploy che conferma che l'autenticazione nega davvero l'accesso agli utenti non autenticati è il tipo di cosa che ho scritto nei post-mortem degli incidenti. Vederla in un installer con un solo comando è una piacevole sorpresa.

Vivere nel piano gratuito senza raccontarsi bugie

Il piano gratuito è reale, ma è un budget, non un buffet. Cloudflare concede agli account gratuiti un'allocazione giornaliera di Workers AI misurata in "Neuron" — 10.000 al giorno — oltre a quote di richieste e di utilizzo dei Durable Object. Questi numeri sono decisi da Cloudflare e possono cambiare. Talorys gestisce la questione in modo più onesto della maggior parte dei progetti "free tier" che ho visto: quando l'allocazione AI si esaurisce, la chat lo dice chiaramente e riprende dopo il reset giornaliero, mentre attività, note, memorie e promemoria continuano a funzionare perché nessuno di questi ha bisogno del modello.

Le protezioni sono utili da copiare nei tuoi progetti. Talorys include limiti configurabili sui token di output massimi, sui token di contesto massimi (la cronologia più vecchia viene riassunta invece di essere troncata in silenzio), sul numero massimo di chiamate agli strumenti e di passaggi di ragionamento per richiesta, sulle richieste AI massime al giorno e sulle esecuzioni AI pianificate massime al giorno. È una posizione matura. I loop di agenti senza limiti sono il modo in cui ti svegli con una bolletta o con un'interruzione per quota esaurita, e "l'agente ha deciso di chiamare lo strumento 40 volte" è un guasto che ho visto bruciare soldi veri in produzione. Correlato: la scelta del progetto di far sì che promemoria e riepiloghi semplici non usino mai l'AI è esattamente giusta. Se un percorso di codice è deterministico, non instradarlo attraverso un modello probabilistico. È la stessa disciplina dietro il vincolare l'output del modello a decisioni strutturate — usa il modello solo dove serve davvero il giudizio.

Una precisazione tratta dalle esperienze della community: diverse persone segnalano sorprese di fatturazione poco chiare quando si combinano Workers AI con piani Workers a pagamento, con un conteggio dei Neuron che non corrisponde ai limiti documentati e ticket di supporto che non portano a nulla. Non posso verificare i dettagli, ma coincide con uno schema che conosco bene: la fatturazione AI a consumo è confusa ovunque, e "compatibile con il free tier" non vuol dire "impossibile da fatturare". Se lo distribuisci su un piano a pagamento, imposta un avviso di spesa nella dashboard di Cloudflare fin dal primo giorno. Considera l'interfaccia di utilizzo del provider come la fonte di verità, non le stime locali dell'app.

La polemica sul "self-hosted" perde il punto

Ora, la concessione che la mia affermazione iniziale richiede. I commenti più in alto su questo progetto sono una guerra di flame sulla parola "self-hosted", e i pignoli hanno un punto reale: questa cosa dipende interamente da Cloudflare. I tuoi dati vivono nei loro data center, l'inferenza gira sulle loro GPU e se domani cambiano il piano gratuito, anche il tuo assistente cambia. Chiamarlo self-hosting stira la parola oltre il punto di rottura. La lettura benevola — nessuna terza parte oltre a un account Cloudflare che già controlli, nessuna telemetria verso gli sviluppatori, nessun operatore nel mezzo — si descriverebbe meglio come "self-owned" o "self-custodied". Le parole contano, e il progetto riceverebbe meno critiche con termini migliori.

Ma qui i pignoli mi perdono. Il vero modello di minaccia per il software personale non è "i termini di servizio di un'azienda potrebbero cambiare". È l'esfiltrazione dei dati, la telemetria e lo sviluppatore che fallisce e spegne la versione ospitata. Su tutti e tre i fronti Talorys è davvero solido: non c'è nessun codice di analytics o tracciamento, niente chiama casa verso gli autori e non esiste una versione ospitata da chiudere. Inoltre il codice è rilasciato con licenza MIT e, come ha notato un commentatore, puntare le chiamate AI a un server di modelli locale è una piccola patch — l'intero stack gira persino in locale con wrangler dev e un provider AI finto. Se Cloudflare diventasse inaccettabile, la via d'uscita sarebbe breve. Confrontalo con la media delle app "self-hosted" che in realtà sono un file Docker Compose che scarica immagini dal registry di qualcun altro e chiama casa per i controlli di licenza.

Nel thread c'è anche una critica più equa: non ci sono prove che l'assistente sia davvero bravo. Un'interfaccia di chat, il CRUD della memoria, gli embedding e il cron sono ciascuno banali da costruire; l'harness, il prompting, la politica di recupero della memoria e gli schemi degli strumenti sono dove un assistente personale vive o muore, e niente di tutto questo è dimostrato da un diagramma di architettura pulito. Vale per quasi tutti i progetti di questo genere, ed è giusto essere scettici. Valuta Talorys come infrastruttura — un telaio ben progettato — non come un copilota collaudato. Se stai valutando modelli per qualcosa del genere, il nostro articolo su l'esecuzione di LLM sul proprio hardware copre l'altro estremo dello spettro della sovranità.

Cosa dovresti copiare da questo design

Anche se non distribuirai mai Talorys, l'architettura è un riferimento che vale la pena assimilare. Le idee trasferibili:

1. Un oggetto per tenant. Se la tua app è single-user o partizionabile in modo pulito, colloca codice e stato in un unico Durable Object ed elimina il tuo livello di cache, la coda dei messaggi e il connection pooler.
2. Nessun URL pubblico per il backend. I service binding con workers_dev: false sono la vittoria più economica sulla sicurezza nel serverless. Un servizio che non può essere raggiunto non può essere attaccato.
3. Allarmi al posto delle macchine con cron. La pianificazione che vive insieme all'infrastruttura sopravvive a riavvii, redeploy e alle tue dimenticanze.
4. Degradazione consapevole delle quote. Progetta l'app in modo che la dipendenza costosa (il modello) possa fallire o esaurirsi mentre il prodotto principale continua a funzionare. La degradazione dev'essere una funzionalità, non un'interruzione.
5. Migrazioni solo in aggiunta. Il namespace del Durable Object non viene mai ricreato durante un aggiornamento; le migrazioni dello schema vengono eseguite in modo transazionale alla prima richiesta. È così che aggiorni il serverless stateful senza giocare alla roulette dei dati persi.

La lezione più ampia riguarda la direzione del software personale. Per vent'anni la scelta è stata binaria: affidare i propri dati a un'azienda SaaS, oppure diventare un sysadmin part-time. I Durable Object — e le primitive copia che gli altri cloud inevitabilmente lanceranno — aprono una terza strada: software che controlli solo tu, gestito da un'infrastruttura che affitti, con costi nulli su scala personale. Non è self-hosting. Potrebbe essere meglio.