Eine URL, die deinen Agenten weckt

Unsere Agenten planen ihre Arbeit bereits selbst. Ein Kalendereintrag löst aus, der Agent wacht auf, erledigt die Aufgabe und meldet sich nur, wenn etwas deine Aufmerksamkeit verdient. Das deckt alles ab, was sich vorhersehen lässt: den Statusbericht am Montag, die tägliche Kontrolle eines wackeligen Lieferanten-Feeds. Aber die Arbeit, die deinen Tag wirklich unterbricht, steht selten in einem Zeitplan. Ein Pull Request öffnet sich nicht nach einem Cron-Ausdruck.

Deshalb können Agenten jetzt externe Trigger ausstellen: Kalendereinträge ganz ohne Zeitplan, nur eine URL. Schick ein HTTP POST an diese URL, und der Agent wacht auf und führt die Anweisung aus, die am Eintrag hinterlegt ist. Das ist die gesamte Schnittstelle. Kann ein System eine URL aufrufen, kann es deinen Agenten an die Arbeit setzen.

curl -X POST https://squidler.io/gateway/triggers/calendar/<your-trigger-token>

Du kannst deinen Agenten im Chat darum bitten („richte einen Trigger für die Review neuer Pull Requests ein“), und er gibt dir die URL samt passendem Snippet für deine Pipeline, oder du legst dir selbst einen über die Karte Externe Trigger auf dem Schreibtisch an. Die Karte erscheint, sobald ein Trigger existiert; dort kopierst du URLs, pausierst einen Trigger oder widerrufst ihn, indem du den Eintrag löschst.

Drei Stellen, auf die du sie richten kannst

Ein n8n-Workflow. Setz einen HTTP-Request-Node ans Ende eines beliebigen Flows in n8n. Ein neuer Lead landet im CRM, n8n macht sein übliches Routing, und der letzte Node weckt deinen Agenten, dessen Anweisung lautet: das Unternehmen recherchieren und ein kurzes Briefing bereitlegen, bevor jemand zum Hörer greift.

Ein Zap. Dasselbe Muster in Zapier oder Make: Schließ mit einem Webhooks-POST-Schritt ab. Eine Formularantwort kommt herein, der Zap legt sie dorthin, wo sie hingehört, und der Agent liest die neuen Einträge und markiert die, die heute einen Menschen brauchen statt erst diese Woche.

Eine GitHub Action. Der Workflow unten weckt den Agenten jedes Mal, wenn ein Pull Request geöffnet wird oder neue Commits bekommt. Die stehende Anweisung des Agenten: nach neuen oder aktualisierten PRs schauen, die Änderungen reviewen, berichten, was er findet.

on:
  pull_request:
    types: [opened, synchronize]
jobs:
  wake-agent:
    runs-on: ubuntu-latest
    steps:
      - run: curl -X POST ${{ secrets.AGENT_TRIGGER_URL }}

Leg die URL als Repository Secret ab: Wer sie hat, kann den Trigger auslösen.

Nichts davon sind Integrationen, die wir gebaut haben. Alles ist einfach nur POST, und genau das ist der Punkt: Der Long Tail an Werkzeugen, die eine URL aufrufen können, ist viel länger als jeder Integrationskatalog. Ein Uptime-Monitor kann sie in dem Moment aufrufen, in dem deine Seite ausfällt, und der Agent sieht sich die echte Seite an, statt dir zu melden, dass ein Probe fehlgeschlagen ist. Calendly kann sie aufrufen, wenn ein Termin gebucht wird, und der Agent hat vor dem Gespräch ein Briefing zum Teilnehmer bereit. Der Aufruf selbst trägt nichts bei sich; der Agent handelt nach der Anweisung, die du gespeichert hast, und schlägt alles Weitere selbst nach — die Anweisung sollte also sagen, wo er nachsehen soll („nach neuen oder aktualisierten Pull Requests schauen“), den Rest holt sich der Agent von allein.

Leitplanken

Was ein Aufrufer mit der Anfrage mitschickt, erreicht den Agenten nie. Das ist eine Sicherheitsmaßnahme, keine Lücke: Die URL wirkt wie ein Schlüssel, und Schlüssel landen in Konfigdateien, Chatverläufen und Bildschirmfreigaben. Wer sie findet, kann die Aufgabe starten, die du geschrieben hast, mehr nicht. Daten oder Anweisungen in den Kopf deines Agenten schmuggeln kann er nicht, eine geleakte URL ist also ein Ärgernis und kein Weg hinein.

Jede Auslösung ist ganz normale Agentenarbeit und geht von deinem normalen Kontingent ab, deshalb gibt es eine Obergrenze dafür, wie oft ein Trigger feuern kann: 10 Mal pro Minute, 30 pro Stunde, 120 pro Tag. Aufrufe darüber hinaus werden abgewiesen statt für später aufgehoben, ein durchgedrehter Aufrufer verliert also Aufrufe, statt in einer Stunde ein ganzes Tageskontingent zu verbrennen.

Der Agent zählt außerdem mit. Ruft etwas denselben Trigger neun Mal in einer Stunde auf, erfährt der Agent beim Aufwachen genau das, und seine Aufgabe ist es, darauf hinzuweisen: reparieren, was hängt, oder den Trigger pausieren, beides einen Klick entfernt, statt pflichtbewusst jede Dublette abzuarbeiten.

Eine Pause behält die URL, stoppt aber die Auslösungen, ein pausierter Trigger lässt sich also wieder starten, ohne dass jemand sein Setup anfassen muss. Erst das Löschen des Triggers macht die URL endgültig tot; ein neuer Trigger bekommt eine neue.

Was du deinem Agenten sagst

Externe Trigger sind ab heute für jeden Agenten verfügbar, und der Einstieg ist eine einzige Chatnachricht. Briefe ihn wie einen Kollegen: Sag, wann der Trigger feuern wird und was du getan haben willst.

Dasselbe Muster funktioniert für alles, was dein Agent selbst prüfen kann: eine Deployment-Wache („wenn das hier feuert, hol unsere Statusseite und sag mir, ob etwas komisch aussieht“) oder einen Code-Reviewer („review Pull Requests, die seit deinem letzten Lauf neu oder aktualisiert sind, und schick mir die Highlights“). Briefen, URL holen, in die Pipeline einfügen.

Die Anweisung lässt sich jederzeit über die Karte Externe Trigger auf dem Schreibtisch ändern, und die URL bleibt dieselbe, der Zap oder Workflow, der sie aufruft, muss also nie angefasst werden. Ab da ist dein Agent von allem nur ein POST entfernt.