Cosa sono gli agenti persistenti?

Gli agenti persistenti sono agenti AI che non vengono avviati per svolgere un compito e poi chiusi, ma restano in esecuzione nel tempo: dormono tra un evento e l'altro, si risvegliano da soli seguendo un ritmo interno o a fronte di un segnale esterno e riprendono i loro obiettivi da dove li avevano lasciati. La novità non sta nel modello ma nella dimensione temporale dell'esecuzione: un agente di questo tipo accumula memoria, abilità e conoscenza del proprio ambiente attraverso molti cicli di veglia, invece di ripartire da zero a ogni richiesta. Conviene distinguere tre profili di esecuzione agentica: agenti reattivi, invocati per un singolo compito; agenti programmati, riavviati a scadenze fisse con contesto pulito; agenti continui, che continuano a pensare anche quando nessuno interagisce con loro. È il modello naturale di chi sorveglia una casella di posta, una linea di produzione o un portafoglio di ticket senza pause né turni.

Reattivo, programmato, continuo

All'agent harness spetta il cosa: loop, strumenti e permessi; la persistenza riguarda il quando. Nel profilo reattivo il processo nasce e muore con la richiesta. In quello programmato uno scheduler lo ri-invoca a intervalli fissi con contesto pulito: è la scelta del Ralph Wiggum Loop, il cui progresso vive nei file e nei commit. Il profilo continuo tiene lo stesso processo vivo attraverso i risvegli, e qui il costo cambia natura: Headlong, microharness open source, dichiara 1-2 dollari l'ora per agente e, ancora in versione alpha, avverte di controllare la bolletta prima di scalarlo.

Il monologo interno tra i risvegli

Ciò che distingue un agente continuo da un batch orchestrato si gioca tra un risveglio e l'altro: il processo non si spegne, rielabora ciò che ha osservato, aggiorna il monologo interno e sceglie cosa approfondire al prossimo ciclo. La forma matura è descritta, come classe di vulnerabilità più che come traguardo, dalla ricerca sugli always-on AI agents: un singolo processo persistente che gira sotto l'identità del proprietario e raccoglie in un unico confine di autorità messaggistica, memoria, skill auto-scritte, scheduling e shell. Non serve infrastruttura pesante: il nucleo di Headlong sta sotto le diecimila righe di Bash, e il suo interprete è un recursive language model in versione shell. Stato e sessioni tra due risvegli restano però una questione di runtime, non di modello. Anche i modelli si adeguano: Muse Glimmer di Meta, 30 miliardi di parametri sotto licenza Apache 2.0, è presentato come un modello pensato per agenti always-on in locale su una GPU consumer.

Un esempio enterprise

Una PMI logistica mette in campo un agente persistente sulla casella dei fornitori: legge le conferme d'ordine, incrocia i ritardi con il piano dei carichi e prepara bozze di sollecito in attesa di approvazione umana, giorno e notte. Ma un'esecuzione non presidiata di questo tipo è già stata osservata sul campo: a luglio 2026 Hunt.io ha documentato l'agente autonomo Hermes mentre girava da solo, in modalità YOLO, dentro un'operazione di spionaggio contro il Ministero delle Finanze thailandese. Chi lo commissiona deve stabilire chi può fermarlo e con quali garanzie: la safe interruptibility, formulata da Orseau e Armstrong, studia come impedire che un agente abbia motivo di evitare l'interruzione umana.

Perché conta per chi decide

Un agente invocato per task si ferma quando l'utente se ne dimentica; uno persistente no: la sorveglianza diventa un problema nel tempo, non per singola risposta. Quattro domande meritano risposta prima di approvarne uno: che cosa lo risveglia e con quale frequenza; quanto costa mentre non fa nulla di visibile; dove conserva ciò che impara tra i cicli; chi riceve un allarme quando il suo comportamento va in deriva. L'heartbeat stesso può diventare il controllo: una revisione periodica di budget, permessi e output rende la deriva visibile prima che diventi un incidente.