Ein Trigger startet eine Sitzung ohne anwesende Person. Ein Cron-Zeitplan löst sie nach Uhrzeit aus; ein signierter Webhook bei einem Ereignis. In beiden Fällen erhält der Agent seinen eigenen Cloud-Computer, seinen eigenen Branch und dieselbe Prüfung auf dem Rückweg.
Am 1. des Monats um 06:30 Uhr
0 30 6 1 * *
Ein Trigger ist eine Uhr oder eine Signatur. Alles andere — unter welchem Agenten er läuft, was er sagt und in welcher Sitzung er landet — ist in beiden Fällen dieselbe Konfiguration.
Ein 6-Feld-Cron-Ausdruck — Sekunde, Minute, Stunde, Tag, Monat, Wochentag — in jeder IANA-Zeitzone. Oder ein einzelner run_at-Zeitstempel für etwas, das einmal geschehen und dann ruhig bleiben soll.
Ein externer Dienst sendet per POST an die Trigger-URL. Kortix prüft die Signatur, rendert die Payload in den Prompt und startet die Sitzung. Eine Payload, die Ihren Filter nicht erfüllt, wird akzeptiert und ignoriert.
Jeder Trigger in einem Projekt ist eine Zeile: wie er heißt, wann er ausgelöst wird, in welcher Zeitzone, als welcher Agent und in welcher Sitzung diese Auslösung landet. Nichts davon ist ein verborgener Zustand, in den Sie erst hineinklicken müssen.
| Trigger | Cron | Timezone | Agent | Session |
|---|---|---|---|---|
| daily-digest | 0 0 9 * * 1-5Wochentags um 09:00 Uhr | America/Los_Angeles | kortix | neu |
| invoice-sweep | 0 30 6 1 * *Am 1. des Monats um 06:30 Uhr | Europe/Berlin | Finanzen | wiederverwenden |
| oncall-handoff | 0 0 17 * * 5Freitags um 17:00 Uhr | UTC | support | neu |
| roadmap-review | 0 0 8 * * 1Montags um 08:00 Uhr | America/New_York | Planer | angeheftet |
Trigger liegen in kortix.yaml neben Ihren Agenten und Sandbox-Images. Jeder benennt seinen Agenten, seinen Zeitplan oder sein Secret sowie die Prompt-Vorlage, die zur ersten Nachricht der Sitzung wird.
# fires on the clocktriggers: - slug: daily-digest type: cron agent: kortix cron: "0 0 9 * * 1-5" timezone: America/Los_Angeles session_mode: fresh prompt: | Summarize yesterday’s commits. Open a change request against main. # fires on an event - slug: new-lead type: webhook agent: sales secret_env: WEBHOOK_SECRET prompt: >- A new lead arrived: {{ body.name }} ({{ body.email }}). Add it to the CRM.# add it, ship it, and the schedule is live$ kortix triggers add daily-digest --type cron \ --cron "0 0 9 * * 1-5" \ --timezone America/Los_Angeles \ --prompt "Summarize yesterday. Open a CR."$ kortix ship→ kortix.yaml pushed. daily-digest is scheduled. # see every trigger and when it last fired$ kortix triggers ls # do not wait for 09:00 to find out$ kortix triggers fire daily-digest→ session startedEin Prompt rendert {{ token.dotted.path }} anhand der Payload, die ihn ausgelöst hat. Ein Webhook-Aufruf erhält {{ body.* }} und die Request-Header; ein Cron-Aufruf erhält {{ cron.schedule }}, {{ cron.timezone }} und {{ cron.scheduled_for }}. Ein nicht vorhandener Wert wird als nichts gerendert — kein Fehler und keine übrig gebliebenen geschweiften Klammern in der Nachricht, die Ihr Agent liest.
Jeder Webhook-Trigger benennt ein Projek-Secret, das ihn signiert. Ein Trigger ohne dieses Secret wird bei der Validierung abgelehnt — es gibt keinen nicht authentifizierten Webhook, dessen Absicherung Sie später vergessen könnten.
POST /v1/webhooks/projects/{projectId}/{slug}
X-Kortix-Signature: sha256=<hmac>
HMAC-SHA256 über den rohen Request-Body, in konstanter Zeit verglichen. Der mit GitHub kompatible Header X-Hub-Signature-256 funktioniert ebenfalls, sodass ein Repo-Webhook keinen Adapter benötigt.
Ein Filter ist ein anhand eines Punktpfads abgeglichener Ausdruck über denselben Payload, den der Prompt sieht. Er verhindert Schleifen: Eine Quelle, die beide Seiten einer Unterhaltung meldet, würde den Agenten sonst mit seiner eigenen Antwort auslösen.
Standardmäßig beginnt jedes Auslösen mit einem leeren Zustand. Wenn die Arbeit in einem laufenden Thread statt in einem neuen Auftrag erfolgt, kann ein Trigger eine bereits von ihm verwendete Sitzung erneut auffordern. Kortix probiert die Modi der Reihe nach und wechselt bei Fehlern zum nächsten, damit ein Auslösen nie einfach verschwindet.
Genau eine Sitzung erneut auffordern, angegeben durch ihre ID. Wenn die Sitzung nicht mehr vorhanden oder fehlgeschlagen ist, wird zum nächsten Modus gewechselt.
Einen Schlüssel aus dem Payload erzeugen und dann die zuletzt verwendete gesunde Sitzung mit genau diesem Schlüssel erneut auffordern. Ein Kunde, ein Thread. Es wird nie auf die Sitzung eines anderen Schlüssels zurückgegriffen.
Die zuletzt verwendete gesunde Sitzung, die dieser Trigger erstellt hat, erneut auffordern. Ein angehefteter Trigger fällt zunächst hierauf zurück.
Einen neuen Branch erstellen und einen neuen Cloud-Computer starten. Dies ist der Standard und der letzte Ausweg für alle anderen Modi.
Eine ausgelöste Sitzung ist für das gesamte Projekt sichtbar und nicht privat für die Person, die den Trigger eingerichtet hat. Nach 5 Minuten Leerlauf beendet sie sich selbst, damit eine um 3 Uhr morgens gestartete Automatisierung nicht bis zum Morgen einen kostenpflichtigen Rechner laufen lässt.
Eine Automatisierung erhält keine Berechtigungen, die eine Person nicht hätte. Dieselbe Isolation, dieselbe begrenzte Reichweite, derselbe einzige Weg zurück zu main.
Beginne mit einer Aufgabe und wachse von dort aus.