Userbot lancia gli Agenti AI proattivi: trigger e webhook per attivarli

Per anni un chatbot ha voluto dire una cosa sola: tu scrivi, lui risponde. Comodo, ma fondamentalmente passivo. Resta lì, in attesa, e finché nessuno apre la chat non succede niente. La cosa interessante è il momento in cui quell'assistente smette di aspettare e comincia a muoversi da solo. È esattamente la direzione presa da Userbot, piattaforma italiana di conversational AI, di cui noi di Turatti Consulting siamo partner e con cui abbiamo già sviluppato diversi importnati progetti di Agenti AI, che ha portato nei suoi blocchi agentici una famiglia di trigger pensati per far partire un agente quando accade qualcosa di rilevante: arriva un messaggio, l'utente resta in silenzio troppo a lungo, scatta un orario, oppure un altro sistema aziendale bussa alla porta con una chiamata. Il trigger è il componente che decide quando l'agente si sveglia, e cambiare quel "quando" cambia completamente cosa l'agente può fare.

Vale la pena fermarsi su queste novità, perché segnano il passaggio da un chatbot che reagisce a un agente che prende l'iniziativa. In questo articolo guardiamo come funzionano i trigger introdotti da Userbot, perché il webhook è quello che apre le possibilità più concrete per chi vuole collegare l'AI ai propri gestionali, e quali accortezze servono prima di mandare un agente proattivo in produzione senza poi pentirsene.

Quando l'agente decide di muoversi da solo

La differenza tra reattivo e proattivo è tutta nell'innesco. Un agente reattivo è una porta che si apre solo se qualcuno bussa: ottimo per rispondere a domande o smistare richieste, ma fermo finché l'utente non scrive. Un agente proattivo ribalta la logica. Tu definisci la condizione che lo deve attivare, e da quel momento è lui a partire, eseguendo una sequenza di azioni in autonomia. Se questo concetto è ancora sfumato, vale la pena partire dalle basi: abbiamo spiegato altrove cosa sono e come funzionano gli agenti AI e perché stanno cambiando il modo di disegnare i processi.

Tra le novità dei blocchi agentici di Userbot ci sono diverse condizioni di attivazione, e sceglierle bene è già metà del lavoro. C'è il trigger che scatta a ogni messaggio in arrivo, indipendentemente dal contenuto, utile quando serve un controllo o un'azione su ciascun turno di conversazione. C'è il trigger schedulato, che si attiva dopo un periodo di inattività dell'utente, una volta sola oppure ripetendosi: è la leva giusta per recuperare un dialogo che si sta spegnendo o per mandare un promemoria al momento opportuno. Su questo punto la piattaforma ha fissato un paletto preciso che conviene conoscere prima di disegnare il flusso: l'attivazione lato front end vale solo entro dieci minuti dall'ultima interazione e solo se la chat è ancora aperta, mentre lato back end si applica alle sole sessioni attive.

A questi si aggiunge il trigger a ora esatta, che parte in un momento preciso della giornata e che Userbot indica come funzionalità in arrivo, e soprattutto il trigger webhook, di cui parliamo tra poco perché è quello che collega l'agente al resto dell'azienda. Due regole architetturali tengono insieme il tutto, ed entrambe si scoprono spesso troppo tardi. La prima: ogni flusso ammette un solo trigger, e almeno un flusso deve averne uno perché le conversazioni possano nascere. La seconda riguarda il comportamento quando una stessa azione dell'utente accende più trigger insieme: i flussi collegati partono in parallelo, e l'ordine con cui le risposte appaiono in chat non è garantito, perché dipende da quale flusso finisce per primo. Tradotto in pratica, conviene evitare configurazioni in cui un solo gesto attiva più trigger con risposte visibili, se si vuole un comportamento prevedibile.

Il webhook è dove l'AI incontra i tuoi sistemi

Qui le cose si fanno davvero interessanti. Il trigger webhook avvia una conversazione quando riceve una chiamata HTTP da un sistema esterno. In concreto Userbot espone un indirizzo univoco a cui un CRM, un sistema di ticketing o una piattaforma di automazione possono inviare una richiesta POST per far partire l'agente in modo programmatico. Non è più l'utente a dare il via: è un fatto accaduto altrove. Un pagamento che entra fa scattare un messaggio di conferma. Un ticket aperto sul gestionale avvia la presa in carico. Una mail ricevuta innesca un follow-up. È la stessa logica di orchestrazione tra strumenti diversi che descriviamo quando spieghiamo come collegare gli assistenti AI al CRM perché leggano e scrivano dati reali.

Ma la parte che fa la differenza non è l'innesco in sé, è il dato che il webhook si porta dietro. La chiamata in arrivo non accende soltanto il flusso: trasporta un payload, cioè le informazioni che il sistema esterno vuole passare all'agente. Userbot ha reso questo passaggio piuttosto pulito con il mapping delle variabili. Funziona così: si avvia un listener di test, si invia una chiamata POST con i dati racchiusi nella chiave data del corpo JSON, e la piattaforma rileva da sola i campi e popola la mappatura. A quel punto decidi con quale nome ciascun campo sarà disponibile nel resto del flusso, e da lì in avanti l'agente può usarlo ovunque: nelle condizioni, nei prompt, nelle chiamate API, nelle risposte. È il momento in cui l'AI smette di essere generica e comincia a rivolgersi alla persona per nome, a citare l'ordine giusto, a modulare il tono in base a ciò che il sistema esterno le ha raccontato.

Questo è anche il punto in cui un agente passa da gadget a strumento di lavoro. Quando riceve dal CRM il nome del cliente, lo storico dell'ordine e lo stato della pratica, la conversazione nasce già informata, e per chi la riceve la differenza si sente subito. È la stessa dinamica che abbiamo visto all'opera su un progetto reale, dove portare gli agenti AI dentro il flusso commerciale ha prodotto una qualificazione dei lead tre volte più rapida. Un dettaglio che si apprezza in fase di debug: Userbot rende riconoscibili le sessioni nate da un webhook, perché nello storico delle conversazioni adottano un prefisso dedicato invece di quello anonimo, e cliccando sul relativo badge si può ispezionare il payload effettivamente ricevuto, con i valori reali delle variabili. Quando qualcosa non torna, è il primo posto dove guardare.

Le accortezze prima di andare in produzione

Un agente che dialoga con i sistemi aziendali si porta dietro responsabilità che un semplice chatbot non ha, e Userbot ha aggiunto gli strumenti per gestirle. Il primo riguarda la sicurezza dell'indirizzo. Un webhook senza restrizioni è di fatto un endpoint pubblico: chiunque ne entri in possesso, anche per sbaglio attraverso un log condiviso, uno screenshot o una repository, può far partire il flusso, generare sessioni e bruciare crediti. Le difese previste sono due, ognuna per uno scenario diverso. La whitelist per dominio di origine è quella giusta quando la chiamata arriva da codice che gira nel browser, dove l'IP non è prevedibile ma il dominio sì. La whitelist per IP serve invece quando il chiamante è un servizio server-to-server con indirizzi statici noti, come capita con i CRM enterprise e le integrazioni di backend.

C'è poi un passaggio procedurale che sembra banale e invece fa perdere ore a chi lo dimentica: dopo aver salvato la configurazione del webhook bisogna pubblicare il flusso, altrimenti le chiamate in arrivo non attivano nulla. E ogni modifica successiva, al flusso o al mapping delle variabili, richiede una nuova pubblicazione per diventare effettiva. Vale la pena trasformarlo in abitudine, perché è il tipo di errore che non dà messaggi chiari: semplicemente non succede niente. Allo stesso modo, Userbot tiene un registro di audit delle operazioni sensibili, a partire dalla rigenerazione degli URL, con data, ora, utente e azione. È il primo riferimento da consultare quando un'integrazione che funzionava smette di rispondere senza un motivo apparente, perché nella maggior parte dei casi il colpevole è proprio una rigenerazione fatta da un altro membro del team, con il vecchio URL invalidato all'istante.

Resta l'accortezza più sottile, che riprende il discorso dei trigger paralleli: la prevedibilità del comportamento dipende più dalla disciplina con cui disegni i flussi che dalla singola funzionalità. Meglio un flusso che fa una cosa in modo deterministico che tre flussi che si contendono la stessa risposta. Chi imposta questi automatismi con metodo ottiene agenti su cui si può contare; chi li improvvisa ottiene comportamenti difficili da diagnosticare, e finisce per accumulare debito tecnico invece di automatizzare davvero. Per questo la fase di disegno conta più di quella di configurazione, e il punto di partenza non è la tecnologia ma una domanda di business: quali fatti, dentro la tua azienda, meritano una reazione automatica, e che conversazione devono far nascere. Rispondere a questo è già metà del progetto; il resto, con strumenti come quelli che Userbot ha messo in campo, è esecuzione.

Domande frequenti

• Qual è la differenza tra un chatbot reattivo e un agente AI proattivo?

  Il chatbot reattivo risponde solo quando l'utente scrive. L'agente proattivo si attiva da solo al verificarsi di un evento — un messaggio, un'inattività, un orario o una chiamata esterna — ed esegue una sequenza di azioni senza intervento manuale.

• A cosa serve il trigger webhook di Userbot?

  Fa partire un flusso conversazionale quando un sistema esterno invia una chiamata HTTP. Permette di avviare l'agente in risposta a eventi reali come un pagamento incassato, un ticket aperto o un nuovo lead, integrando l'AI con CRM e gestionali.

• I dati inviati dal sistema esterno sono utilizzabili dall'agente?

  Sì. Il payload della chiamata viene mappato in variabili di sessione, che l'agente usa per personalizzare la conversazione: nome del contatto, riferimento all'ordine, stato della pratica. È il mapping a rendere le risposte contestuali e non generiche.

• Un webhook è sicuro da esporre?

  Solo se protetto. Senza restrizioni è un endpoint pubblico attivabile da chiunque ne conosca l'URL. Si mette in sicurezza con una whitelist per dominio, quando la chiamata arriva dal browser, o per IP, quando arriva da un servizio server-to-server con indirizzi noti.