Dein Agent startet, wenn
wirklich etwas passiert
Ein Trigger beantwortet eine einzige Frage: Wann startet dieser Agent? Eine geplante Aufgabe antwortet mit einer Uhrzeit. Ein Webhook-Trigger antwortet mit einem Event aus der Außenwelt. Ein Pull Request geht auf, ein Build bricht, ein Alert schlägt an, und der Agent läuft bereits.
AgentsRoom gibt jedem Trigger eine öffentliche URL und ein Signatur-Secret. Du fügst die URL in GitHub, GitLab, Slack, Linear, Sentry oder alles ein, was JSON per POST senden kann. Der Aufruf kommt an, die Signatur wird geprüft, der Payload wird zu Variablen deines Prompts, und ein echter Agent startet in deinem Projekt, mit eigenem Terminal und eigenem Transcript.
Ein Trigger, eine öffentliche URL. Das Event kommt an, die Signatur wird geprüft, der Payload wird zu Variablen des Prompts, und ein Agent startet in deinem Projekt.
Geplante Aufgaben haben das Problem zur Hälfte gelöst. Du kannst einem Agenten längst sagen, dass er jeden Morgen um 8 die Pull Requests prüfen soll. Nur passiert das meiste, was man einem Agenten übergeben würde, eben nicht um 8: Es passiert, wenn jemand einen Pull Request öffnet, wenn der Build auf Rot springt, wenn ein Kunde um 14 Uhr einen Bug meldet.
Bis jetzt gab es nur einen Weg, das zu erwischen: einen Agenten nachschauen lassen. Ihn in kurzem Intervall starten, die API abfragen lassen, „was Neues?“ fragen und mehrere hundert Mal am Tag Tokens für die Antwort „nein“ bezahlen. Das ist teuer, es reagiert langsam, und es skaliert schlecht, sobald du drei Repositories beobachten willst.
Ein Webhook-Trigger dreht die Richtung um. Der Dienst sagt dir Bescheid. AgentsRoom gibt dir eine URL, du fügst sie in GitHub, GitLab, Slack, Linear, Sentry oder deine CI ein, und nichts läuft, solange dieser Dienst nichts sendet. Sendet er, startet der Agent mit dem Event schon im Prompt. Null Tokens, wenn der Tag ruhig ist, und ein Agent an der Sache in Sekunden, wenn er es nicht ist.
Warum ein Event eine Polling-Schleife schlägt
Du hörst auf, für Stille zu bezahlen. Ein Agent, der alle fünf Minuten ein Repository prüft, verbraucht alle fünf Minuten einen vollständigen Kontext-Durchlauf, und fast jeder dieser Durchläufe findet nichts. Ein Trigger verbraucht exakt nichts, bis das Event ankommt.
Die Reaktion kommt sofort. Kein Intervall zum Einstellen, kein Zeitfenster, in dem ein Pull Request elf Minuten liegen bleibt, weil die Abfrage gerade durch war. Der Agent startet auf den Aufruf hin, also wartet das Review schon, wenn der Autor die Seite neu lädt.
Das Event bringt seine Daten mit. Der Payload wird in Variablen zerlegt, die du direkt in den Prompt setzt: Titel, Autor, URL, Nummer, Branch oder das ganze rohe JSON. Der Agent muss nicht erst holen gehen, was ihn ausgelöst hat.
Es ist dasselbe Panel, das du schon kennst. Trigger behalten die Liste, den Ein/Aus-Schalter, die Historie pro Lauf, die Agentenauswahl und die Bindung an bestimmte Maschinen der geplanten Aufgaben. Ein Webhook ist einfach eine weitere Antwort auf „wann löst das aus“.
Ein Trigger, zwei Arten auszulösen
Das Panel trägt beide. Nimm die, die zu dem passt, worauf du wartest.
Geplant
Der ursprüngliche Modus, unverändert. Alle N Minuten, stündlich, täglich, wöchentlich oder monatlich, ohne eine cron-Expression zu schreiben. Für Arbeit, die zu einer Uhr gehört: das Review am Morgen, der Dependency-Check am Montag, das Changelog am Freitag.
Webhook
Der Agent wartet auf ein Event statt auf eine Uhrzeit. AgentsRoom gibt dir eine öffentliche URL und ein Signatur-Secret, du fügst die URL in den Dienst ein, und der Trigger löst aus, sobald dieser Dienst seinen POST schickt. Für Arbeit, die zu einem Vorfall gehört: ein Pull Request, ein fehlgeschlagener Build, ein neuer Bug-Report.
Was sich auslösen lässt
Echte Events, und der Agent, den man am anderen Ende haben will.
Jeden Pull Request prüfen, sobald er aufgeht
Richte einen GitHub- oder GitLab-Webhook auf den Trigger, filtere auf das Öffnen des Pull Requests, und ein Reviewer-Agent geht in Sekunden auf den Diff los. Der Autor bekommt Feedback, solange er die Änderung noch im Kopf hat.
Einen roten Build automatisch untersuchen
Deine CI kann einen POST senden, wenn eine Pipeline fehlschlägt. Der Trigger startet einen Agenten mit dem Branch und der URL des Laufs im Prompt, also liest er den gescheiterten Job und kommt mit einer Ursache zurück statt mit einem roten Badge.
Einen Crash triagieren, sobald er gemeldet wird
Häng einen Sentry-Alert an einen Trigger. Eine neue Exception in der Produktion startet einen Backend-Agenten mit dem Titel des Fehlers und der URL des Issues, also passiert der erste Blick auf den Stacktrace, bevor überhaupt jemand das Dashboard öffnet.
Einen Agenten aus Slack starten
Ein Slash Command oder ein ausgehender Webhook von Slack kann die Trigger-URL aufrufen. Jemand tippt die Anfrage in einen Channel, der Payload landet im Prompt, und der Agent nimmt sie im richtigen Projekt auf.
Ein neues Issue eingrenzen, sobald es angelegt ist
Ein Issue, das auf GitHub, GitLab oder Linear angelegt wird, startet einen Produkt-Agenten, der die Meldung liest, die fehlenden Fragen stellt und daraus etwas macht, das ein Entwickler übernehmen kann.
Nach jedem Deploy einen QA-Durchlauf fahren
Deine Deploy-Pipeline sendet einen POST, wenn ein Release rausgeht. Der Trigger startet einen QA-Agenten, der die App gegen genau die Version durchspielt, die gerade ausgeliefert wurde, statt nach einem Zeitplan, der mit Releases nichts zu tun hat.
Die Release Notes beim Tag schreiben
Ein Tag wird gepusht, ein Release veröffentlicht, und ein Dokumentations-Agent macht aus den Commits lesbare Notizen. Das Event trägt den Namen des Tags, also weiß der Agent genau, welchen Bereich er zusammenfassen soll.
Alles, was JSON per POST senden kann
Es gibt keine Integrationsliste, auf die du warten musst. Ein cron auf einem Server, ein Zapier-Schritt, ein Monitoring-Tool, dein eigenes Backend: Wenn es einen signierten POST an eine URL schicken kann, kann es einen Agenten in deinem Projekt starten.
So funktioniert ein Webhook-Trigger, Schritt für Schritt
Von einem leeren Formular zu einem Agenten, der auf die Produktion reagiert, in ein paar Minuten.
Lege einen Trigger an
Öffne das Trigger-Panel auf deinem Projekt und lege einen neuen an. Gleiche Liste, gleicher Ein/Aus-Schalter, gleiche Historie wie bei einer geplanten Aufgabe, denn es ist dasselbe Panel.
Stell ihn auf Webhook um
Wähle Webhook statt Geplant. AgentsRoom erzeugt eine öffentliche URL für diesen Trigger und daneben ein Signatur-Secret. Das Secret lässt sich jederzeit neu erzeugen, um dem den Zugang zu kappen, der das alte hatte.
Füge die URL in den Dienst ein
Setz sie in einen GitHub- oder GitLab-Webhook, eine Slack-App, eine Linear- oder Sentry-Integration oder in deine CI. Gib dem Dienst auch das Signatur-Secret, damit seine Aufrufe überprüfbar sind.
Filtere, was wirklich auslösen soll
Ein Repository sendet viele Events. Füge eine optionale Bedingung auf dem Payload hinzu, zum Beispiel action gleich opened, und alles andere wird ignoriert. Setz ein Burst-Limit, damit ein geschwätziger Dienst nicht zwanzig Agenten in einer Minute startet.
Bring das Event in deinen Prompt
Schreib den Prompt mit den Variablen des Events: Titel, Autor, URL, Nummer, Branch oder den ganzen Payload. Sie werden aufgelöst, sobald der Trigger auslöst, genau wie die Datums- und Zeitvariablen, die geplante Aufgaben schon unterstützen.
Spiel den letzten Aufruf erneut ab und geh live
Der Editor zeigt den letzten Aufruf, den der Trigger empfangen hat, samt rohem JSON, und spielt ihn mit einem Klick erneut ab. Du verkabelst einen Webhook, indem du ihn ansiehst, nicht indem du rätst, und wenn es stimmt, schaltest du den Trigger ein.
Die Reihe der Dienste ist eine Sammlung von Abkürzungen, keine Positivliste. Der Editor sagt das unter der Auswahl, und genau deshalb ist der erste Eintrag Any service (JSON): Alles, was einen JSON-Body per POST senden kann, funktioniert. GitHub, GitLab, Slack, Linear oder Sentry auszuwählen fügt exakt zwei Dinge hinzu, den jeweils eigenen Signatur-Header zum Prüfen und die Payload-Felder, die schon auf die Event-Variablen abgebildet sind. Nichts wird abgelehnt, weil es nicht in der Liste steht.
Die Variablen-Chips sind keine Dokumentation, sie sind Buttons: Klick auf einen, und er landet im Prompt, und die, die der letzte Aufruf tatsächlich gefüllt hat, sind hervorgehoben. Darunter steht der letzte Aufruf, den der Trigger empfangen hat, du schreibst Filter und Prompt also gegen einen echten Payload, den du siehst, spielst ihn erneut ab und schaltest den Trigger erst ein, wenn der Lauf richtig herauskommt.
- Das Event landet auf deiner Trigger-URL
Der Dienst sendet sein JSON per POST. AgentsRoom prüft die Signatur gegen dein Secret und weist jeden unsignierten Aufruf ab, und wendet dann deinen Filter an, falls du einen gesetzt hast.
- Es wartet, wenn niemand da ist
Deine Maschine darf aus sein. Das Event wird bis zu eine Woche lang festgehalten und beim nächsten Start erneut zugestellt, statt verloren zu gehen: dasselbe Nachhol-Modell, das geplante Aufgaben schon nutzen.
- Eine Maschine nimmt es, und nur eineBüro-MacMac zu HauseBuild-Maschine
Haben mehrere Rechner das Projekt offen, sperrt der erste, der das Event greift, es für sich. Die anderen sehen, dass es vergeben ist, und ziehen weiter, also erzeugt ein einzelnes Event nie zwei Agenten.
- Der Agent läuft, einmal
Ein echter Agent öffnet sich im Projekt, mit der Rolle, dem Provider und dem Modell deiner Wahl, mit eigenem Terminal, eigener Konversationsansicht und einem archivierten Transcript, das du später nachlesen kannst.
Eine öffentliche URL, die keine offene Tür ist
Die URL ist aus dem Internet erreichbar, also entscheidet der Trigger, was er annimmt, bevor irgendetwas startet.
Jeder Aufruf ist signiert
AgentsRoom prüft jeden Aufruf gegen dein Secret, bevor irgendetwas startet: X-Hub-Signature-256 für GitHub, X-Slack-Signature für Slack, das geteilte Token X-Gitlab-Token für GitLab und ein schlichter HMAC über den rohen Body für Linear, Sentry und generische Quellen. Ein Aufruf ohne Signatur wird abgewiesen, die URL zu kennen reicht also nicht, um einen Agenten auf deiner Maschine zu starten.
Erneuere das Secret, wann du willst
Das Signatur-Secret steht im Editor und lässt sich an Ort und Stelle neu erzeugen. Alte Aufrufe sind sofort nicht mehr gültig, und genau das willst du an dem Tag, an dem ein Dienst abgeschaltet wird oder ein Secret in ein Log rutscht.
Filtere auf dem Payload
Eine optionale Bedingung entscheidet, ob das Event einen Agenten verdient. Nur auslösen, wenn action gleich opened ist, nur auf einem Branch, nur für ein Label. Alles, was nicht passt, wird verworfen, ohne dass etwas gestartet wird.
Burst-Schutz
Höchstens ein Lauf pro Zeitfenster. Ein Dienst, der dreißig Events in zehn Sekunden schickt, startet keine dreißig Agenten: Die Aufrufe innerhalb des Fensters werden zusammengefasst, und ein einziger Lauf deckt sie ab.
Der Payload wird zu deinem Prompt
Das JSON, das der Dienst sendet, wird in Variablen zerlegt, die du direkt in den Prompt schreibst. Sie werden beim Auslösen aufgelöst, wie die Datums- und Zeitvariablen, die geplante Aufgaben schon nutzen.
Du schreibst den Prompt einmal, und jeder Lauf bekommt die Daten des Events, das ihn ausgelöst hat.
{{event.title}}Der Titel des Events: der Titel des Pull Requests, der Titel des Issues, der Name des Alerts.{{event.author}}Wer es verursacht hat: der Autor des Pull Requests, die Person, die das Issue geöffnet hat.{{event.url}}Der Link zurück zum Event, damit der Agent den Pull Request oder den Alert öffnen kann.{{event.number}}Die Nummer des Pull Requests oder des Issues, wenn der Dienst eine mitschickt.{{event.branch}}Der Branch, um den es im Event geht, bei einem Push, einem Pull Request oder einem fehlgeschlagenen Build.{{payload}}Das ganze rohe JSON, für alles, was die benannten Variablen nicht abdecken.
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.Die Variablennamen stehen im Prompt-Feld zwischen doppelten geschweiften Klammern, genau wie die Datums- und Zeitvariablen einer geplanten Aufgabe.
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.idWas tatsächlich läuft, und wo
Dasselbe ehrliche Ausführungsmodell wie bei geplanten Aufgaben, erweitert auf Events.
Woher die Events kommen
Alles, was einen signierten POST mit JSON-Body senden kann, kann einen Agenten starten. Das sind die Quellen, die man zuerst verkabelt.
Deine CI, dein Backend, alles
Ein Pipeline-Schritt, ein Monitoring-Tool, ein interner Dienst, ein Shell-Skript mit curl. Es gibt keine Integration zu beantragen: ein POST mit JSON-Body und einer Signatur, das ist der ganze Vertrag.
GitHub und GitLab
Pull Requests und Merge Requests, die geöffnet, reviewt oder gemerged werden, angelegte Issues, Pushes, Releases, fehlgeschlagene Workflows. Die klassische Quelle, und die mit dem nützlichsten Payload.
Slack
Ein Slash Command oder ein ausgehender Webhook macht aus einer Nachricht in einem Channel einen Agenten-Lauf im richtigen Projekt. Slack-Signaturen werden mit X-Slack-Signature geprüft.
Linear und Sentry
Ein Issue, das in eine Spalte wandert, eine neue Exception in der Produktion, ein Regressions-Alert. Das Tracking-Tool löst aus, der Agent startet mit dem Ticket oder dem Fehler im Prompt.
Die andere Hälfte desselben Panels
Trigger und geplante Aufgaben sind ein einziges Feature mit zwei Antworten auf dieselbe Frage. Eine geplante Aufgabe ist ein Trigger, dessen Event eine Uhr ist. Ein Webhook-Trigger ist eine geplante Aufgabe, deren Zeitplan die Außenwelt ist. Sie leben in derselben Liste und teilen sich dieselbe Agenten-Konfiguration, denselben Ein/Aus-Schalter, dieselbe Lauf-Historie und dieselbe Bindung an bestimmte Maschinen.
Du wählst also pro Arbeit statt pro Werkzeug. Der Dependency-Check bleibt am Montagmorgen, weil von außen niemand ankündigt, dass ein Paket veraltet ist. Das Pull-Request-Review wandert auf einen Webhook, weil GitHub die genaue Sekunde längst kennt, in der es stattfinden soll. Die Seite zu den geplanten Aufgaben deckt die Uhr-Seite der Familie ab.
Geplante Aufgaben ansehen, die Uhr-Seite desselben PanelsFAQ
Was ist ein Webhook-Trigger in AgentsRoom?
Es ist ein Trigger, der einen KI-Agenten startet, wenn ein externer Dienst ihm ein Event schickt, statt zu einer festen Zeit. AgentsRoom gibt dem Trigger eine öffentliche URL und ein Signatur-Secret; du fügst die URL in GitHub, GitLab, Slack, Linear, Sentry oder jedes Werkzeug ein, das JSON per POST senden kann. Ruft dieser Dienst die URL auf, wird die Signatur geprüft, dein optionaler Filter angewendet, und ein Agent startet in deinem Projekt, mit dem Payload bereits als Variablen des Prompts verfügbar.
Worin unterscheidet sich das von einer geplanten Aufgabe?
Nur die Frage „wann löst das aus“ ändert sich. Eine geplante Aufgabe löst nach der Uhr aus: alle N Minuten, stündlich, täglich, wöchentlich oder monatlich. Ein Webhook-Trigger löst auf ein Event von außen aus. Alles andere ist gemeinsam: dieselbe Liste, derselbe Ein/Aus-Schalter, dieselbe Agenten-Konfiguration, dieselbe Historie pro Lauf, dieselbe Bindung an bestimmte Maschinen.
Warum nicht einfach einen Agenten die API abfragen lassen?
Weil Polling bei jedem Durchlauf Tokens kostet und fast jeder Durchlauf nichts findet. Ein Agent, der alle fünf Minuten ein Repository prüft, fährt alle fünf Minuten einen vollständigen Durchlauf, um „nein“ zu antworten. Ein Webhook-Trigger verbraucht nichts, solange nichts passiert, und reagiert in Sekunden, wenn doch etwas passiert. Das ist das ganze wirtschaftliche Argument für dieses Feature.
Ist es unbedenklich, die Trigger-URL offenzulegen?
Die URL allein reicht nicht, um irgendetwas zu starten. Jeder Aufruf muss belegen, dass er von dem Dienst kommt, der dein Secret hat: X-Hub-Signature-256 für GitHub, X-Slack-Signature für Slack, das geteilte Token X-Gitlab-Token für GitLab, ein schlichter HMAC über den rohen Body für Linear, Sentry und generische Quellen. Ein Aufruf ohne Signatur-Header wird abgewiesen und nie durchgewunken. Das Secret steht im Editor und lässt sich jederzeit neu erzeugen, was sofort alles ungültig macht, was das alte benutzt hat.
Kann ich nur bei bestimmten Events auslösen?
Ja. Ein Repository sendet weit mehr Events, als du Agenten dafür haben willst, also nimmt ein Trigger eine optionale Bedingung auf dem Payload an, zum Beispiel action gleich opened. Events, die nicht passen, werden ignoriert, und es wird nichts gestartet. Es gibt außerdem ein Burst-Limit: höchstens ein Lauf pro Zeitfenster, wobei die Aufrufe, die in diesem Fenster ankommen, zusammengefasst werden.
Was passiert, wenn AgentsRoom geschlossen ist, während das Event ankommt?
Das Event wird auf dem Server in die Warteschlange gestellt und beim nächsten Start der App erneut zugestellt, es läuft also verspätet statt nie. Events in der Warteschlange werden eine Woche lang aufbewahrt, was ein über ein langes Wochenende zugeklapptes Notebook abdeckt, ohne dir bei der Rückkehr einen Monat abgestandene Arbeit erneut zuzustellen. Es ist dasselbe Modell aus In-App plus Nachholen, das geplante Aufgaben nutzen. Webhook-Trigger lassen deinen Agenten nicht in der Cloud laufen: Der Agent läuft immer auf deiner Maschine, in deinem Projekt.
Ich habe das Projekt auf zwei Rechnern offen. Läuft der Agent dann zweimal?
Nein. Ein Event wird genau einmal verbraucht. Die erste Maschine, die es aufgreift, sperrt es, und die anderen sehen, dass es vergeben ist, und überspringen es. Du kannst einen Trigger auch an bestimmte Maschinen heften, genau wie eine geplante Aufgabe, wenn ein bestimmter Rechner dafür zuständig sein soll.
Was kann ich aus dem Event in den Prompt setzen?
Der Payload wird in Variablen zerlegt, die du direkt ins Prompt-Feld schreibst, zwischen doppelten geschweiften Klammern: event.title, event.author, event.url, event.number, event.branch und payload für das ganze rohe JSON. Sie werden aufgelöst, sobald der Trigger auslöst, genauso wie die Datums- und Zeitvariablen einer geplanten Aufgabe.
Woher weiß ich, ob mein Webhook richtig verkabelt ist?
Der Editor zeigt den letzten Aufruf, den der Trigger empfangen hat, samt rohem JSON-Body, und lässt dich ihn mit einem Klick erneut abspielen. Du stellst Filter und Prompt also gegen einen echten Payload ein, den du siehst, und spielst so lange erneut ab, bis der Lauf stimmt, statt Test-Commits zu pushen, um es herauszufinden.
Welche Dienste werden unterstützt?
Jeder Dienst, der einen signierten POST mit JSON-Body senden kann. GitHub, GitLab, Slack, Linear und Sentry sind die, die man zuerst verkabelt, weil ihre Payloads reichhaltig sind, aber es gibt keine feste Liste: ein CI-Job, ein Monitoring-Tool, dein eigenes Backend oder ein curl in einem Shell-Skript funktionieren genau gleich.
Ist das ein visueller Automations-Baukasten mit mehrstufigen Szenarien?
Nein, und das will es auch nicht sein. Ein Trigger hat eine einzige Aufgabe: entscheiden, wann ein Agent startet, und ihm das Event übergeben. Der mehrstufige Teil ist der Agent selbst, der den Code liest, die Werkzeuge startet und die Arbeit macht. Wenn mehrere Agenten einander Arbeit übergeben sollen, ist das Agent Teams, kein Szenario-Canvas.
Kann AgentsRoom Webhooks an andere Dienste senden?
Trigger sind nur eingehend: AgentsRoom empfängt Events, es sendet keine. Wenn ein Agent am Ende eines Laufs einen externen Dienst aufrufen soll, ist das die Aufgabe des Agenten selbst, mit den Werkzeugen und den MCP-Servern, die du ihm gegeben hast.
Passt gut zu
Geplante Aufgaben
Die Uhr-Seite desselben Panels. Alle N Minuten, stündlich, täglich, wöchentlich oder monatlich, ohne eine cron-Expression zu schreiben.
Backlog Task Board
Zieh ein Ticket in eine Spalte, und ein Agent nimmt es auf. Ein Trigger macht dasselbe, nur zieht ein Event von außen.
Agent Teams
Dev-, QA- und PM-Agenten, die einander Arbeit übergeben. Richte einen Trigger auf ein Team, und ein Event startet die ganze Routine.
AgentsRoom MCP
Die Werkzeuge, mit denen ein Agent das Backlog, das Gedächtnis und die Prompt-Bibliothek liest. Ein ausgelöster Agent bekommt sie wie jeder andere.
Agenten-Benachrichtigungen
Erfahre in der Sekunde, in der ein Trigger auslöst, auf dem Desktop und auf deinem Handy, mit einem Tippen zum Agenten, den er gestartet hat.
Remote-Flotte
Mehrere Maschinen auf einem Konto. Hefte einen Trigger an die, die antworten soll, und nur diese Maschine führt den Agenten aus.
Hör auf zu pollen. Fang an zu reagieren.
Lade AgentsRoom herunter, füge eine URL in GitHub, GitLab, Slack, Linear oder Sentry ein, und lass das Event den Agenten starten. Nichts läuft, solange nichts passiert.
Companion-App: Agenten auch unterwegs im Blick behalten
Nutzen Sie Claude, Codex, Antigravity CLI oder einen anderen KI-Anbieter.
Bugs und Wünsche direkt in dein öffentliches Backlog schicken.
Ein Blick auf AgentsRoom in Aktion.