AIREITERFactory Automations kann eine Droid-Session zeitgesteuert, über eine Nachricht auf oberster Slack-Ebene, durch ein GitHub-Ereignis oder per eingehender HTTP-Anfrage starten. Webhook-Trigger befinden sich weiterhin in der Private Preview. Zeitpläne arbeiten mit festen UTC-Zeitpunkten und passen sich nicht automatisch an die Sommerzeit an. Für einen klar begrenzten Pilotbetrieb ist das System bereit – für einen uneingeschränkten Produktionseinsatz noch nicht.
Was Factory Automations tatsächlich ausführt
Jede Automation kombiniert einen Trigger, Anweisungen, eine Identität und ein Ausführungsziel (Factory-Dokumentation).
| Trigger | Was den Lauf startet | Wichtiges Detail zur Ausführung |
|---|---|---|
| Zeitplan | Beschreibung in natürlicher Sprache oder ein fünfteiliger Cron-Ausdruck | Ausführung auf einem ausgewählten Computer oder Zielsystem; verwaltete Computer unterstützen 10 Automationen und 5 Zeitpläne für eine Minute |
| Slack | Passende Nachricht auf oberster Kanalebene | Antwort im ursprünglichen Thread |
| GitHub | Pull Requests, Kommentare, Pushes, Labels, Checks oder ein Zeitplan | Nach der Einrichtung in GitHub Actions ausgeführt |
| Webhook | HTTP-POST von einem anderen Dienst | Droid Computer oder Ausführungsvorlage; Private Preview |
Eine Automation kann privat bleiben oder mit einer Organisation geteilt werden. Die Sitzungsprivatsphäre legt unabhängig davon fest, wer die von ihren Läufen erstellten Sessions öffnen darf.
Der Trigger bestimmt das Betriebsmodell
Zeitpläne: der sicherste Einstieg
Zeitpläne akzeptieren einfache Angaben wie „jeden Montag um 9 Uhr PST“ ebenso wie Cron-Ausdrücke wie 0 9 * * 1. Factory zeigt die daraus resultierende Zeit vorab an, Cron läuft jedoch in UTC. Eine angegebene Zeitzone wird in einen festen UTC-Zeitplan umgerechnet und bei der Umstellung auf Sommerzeit nicht automatisch angepasst (Factory-Dokumentation).
Geeignete erste Aufgaben sind ein täglicher Statusüberblick, eine Prüfung der Abhängigkeiten, die Suche nach veralteter Dokumentation oder ein PR-Reviewer, der zunächst Belege und Empfehlungen erstellt, statt Code zu mergen.
Slack-Nachrichten: nützlich, aber nur für Signale auf oberster Ebene
Eine Slack-Automation startet, sobald in einem zugänglichen Kanal eine passende Nachricht auf oberster Ebene erscheint. Antworten innerhalb eines Threads lösen keinen eigenen Lauf aus. Über Filter lassen sich Nachrichten nach Kanal-Muster, Absender-Typ, Schlüsselwörtern, ausgeschlossenen Schlüsselwörtern oder ausgeschlossenen Absendern einschränken.
Die Ausführung antwortet im Thread der auslösenden Nachricht. Passen mehrere Automationen, antwortet nur die erste dort; die übrigen veröffentlichen separate Nachrichten mit einem Link zum Original. Factory dokumentiert dieses Verhalten ebenso wie die Regeln für den Zugriff auf private Kanäle (Factory-Dokumentation). Das eignet sich gut für einen kontrollierten Incident-Kanal, nicht aber für Abläufe, die auf jede weitere Antwort im Thread angewiesen sind.
GitHub-Ereignisse: leistungsfähig, aber erst nach einer sichtbaren Einrichtungshürde
Benutzerdefinierte GitHub-Automationen können auf Pull Requests, Pushes, Kommentare, Änderungen an Labels, abgeschlossene Checks oder einen Zeitplan reagieren. Sie laufen in GitHub Actions. Beim Erstellen öffnet Factory in jedem ausgewählten Repository einen Setup-Pull-Request.
Dieser Setup-Pull-Request muss gemergt werden, bevor der Workflow aktiv ist. Läufe, die starten, bevor der Workflow den Default-Branch erreicht, schlagen fehl. Bis dahin kann die Automation weder Kommentare veröffentlichen noch Commits pushen oder Pull Requests öffnen. GitHub ist der stärkste Trigger, wenn die wiederkehrende Aufgabe ohnehin an ein Repository-Ereignis gekoppelt ist und die normale Pull-Request-Prüfung die Grenze für das Ausrollen bleibt.
Webhooks: technisch vorhanden, aber nur eingeschränkt verfügbar
Factory führt Webhook-Automationen als Private Preview und bittet Organisationen, sich für die Freischaltung an den Support zu wenden. Ein Webhook startet einen Lauf über einen externen HTTP-POST. Auf dem lokalen Rechner eines Benutzers kann er jedoch nicht ausgeführt werden; benötigt wird ein Droid Computer oder eine Ausführungsvorlage.
Factory stellt eine Webhook-URL, die Option für einen X-Webhook-Secret-Header sowie eine URL-Variante für Absender bereit, die keine Header setzen können. Die Dokumentation empfiehlt den Header, weil Geheimnisse in URLs in Logs auftauchen können. Das Secret wird nur einmal angezeigt; eine Rotation macht den alten Wert ungültig (Factory-Webhooks-Dokumentation).
Dieselbe Dokumentation nennt ein Body-Limit von 200 KiB, 60 akzeptierte Anfragen pro Minute, Zustellprotokolle für 30 Tage, ein zehnminütiges Deduplizierungsfenster für identische Bodies und eine Begrenzung auf 10 Läufe pro Stunde. Damit lassen sich Webhooks für Alarmreaktionen testen. Der Preview-Status bleibt jedoch ein Blocker für den Produktionseinsatz, wenn der Zugriff verlässlich planbar sein muss.
Diese Kontrollen entscheiden über den sicheren Automatisierungsbetrieb
Zeitplan-, Slack- und Webhook-Automationen können als Benutzer oder als gemeinsam genutztes Servicekonto laufen. Die Identität beeinflusst den Zugriff auf Connectoren, die Abrechnung und die Zuordnung in Slack. Die Regeln für Ausführungsziele stehen in der Factory-Dokumentation.
Formuliere den Prompt eng, verwende widerrufbare Zugangsdaten, wähle ein dediziertes Ausführungsziel und belasse Deployment- sowie Merge-Berechtigungen bei den bestehenden Repository-Kontrollen. In seinem Eintrag im Slack Marketplace weist Factory ausdrücklich darauf hin, dass die App Fehler machen kann, und empfiehlt, Code und Antworten zu überprüfen.
Ein Nutzer wies auf Lücken bei der Überwachung hin, darunter eine fehlende Linux-Desktop-App und keine Synchronisierung zwischen Computern (Beitrag von @JoelDeTeves auf X). Das ist relevant, wenn ein Team lang laufende automatisierte Aufgaben auch abseits eines Desktops überwachen möchte.
Factory Automations oder doch ein einfacher GitHub Action?
| Anforderung | Factory Automations | Einfache GitHub Action |
|---|---|---|
| Einen Prompt gegen ein Repository ausführen | Native Droid-Session und Ausführungsziel | Das Team stellt Agent-Laufzeit und Workflow-Code bereit |
| Geplante Aufgaben | Natürliche Sprache oder Cron, mit UTC-Einschränkung | GitHub-Cron und eigene Logik |
| Slack-Trigger | Nachrichten auf oberster Ebene mit Filtern und Antworten in Threads | Slack-App oder Webhook-Anbindung |
| GitHub-Ereignis | Geführter Setup-PR und Ausführung über GitHub Actions | Direkte Workflow-Datei |
| Webhook | Integriert, aber Private Preview | Endpoint, Authentifizierung, Retries und Worker selbst bauen |
| Prüfgrenze | Kann Arbeit für eine menschliche Prüfung vorbereiten | Hängt von den Workflow-Berechtigungen ab |
Greife zu einer GitHub Action, wenn es um deterministische API-Logik geht, etwa einen täglichen PR-Überblick. Factory ist sinnvoller, wenn der wiederkehrende Schritt Untersuchung, Repository-Kontext, einen vorgeschlagenen Code-Change oder eine für Menschen lesbare Session erfordert. Eine Agent-Plattform sollte nicht allein deshalb zum Einsatz kommen, weil ein kurzes Skript vermieden werden soll.
Ein risikoarmer Pilot, der schrittweise mehr Verantwortung übernehmen kann
- Wähle eine wiederkehrende Aufgabe mit begrenztem Input, etwa die Prüfung neuer Pull Requests oder generierter Dateien.
- Beginne mit einer zeitgesteuerten Automation statt mit einem Webhook. So entfällt der Zugriff auf die Preview-Funktion, und der Ausführungsrhythmus lässt sich leicht kontrollieren.
- Lass als Ergebnis zunächst einen Bericht oder Pull Request erzeugen, kein Deployment und keinen Merge.
- Dokumentiere fehlgeschlagene Läufe, blockierte Aufgaben, geänderte Dateien und menschliche Korrekturen. Allein angenommene Pull Requests liefern noch keine ausreichenden Belege.
- Erweitere jeweils nur eine Dimension: eine weitere Aufgabenkategorie, ein weiteres Repository oder einen weiteren Trigger.
Factorys Anleitung für Workflows empfiehlt, den ursprünglichen Fehler zu reproduzieren, eine Korrektur in einer sauberen Umgebung zu testen und anschließend einen ähnlichen Fall zu prüfen, bevor daraus eine wiederverwendbare Anweisung entsteht. Das ist auch für einen Automation-Pilotbetrieb ein sinnvoller Maßstab.
FAQ
Unterstützt Factory Automations Webhooks?
Ja, Webhook-Trigger befinden sich jedoch in der Private Preview und erfordern möglicherweise eine Freischaltung auf Organisationsebene. Für die Ausführung ist ein Droid Computer oder eine Ausführungsvorlage nötig. Details stehen im Abschnitt zu Webhooks weiter oben.
Lösen Antworten in Slack-Threads eine Automation aus?
Nein. Nur eine passende Nachricht auf oberster Ebene startet den Lauf; siehe Slack-Nachrichten.
Passt sich der Zeitplan an die Sommerzeit an?
Nein. Factory speichert einen festen UTC-Zeitplan. Wenn sich die lokalen Sommerzeitregeln ändern, sollte der Zeitplan überprüft werden. Siehe Zeitpläne.
Laufen GitHub-Automationen, bevor der Setup-Pull-Request gemergt ist?
Nein. Der Setup-Pull-Request muss zuerst den Default-Branch erreichen; frühere Läufe schlagen fehl. Siehe GitHub-Ereignisse.
Was passiert bei einer wiederholten Webhook-Zustellung?
Ein identischer Body, der innerhalb von 10 Minuten erneut eingeht, wird als Deduped protokolliert und startet keinen weiteren Lauf. Factory erfasst außerdem gefilterte, durch Rate-Limits begrenzte, übersprungene und fehlgeschlagene Zustellungen.
Der entscheidende Zielkonflikt
Setze zeitgesteuerte oder GitHub-gestützte Aufgaben als Pilot ein, wenn sich das Ergebnis innerhalb eines Pull-Request-Prüfprozesses halten lässt. Slack funktioniert mit klaren Konventionen für Nachrichten auf oberster Ebene gut. Webhooks sind detailliert genug für Tests, sollten wegen ihres Private-Preview-Status aber noch nicht das Fundament eines produktiven Incident-Systems bilden.