Un agente personale sempre attivo non dovrebbe comportarsi come un flusso di notifiche con una grammatica migliore. Il suo compito non è reagire in modo visibile a ogni nuova email, segnalazione, variazione di prezzo, modifica a un documento o aggiornamento del calendario. Il suo compito è restare di guardia mentre sei altrove, riconoscere la piccola parte di cambiamenti che modificano ciò che dovrebbe succedere dopo e riportare in primo piano il lavoro giusto, al momento giusto e al livello giusto.
Per questo «quando dovrebbe svegliarsi l’agente?» è una questione di progettazione, non solo di prestazioni. Se si sveglia troppo spesso, l’agente diventa un’altra fonte di rumore. Se resta in silenzio con troppa ostinazione, si perde proprio il motivo per cui gli hai chiesto di sorvegliare. Se agisce senza un confine chiaro, un utile sistema in background diventa un problema di autorità.
La risposta giusta è una sequenza di decisioni. Un nuovo evento può non meritare alcuna risposta, una revisione successiva, un passaggio dell’agente principale o il tuo giudizio diretto. Sono esiti diversi, e un agente affidabile non dovrebbe ridurli a uno solo.
Sempre attivo dovrebbe voler dire continuità, non interruzione
«Sempre attivo» ha valore perché il mondo non si organizza in sessioni di chat. Una pull request può fallire dopo che hai chiuso il portatile. Un fornitore può cambiare una data di consegna mentre sei in riunione. Un contratto può essere firmato tre giorni dopo l’ultima volta che ne avete parlato. Se deve farsi carico di una responsabilità che prosegue, l’agente ha bisogno di continuità attraverso questi vuoti.
La continuità non richiede di ragionare senza sosta. La maggior parte degli eventi sono duplicati, conferme di routine, modifiche irrilevanti o informazioni che saranno utili anche più tardi. Svegliare un grande modello per ogni evento spreca potenza di calcolo, ma il costo maggiore riguarda il comportamento: se ogni risveglio diventa un messaggio, l’agente spende l’attenzione dell’utente come se fosse gratuita.
La ricerca sulle notifiche sul lavoro ha trovato da tempo la stessa tensione. Le persone apprezzano restare informate in modo passivo, ma le notifiche disturbano l’attività su cui sono concentrate. Anche la ricerca sul rinvio limitato mostra perché «adesso o mai» è la scelta sbagliata: un avviso può essere ritardato entro un limite noto, così l’informazione si conserva senza trattare ogni arrivo come urgente.
Un agente sempre attivo dovrebbe quindi tenere separati tre orologi:
il momento in cui arriva un evento;
il momento in cui l’agente deve ragionarci sopra;
il momento in cui l’utente deve saperlo o decidere.
A volte tutti e tre coincidono con adesso. Di solito no.
Un risveglio non è una notifica, e una notifica non è un permesso
Il confine più importante è facile da non vedere. Rilevare un evento, svegliare l’agente principale, avvisare l’utente e compiere un’azione esterna sono quattro passaggi distinti.
Supponiamo che Comma stia seguendo una pull request. Arriva un nuovo commento di revisione. Il processo di sorveglianza può prima stabilire se il commento cambia qualcosa di rilevante. Se sì, l’agente principale può svegliarsi ed esaminare la pull request, la discussione intorno e l’attività a cui appartiene. L’agente potrebbe aggiornare una bozza o preparare una correzione senza interromperti. Potrebbe doverti dire che la finestra per il merge è a rischio. Oppure potrebbe arrivare a una decisione, come accettare un compromesso sulla sicurezza, che spetta a te.
Nessuna di queste conclusioni discende dal solo arrivo del commento.
L’architettura di Comma è pensata per funzionare secondo questa separazione. Un Loop leggero resta di guardia e sveglia l’agente principale solo quando serve; poi è l’agente principale a fare il lavoro che richiede contesto. I dettagli tecnici, compreso il modo in cui i Loop filtrano gli eventi, eliminano i risvegli doppi e funzionano entro quote, sono descritti in Event loop programmabili per il nostro harness distribuito per agenti. Il principio per chi legge è più semplice: un evento è un indizio, non un’istruzione, e un risveglio è una richiesta di indagare, non un permesso di agire.
I quattro test per svegliare l’agente principale
Una buona regola di risveglio si può esprimere in quattro test. Non sono una scheda di punteggio in cui un totale alto vince automaticamente. Ogni test elimina un tipo diverso di falso allarme.
1. È cambiato qualcosa di sostanziale?
Il primo test riguarda lo stato, non l’attività. Un nuovo messaggio è attività. Una scadenza che si avvicina, un ostacolo che compare, un’approvazione che arriva o una condizione promessa che si avvera sono cambiamenti di stato.
L’agente dovrebbe restare in silenzio quando il nuovo evento ripete ciò che sa già, conferma la ricezione di un messaggio senza cambiare il piano o esce dalla responsabilità che gli è stato chiesto di sorvegliare. Identificatori stabili e deduplicazione aiutano a livello di sistema, ma la ripetizione semantica richiede comunque giudizio: due messaggi diversi possono comunicare lo stesso «non è cambiato nulla».
Questo test impedisce che il movimento si spacci per progresso.
2. Il cambiamento tocca un obiettivo o un vincolo attivo?
Ciò che è sostanziale dipende dalla persona. Un calo del prezzo di un volo non è importante di per sé; conta se scende sotto il budget che l’utente ha fissato per un viaggio che intende ancora fare. Una build fallita conta in modo diverso su un branch abbandonato, su un branch esplorativo e su una release candidate.
L’agente ha bisogno dell’obiettivo, del piano attuale, dei vincoli pertinenti e di abbastanza informazioni sulla provenienza da sapere da dove vengono quei fatti. Senza questo contesto, «importante» tende a voler dire vistoso in generale invece che utile nello specifico.
È anche qui che l’ambito protegge la fiducia. Un Loop che segue un repository non dovrebbe trasformare un riferimento di passaggio a un altro progetto in un nuovo incarico. Il contenuto in arrivo può informare la responsabilità sorvegliata; non può allargarla di nascosto.
3. C’è una finestra per agire?
Alcuni cambiamenti contano ma non richiedono di ragionare subito. Un report che verrà rivisto venerdì può aspettare in un riepilogo. Una spedizione in ritardo può diventare rilevante solo se minaccia un evento che ne dipende. Al contrario, una riunione annullata che libera una finestra di prenotazione rara, o una regressione in produzione che si estende a sempre più utenti, può perdere valore a ogni minuto di ritardo.
La domanda non è semplicemente «è urgente?». È: ragionare adesso creerebbe un’opzione migliore che ragionare più tardi?
Se sì, sveglia l’agente principale. Se l’informazione resterà ugualmente utile per agire, rimandala a un punto di controllo naturale o raggruppala con aggiornamenti correlati. Se non è possibile alcuna azione e nessun piano cambia, registrala e resta in silenzio.
4. A chi spetta la prossima decisione?
Dopo aver raccolto il contesto, l’agente principale dovrebbe stabilire chi ha l’autorità sul passo successivo.
Il lavoro di routine e reversibile entro le istruzioni dell’utente può spesso proseguire senza interruzioni. L’agente può aggiornare le note dell’attività, preparare un confronto o scrivere la bozza di una risposta. Una decisione con conseguenze, ambigua o legata alle preferenze dovrebbe tornare all’utente. In Comma, il lavoro che ha bisogno di una decisione umana può aspettare in Da rivedere invece di essere risolto tirando a indovinare o segnato come completato.
Una buona escalation è precisa. Dovrebbe dire cosa è cambiato, perché questo cambia il piano, cosa ha già verificato l’agente, quale decisione serve e quando quella decisione smette di essere utile. «Cosa vuoi fare?» non è un passaggio di consegne; è un’analisi non finita.
Quattro esiti legittimi, non solo sveglio o addormentato
Applicati i test, l’agente ha quattro risposte utili.
Restare in silenzio. Non è cambiato nulla di rilevante, l’evento è un duplicato o esce dall’ambito della sorveglianza. Il silenzio dovrebbe essere una conclusione deliberata, con abbastanza tracce interne per diagnosticare gli errori, e non l’assenza di elaborazione.
Rimandare o raggruppare. Il cambiamento è rilevante, ma il suo valore sopravvive a un ritardo. Aggiungilo al prossimo punto di controllo dell’attività, a un briefing o a un riepilogo compatto. Il rinvio ha bisogno di un limite: «più tardi» dovrebbe indicare un momento o una condizione noti, non un arretrato senza responsabile.
Svegliare l’agente principale. L’evento potrebbe cambiare il piano, richiede un contesto più ampio o è troppo incerto per il filtro leggero. Svegliarlo è appropriato anche quando l’esito finale è il silenzio; l’agente principale può indagare e concludere che non serve alcun messaggio per l’utente.
Restituire il controllo all’utente. L’agente è arrivato a una decisione che coinvolge autorità, rischio, gusto o un compromesso che solo l’utente può fare. Dovrebbe conservare il lavoro già svolto e presentare la decisione più piccola che sblocca l’avanzamento.
Questo modello a quattro esiti rende gestibile l’incertezza. Un processo di sorveglianza non deve fingere sicurezza quando le prove sono deboli. Può svegliare l’agente principale per una verifica più approfondita. L’agente principale, a sua volta, non deve inventarsi un’autonomia quando una decisione spetta all’utente.
La fiducia dovrebbe cambiare il percorso, non nascondere l’evento
Un sistema sempre attivo a volte sbaglierà. Il guasto pericoloso non è solo un falso allarme; è un evento scartato con sicurezza che l’utente non ha mai l’occasione di recuperare.
L’impostazione predefinita di Comma riflette questa asimmetria. Quando i Loop usano Jev per esaminare una pull request, una segnalazione o un thread seguiti, «restare in silenzio» richiede un’alta confidenza. Incertezza ed errori passano all’agente principale, che ha l’istruzione di verificare la fonte prima di scrivere all’utente. Jev può classificare; non può inviare messaggi, cambiare lo stato esterno né concedersi più accesso. Il comportamento e i limiti attuali sono documentati in Ecco Salix, l'harness per agenti di Comma e nella documentazione dei Loop.
Questo design non elimina gli errori. Una decisione di silenzio sbagliata ma presa con sicurezza può ancora nascondere un aggiornamento. Però mette l’incertezza sul percorso più sicuro: un’ispezione più approfondita invece di uno scarto silenzioso. Gli utenti dovrebbero anche poter mettere in pausa o eliminare una sorveglianza, restringerne l’ambito e riprendersi l’accesso operativo. Un agente si guadagna il diritto di essere presente in background rendendo quella presenza verificabile e reversibile.
Una buona interruzione arriva con il lavoro già fatto
Il valore di un agente personale sempre attivo non sta nell’accorgersi delle cose prima di te. Gli strumenti di monitoraggio lo fanno già. Il valore sta nel collegare il cambiamento a una responsabilità attiva e nel ridurre il lavoro che resta a te.
Nella sostanza, un’interruzione utile potrebbe suonare così:
Il revisore ha chiesto una modifica al flusso di autenticazione. Blocca il criterio di rilascio che hai fissato per giovedì. Ho controllato il branch attuale e ho riprodotto il problema. Ho preparato una patch e i test; approvare il compromesso sulla compatibilità è l’unica decisione che mi serve da te prima di applicarla.
Questo messaggio porta contesto, conseguenze, l’indagine già fatta, un passo successivo proposto e un confine decisionale chiaro. Non chiede all’utente di ricostruire perché l’evento conta. E non confonde un’azione successiva plausibile con l’autorizzazione a compierla.
Lo stesso criterio vale quando l’agente sceglie di non interrompere. Un aggiornamento rimandato dovrebbe ricomparire al punto di controllo promesso. Una decisione di silenzio dovrebbe restare verificabile. Un’attività che richiede giudizio dovrebbe aspettare in modo visibile, non sparire dentro una conversazione senza fine.
L’obiettivo è una continuità tranquilla
Un agente sempre attivo dovrebbe creare continuità senza pretendere attenzione continua. Il sistema esterno sorveglia a basso costo e in un ambito ristretto. L’agente principale si sveglia quando un cambiamento può alterare il piano. Indaga prima di interrompere. Prosegue il lavoro di routine e reversibile quando l’utente gli ha già dato l’autorità, e restituisce le scelte con conseguenze insieme al lavoro pertinente.
L’esperienza che ne risulta non è quella di un agente che parla di più. È quella di un agente che può restare responsabile pur rimanendo in silenzio, e che sa esattamente quando il silenzio non serve più.
Domande frequenti
Cosa gira prima che l’agente principale si svegli?
In Comma, un Loop leggero sorveglia la casella di posta, il repository, il feed, l’API o il webhook scelti. Il suo programma può applicare regole deterministiche e chiedere a Jev una decisione tipizzata e veloce. L’agente principale e il suo contesto più ampio entrano in funzione solo quando il Loop invia un risveglio per un’indagine o un’azione più approfondita.
Ogni risveglio dell’agente dovrebbe diventare una notifica per l’utente?
No. Un risveglio permette all’agente principale di esaminare il contesto e decidere cosa cambia l’evento. Può proseguire il lavoro in background, rimandare un aggiornamento o concludere che non serve interrompere l’utente. L’attenzione dell’utente dovrebbe essere richiesta solo quando l’informazione o la decisione è urgente.
Cosa dovrebbe succedere quando l’agente non è sicuro?
L’incertezza dovrebbe spostare l’evento verso chi può decidere meglio. Un filtro leggero può svegliare l’agente principale; l’agente principale può verificare la fonte, raccogliere il contesto e procedere entro la propria autorità oppure chiedere all’utente. L’incertezza non dovrebbe trasformarsi in una decisione di silenzio presa con sicurezza né in un’azione non autorizzata.
Come può un utente fermare una sorveglianza sempre attiva?
Comma permette di chiedergli di mettere in pausa o eliminare un Loop. Anche l’accesso ai computer collegati può tornare in sola lettura disattivando le operazioni. Una responsabilità sempre attiva dovrebbe avere sempre un ambito comprensibile, uno stato visibile e un interruttore di spegnimento concreto.
Trasforma un segnale in un passo successivo utile
Parti da una sola fonte di eventi e annota cosa cambierebbe davvero il tuo piano, per quanto tempo resta aperta la finestra per agire e quale decisione deve restare tua. Esplora l’Agent di Comma per vedere come l’attenzione proattiva si collega alle attività e alla revisione, oppure leggi la documentazione dei Loop per conoscere il modello di monitoraggio attuale e i suoi limiti.
