Il tuo agente parte quando
succede davvero qualcosa
Un trigger risponde a una sola domanda: quando parte questo agente? Una scheduled task risponde con un orario. Un trigger webhook risponde con un evento che arriva da fuori. Si apre una pull request, si rompe una build, scatta un alert, e l'agente sta già lavorando.
AgentsRoom dà a ogni trigger un URL pubblico e un segreto di firma. Incolli l'URL in GitHub, GitLab, Slack, Linear, Sentry o in qualsiasi cosa sappia inviare un POST JSON. La chiamata arriva, la firma viene verificata, il payload diventa variabili del tuo prompt, e un vero agente parte nel tuo progetto, con il suo terminale e la sua trascrizione.
Un trigger, un URL pubblico. L'evento arriva, la firma viene verificata, il payload diventa variabili del prompt, e un agente parte nel tuo progetto.
Le scheduled task risolvevano metà del problema. Puoi già chiedere a un agente di rivedere le pull request ogni mattina alle 8. Solo che il grosso del lavoro che affideresti a un agente non succede alle 8: succede quando qualcuno apre una pull request, quando la build passa al rosso, quando un cliente segnala un bug alle 2 del pomeriggio.
Fino a oggi l'unico modo per intercettarlo era mettere un agente a sorvegliare: farlo girare su un intervallo stretto, fargli interrogare l'API, chiedere «c'è qualcosa di nuovo?» e pagare token per la risposta «no» qualche centinaio di volte al giorno. È caro, reagisce lentamente e diventa ingestibile appena vuoi sorvegliare tre repository.
Un trigger webhook ribalta il senso. È il servizio che ti avvisa. AgentsRoom ti dà un URL, tu lo incolli in GitHub, GitLab, Slack, Linear, Sentry o nella tua CI, e non gira niente finché quel servizio non chiama. Quando chiama, l'agente parte con l'evento già nel suo prompt. Zero token quando la giornata è tranquilla, un agente sul pezzo in pochi secondi quando non lo è.
Perché un evento batte un loop di polling
Smetti di pagare il silenzio. Un agente che controlla un repository ogni cinque minuti consuma un turno di contesto intero ogni cinque minuti, e quasi nessuno di quei turni trova qualcosa. Un trigger non consuma assolutamente niente finché l'evento non arriva.
La reazione è immediata. Nessun intervallo da regolare, nessuna finestra in cui una pull request resta ferma undici minuti perché il controllo è appena passato. L'agente parte sulla chiamata, quindi la revisione è già lì quando l'autore ricarica la pagina.
L'evento arriva con i suoi dati. Il payload viene trasformato in variabili che infili direttamente nel prompt: il titolo, l'autore, l'URL, il numero, il branch, o tutto il JSON grezzo. L'agente non deve andare a cercare che cosa lo ha svegliato.
È lo stesso pannello che conosci già. I trigger tengono l'elenco, l'interruttore on/off, lo storico per esecuzione, la scelta dell'agente e la portata per macchina delle scheduled task. Un webhook è solo un'altra risposta alla domanda «quando parte».
Un trigger, due modi di partire
Il pannello li contiene entrambi. Prendi quello che corrisponde a ciò che stai aspettando.
Pianificato
La modalità originale, invariata. Ogni N minuti, oraria, giornaliera, settimanale o mensile, senza nessuna espressione cron da scrivere. Per il lavoro che appartiene a un orologio: la revisione del mattino, il controllo delle dipendenze del lunedì, il changelog del venerdì.
Webhook
L'agente aspetta un evento invece di un orario. AgentsRoom ti dà un URL pubblico e un segreto di firma, tu incolli l'URL nel servizio, e il trigger parte quando quel servizio invia il suo POST. Per il lavoro che appartiene a qualcosa che succede: una pull request, una build fallita, una nuova segnalazione di bug.
Cosa far scattare
Eventi veri, e l'agente che vorresti dall'altra parte.
Rivedi ogni pull request appena si apre
Punta un webhook GitHub o GitLab sul trigger, filtra sull'apertura della pull request, e un agente revisore attacca il diff in pochi secondi. L'autore riceve un riscontro mentre ha ancora la modifica in testa.
Indaga automaticamente su una build rossa
La tua CI può inviare un POST quando una pipeline fallisce. Il trigger avvia un agente con il branch e l'URL dell'esecuzione nel prompt: legge il job che si è rotto e torna con una causa invece che con un badge rosso.
Fai il triage di un crash appena viene segnalato
Collega un alert Sentry a un trigger. Una nuova eccezione in produzione avvia un agente backend con il titolo dell'errore e l'URL del ticket, così la prima occhiata allo stack trace arriva prima che qualcuno apra la dashboard.
Avvia un agente da Slack
Una slash command o un webhook in uscita di Slack può chiamare l'URL del trigger. Qualcuno scrive la richiesta in un canale, il payload atterra nel prompt, e l'agente la prende nel progetto giusto.
Inquadra un nuovo ticket appena viene aperto
Un ticket creato su GitHub, GitLab o Linear avvia un agente prodotto che legge la segnalazione, fa le domande che mancano e la trasforma in qualcosa che uno sviluppatore può prendere in carico.
Fai una passata di QA dopo ogni deploy
La tua pipeline di deploy invia un POST quando esce una release. Il trigger avvia un agente QA che mette alla prova l'app sulla versione appena rilasciata, invece che su un orario che non ha niente a che vedere con le release.
Scrivi le release notes al tag
Un tag pushato, una release pubblicata, e un agente documentazione trasforma i commit in note leggibili. L'evento porta il nome del tag, quindi l'agente sa esattamente quale intervallo riassumere.
Qualsiasi cosa sappia inviare un POST JSON
Non c'è nessuna lista di integrazioni da aspettare. Un cron su un server, uno step di Zapier, un tool di monitoraggio, il tuo backend: se sa mandare un POST firmato a un URL, sa avviare un agente nel tuo progetto.
Come funziona un trigger webhook, passo dopo passo
Da un form vuoto a un agente che reagisce alla produzione, in un paio di minuti.
Crea un trigger
Apri il pannello Trigger sul tuo progetto e creane uno nuovo. Stesso elenco, stesso interruttore on e off, stesso storico di una scheduled task, perché è lo stesso pannello.
Passalo in modalità Webhook
Scegli Webhook invece di Pianificato. AgentsRoom genera un URL pubblico per questo trigger, con un segreto di firma lì accanto. Il segreto si rigenera quando vuoi, per tagliare fuori chi aveva il vecchio.
Incolla l'URL nel servizio
Mettilo in un webhook GitHub o GitLab, in una app Slack, in un'integrazione Linear o Sentry, o nella tua CI. Dai al servizio anche il segreto di firma, così le chiamate che invia possono essere verificate.
Filtra cosa deve davvero partire
Un repository manda un sacco di eventi. Aggiungi una condizione facoltativa sul payload, per esempio action uguale a opened, e tutto il resto viene ignorato. Imposta un limite anti-raffica perché un servizio rumoroso non avvii venti agenti in un minuto.
Metti l'evento nel tuo prompt
Scrivi il prompt con le variabili dell'evento: il titolo, l'autore, l'URL, il numero, il branch, o tutto il payload. Vengono risolte quando il trigger scatta, esattamente come le variabili di data e ora che le scheduled task supportano già.
Riproduci l'ultima chiamata e accendilo
L'editor mostra l'ultima chiamata ricevuta dal trigger, JSON grezzo compreso, e la riproduce con un clic. Un webhook lo colleghi guardandolo, non tirando a indovinare, e quando è giusto accendi il trigger.
La riga dei servizi è un insieme di scorciatoie, non una lista di ammessi. L'editor lo dice sotto il selettore, ed è per questo che la prima voce è Any service (JSON): funziona qualsiasi cosa sappia inviare un corpo JSON in POST. Scegliere GitHub, GitLab, Slack, Linear o Sentry aggiunge esattamente due cose, il suo header di firma da verificare e i campi del suo payload già mappati sulle variabili dell'evento. Niente viene rifiutato perché non è nell'elenco.
Le etichette delle variabili non sono documentazione, sono pulsanti: cliccane una per inserirla nel prompt, e quelle che l'ultima chiamata ha davvero riempito sono evidenziate. Sotto c'è l'ultima chiamata ricevuta dal trigger, così scrivi il filtro e il prompt su un payload vero che hai davanti, lo riproduci, e accendi il trigger solo quando l'esecuzione viene giusta.
- L'evento arriva sull'URL del trigger
Il servizio invia il suo JSON in POST. AgentsRoom verifica la firma con il tuo segreto e rifiuta qualsiasi chiamata non firmata, poi applica il tuo filtro se ne hai impostato uno.
- Aspetta se non c'è nessuno
La tua macchina può essere spenta. L'evento viene trattenuto per una settimana e riprodotto al lancio successivo invece di andare perso: lo stesso recupero che le scheduled task fanno già.
- Lo prende una macchina solaMac dell'ufficioMac di casaMacchina di build
Se più computer hanno il progetto aperto, il primo che prende l'evento lo blocca. Gli altri vedono che è già preso e tirano dritto, quindi un evento non produce mai due agenti.
- L'agente gira, una volta
Nel progetto si apre un vero agente, con il ruolo, il provider e il modello che hai scelto, il suo terminale, la sua vista conversazione e una trascrizione archiviata che rileggi più tardi.
Un URL pubblico che non è una porta aperta
L'URL è raggiungibile da internet, quindi il trigger decide che cosa accetta prima che parta qualsiasi cosa.
Ogni chiamata è firmata
AgentsRoom verifica ogni chiamata con il tuo segreto prima che parta qualsiasi cosa: X-Hub-Signature-256 per GitHub, X-Slack-Signature per Slack, il token condiviso X-Gitlab-Token per GitLab, e un semplice HMAC del corpo grezzo per Linear, Sentry e le sorgenti generiche. Una chiamata senza firma viene rifiutata: conoscere l'URL non basta per avviare un agente sulla tua macchina.
Rigenera il segreto quando vuoi
Il segreto di firma è mostrato nell'editor e si rigenera sul posto. Le vecchie chiamate smettono subito di essere valide, che è esattamente quello che serve il giorno in cui un servizio viene dismesso o un segreto finisce in un log.
Filtra sul payload
Una condizione facoltativa decide se l'evento merita un agente. Parti solo quando action vale opened, solo su un branch, solo per una label. Tutto ciò che non corrisponde viene scartato senza avviare niente.
Protezione anti-raffica
Al massimo un'esecuzione per finestra temporale. Un servizio che manda trenta eventi in dieci secondi non avvia trenta agenti: le chiamate dentro la finestra vengono raggruppate e una sola esecuzione le copre.
Il payload diventa il tuo prompt
Il JSON inviato dal servizio viene trasformato in variabili che scrivi direttamente nel prompt. Vengono risolte quando il trigger scatta, come le variabili di data e ora che le scheduled task usano già.
Scrivi il prompt una volta, e ogni esecuzione riceve i dati dell'evento che l'ha fatta partire.
{{event.title}}Il titolo dell'evento: il titolo della pull request, quello del ticket, il nome dell'alert.{{event.author}}Chi l'ha provocato: l'autore della pull request, la persona che ha aperto il ticket.{{event.url}}Il link all'evento, così l'agente può aprire la pull request o l'alert.{{event.number}}Il numero della pull request o del ticket, quando il servizio ne manda uno.{{event.branch}}Il branch a cui si riferisce l'evento, per un push, una pull request o una build fallita.{{payload}}Tutto il JSON grezzo, per quello che le variabili con un nome non coprono.
Review pull request #{{event.number}} "{{event.title}}" opened by {{event.author}} on branch {{event.branch}}. Read the diff at {{event.url}} and reply with the risky parts first.I nomi delle variabili si scrivono tra doppie parentesi graffe nel campo prompt, esattamente come le variabili di data e ora di una scheduled task.
event.actionevent.numberevent.titleevent.bodyevent.authorevent.branchevent.baseevent.urlevent.repositoryevent.stateevent.actionevent.numberevent.titleevent.bodyevent.authorevent.branchevent.baseevent.urlevent.repositoryevent.stateevent.actionevent.titleevent.bodyevent.authorevent.channelevent.urlevent.teamevent.actionevent.numberevent.titleevent.bodyevent.authorevent.assigneeevent.stateevent.priorityevent.urlevent.teamevent.actionevent.titleevent.bodyevent.levelevent.projectevent.urlevent.countevent.actionevent.titleevent.bodyevent.authorevent.urlevent.idCosa gira davvero, e dove
Lo stesso modello di esecuzione onesto delle scheduled task, esteso agli eventi.
Da dove arrivano gli eventi
Tutto ciò che sa inviare un POST firmato con un corpo JSON può avviare un agente. Questi sono quelli che si collegano per primi.
La tua CI, il tuo backend, qualsiasi cosa
Uno step di pipeline, un tool di monitoraggio, un servizio interno, uno script shell con curl. Non c'è nessuna integrazione da richiedere: un POST con un corpo JSON e una firma, è tutto il contratto.
GitHub e GitLab
Pull request e merge request aperte, revisionate o mergiate, ticket creati, push, release, workflow falliti. La sorgente classica, e quella con il payload più utile.
Slack
Una slash command o un webhook in uscita trasforma un messaggio in un canale in un'esecuzione di agente nel progetto giusto. Le firme di Slack vengono verificate con X-Slack-Signature.
Linear e Sentry
Un ticket spostato in una colonna, una nuova eccezione in produzione, un alert di regressione. Il tracker scatta, l'agente parte con il ticket o l'errore nel prompt.
L'altra metà dello stesso pannello
I trigger e le scheduled task sono una sola feature con due risposte alla stessa domanda. Una scheduled task è un trigger il cui evento è un orologio. Un trigger webhook è una scheduled task la cui pianificazione è il mondo esterno. Vivono nello stesso elenco e condividono la stessa configurazione dell'agente, lo stesso interruttore di attivazione, lo stesso storico delle esecuzioni e la stessa portata per macchina.
Quindi scegli in base al lavoro, non in base allo strumento. Il controllo delle dipendenze resta il lunedì mattina, perché niente all'esterno annuncia che un pacchetto è invecchiato. La revisione delle pull request passa su webhook, perché GitHub sa già il secondo esatto in cui deve avvenire. La pagina delle scheduled task copre il lato orologio della famiglia.
Vedi Scheduled Tasks, il lato orologio dello stesso pannelloFAQ
Che cos'è un trigger webhook in AgentsRoom?
È un trigger che avvia un agente AI quando un servizio esterno gli manda un evento, invece che a un orario fisso. AgentsRoom dà al trigger un URL pubblico e un segreto di firma; tu incolli l'URL in GitHub, GitLab, Slack, Linear, Sentry o in qualsiasi tool capace di inviare un POST JSON. Quando quel servizio chiama, la firma viene verificata, il tuo filtro facoltativo viene applicato, e un agente parte nel tuo progetto con il payload già disponibile come variabili del prompt.
In cosa è diverso da una scheduled task?
Cambia solo la risposta alla domanda «quando parte». Una scheduled task parte su un orologio: ogni N minuti, oraria, giornaliera, settimanale o mensile. Un trigger webhook parte su un evento che arriva da fuori. Tutto il resto è in comune: lo stesso elenco, lo stesso interruttore on e off, la stessa configurazione dell'agente, lo stesso storico per esecuzione, la stessa portata per macchina.
Perché non mettere semplicemente un agente a interrogare l'API?
Perché il polling costa token a ogni giro, e quasi ogni giro non trova niente. Un agente che controlla un repository ogni cinque minuti esegue un turno intero ogni cinque minuti per rispondere «no». Un trigger webhook non consuma niente finché non succede niente, e reagisce in pochi secondi quando succede qualcosa. È tutto qui l'argomento economico della feature.
È prudente esporre l'URL del trigger?
L'URL da solo non basta ad avviare niente. Ogni chiamata deve dimostrare di arrivare dal servizio che ha il tuo segreto: X-Hub-Signature-256 per GitHub, X-Slack-Signature per Slack, il token condiviso X-Gitlab-Token per GitLab, un semplice HMAC del corpo grezzo per Linear, Sentry e le sorgenti generiche. Una chiamata senza header di firma viene rifiutata, mai lasciata passare. Il segreto è mostrato nell'editor e si rigenera in qualsiasi momento, il che invalida subito tutto ciò che usava quello vecchio.
Posso far partire il trigger solo su certi eventi?
Sì. Un repository manda molti più eventi di quelli che meritano un agente, quindi un trigger accetta una condizione facoltativa sul payload, per esempio action uguale a opened. Gli eventi che non corrispondono vengono ignorati e non viene avviato niente. C'è anche un limite anti-raffica: al massimo un'esecuzione per finestra temporale, con le chiamate arrivate dentro quella finestra raggruppate insieme.
Cosa succede se AgentsRoom è chiuso quando arriva l'evento?
L'evento viene messo in coda lato server e riprodotto la volta successiva che avvii l'app, così gira in ritardo invece che mai. Gli eventi in coda vengono conservati per una settimana: abbastanza per un portatile chiuso durante un lungo weekend, senza riprodurre un mese di lavoro ormai vecchio quando torni. È lo stesso modello «nell'app più recupero» che usano le scheduled task. I trigger webhook non fanno girare il tuo agente nel cloud: l'agente gira sempre sulla tua macchina, nel tuo progetto.
Ho il progetto aperto su due computer. L'agente girerà due volte?
No. Un evento viene consumato una volta sola. La prima macchina che lo prende lo blocca, e le altre vedono che è già preso e lo saltano. Puoi anche fissare un trigger a macchine precise, esattamente come una scheduled task, se vuoi che se ne occupi un computer in particolare.
Cosa posso mettere nel prompt a partire dall'evento?
Il payload viene trasformato in variabili che scrivi direttamente nel campo prompt, tra doppie parentesi graffe: event.title, event.author, event.url, event.number, event.branch, e payload per tutto il JSON grezzo. Vengono risolte quando il trigger scatta, allo stesso modo delle variabili di data e ora di una scheduled task.
Come faccio a sapere se il mio webhook è collegato bene?
L'editor mostra l'ultima chiamata ricevuta dal trigger, corpo JSON grezzo compreso, e permette di riprodurla con un clic. Così regoli il filtro e il prompt su un payload vero che hai davanti, poi riproduci finché l'esecuzione non è giusta, invece di pushare commit di prova per scoprire com'è andata.
Quali servizi sono supportati?
Tutti quelli che sanno inviare un POST firmato con un corpo JSON. GitHub, GitLab, Slack, Linear e Sentry sono quelli che si collegano per primi perché i loro payload sono ricchi, ma non c'è nessuna lista chiusa: un job di CI, un tool di monitoraggio, il tuo backend o un curl dentro uno script shell funzionano esattamente allo stesso modo.
È un editor visuale di automazioni con scenari a più step?
No, e non vuole esserlo. Un trigger ha un solo compito: decidere quando parte un agente e consegnargli l'evento. La parte a più step è l'agente stesso, che legge il codice, lancia i tool e fa il lavoro. Se vuoi che più agenti si passino il lavoro, quello è il compito di Agent Teams, non di un canvas di scenari.
AgentsRoom può inviare webhook verso altri servizi?
I trigger sono solo in entrata: AgentsRoom riceve eventi, non ne emette. Se vuoi che un agente chiami un servizio esterno alla fine di un'esecuzione, quello è compito dell'agente stesso, con i tool e i server MCP che gli hai dato.
Si abbina bene con
Scheduled Tasks
Il lato orologio dello stesso pannello. Ogni N minuti, oraria, giornaliera, settimanale o mensile, senza nessuna espressione cron da scrivere.
Backlog Task Board
Trascini un ticket in una colonna e un agente lo prende in carico. Un trigger fa la stessa cosa, solo che a trascinare è un evento esterno.
Agent Teams
Agenti Dev, QA e PM che si passano il lavoro. Punta un trigger su un team e un evento avvia tutta la routine.
AgentsRoom MCP
I tool con cui un agente legge il backlog, la memoria e la libreria di prompt. Un agente avviato da un trigger li ha come tutti gli altri.
Notifiche degli agenti
Sai nell'istante in cui un trigger scatta, sul desktop e sul telefono, con un tap per aprire l'agente che ha avviato.
Flotta remota
Più macchine su un solo account. Fissa un trigger a quella che deve rispondere, e solo quella esegue l'agente.
Smetti di fare polling. Inizia a reagire.
Scarica AgentsRoom, incolla un URL in GitHub, GitLab, Slack, Linear o Sentry, e lascia che sia l'evento ad avviare l'agente. Non gira niente finché non succede niente.
App companion: monitora i tuoi agenti in movimento
Usa Claude, Codex, Antigravity CLI o un altro provider IA.
Invia bug e richieste direttamente nel tuo backlog pubblico.
Uno sguardo ad AgentsRoom in azione.