Un déclencheur démarre une session sans présence humaine. Une planification cron la lance à l’heure prévue ; un webhook signé la lance lors d’un événement. Dans les deux cas, l’agent obtient son propre ordinateur cloud, sa propre branche et la même validation au retour.
Le 1er du mois à 06:30
0 30 6 1 * *
Un déclencheur est une horloge ou une signature. Tout le reste — l’agent sous lequel il s’exécute, son contenu et la session dans laquelle il arrive — relève de la même configuration dans les deux cas.
Une expression cron à 6 champs — seconde, minute, heure, jour, mois, jour de la semaine — dans n’importe quel fuseau IANA. Ou un horodatage run_at unique, pour un événement ponctuel qui reste ensuite silencieux.
Un service externe envoie une requête POST à l’URL du déclencheur. Kortix vérifie la signature, transforme la charge utile en prompt et démarre la session. Une charge utile qui échoue à votre filtre est acceptée puis ignorée.
Chaque déclencheur d’un projet tient sur une ligne : son nom, son heure de déclenchement, son fuseau horaire, l’agent utilisé et la session concernée. Rien n’est masqué dans un état interne auquel il faudrait accéder par un clic.
| Trigger | Cron | Timezone | Agent | Session |
|---|---|---|---|---|
| daily-digest | 0 0 9 * * 1-5Jours ouvrés à 09:00 | America/Los_Angeles | kortix | fresh |
| invoice-sweep | 0 30 6 1 * *Le 1er du mois à 06:30 | Europe/Berlin | finance | réutiliser |
| oncall-handoff | 0 0 17 * * 5Les vendredis à 17:00 | UTC | support | fresh |
| roadmap-review | 0 0 8 * * 1Les lundis à 08:00 | America/New_York | planner | épinglé |
Les déclencheurs résident dans kortix.yaml, à côté de vos agents et de vos images sandbox. Chacun indique son agent, sa planification ou son secret, ainsi que le modèle de prompt qui devient le premier message de la session.
# 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 startedUn prompt évalue {{ token.dotted.path }} par rapport à la charge utile qui l’a déclenché. Un webhook fournit {{ body.* }} et les en-têtes de la requête ; un déclenchement cron fournit {{ cron.schedule }}, {{ cron.timezone }} et {{ cron.scheduled_for }}. Une valeur absente produit du vide — aucune erreur ni accolade résiduelle dans le message lu par votre agent.
Chaque déclencheur webhook indique un secret de projet qui le signe. Un déclencheur sans secret est rejeté lors de la validation : il n’existe aucun webhook non authentifié que vous pourriez oublier de sécuriser plus tard.
POST /v1/webhooks/projects/{projectId}/{slug}
X-Kortix-Signature: sha256=<hmac>
HMAC-SHA256 calculé sur le corps brut de la requête et comparé en temps constant. L’en-tête X-Hub-Signature-256 compatible avec GitHub fonctionne également : un webhook de dépôt ne nécessite donc aucun adaptateur.
Un filtre est un chemin pointé comparé à la même charge utile que celle visible par le prompt. Il sert à interrompre les boucles : une source qui signale les deux côtés d’une conversation lancerait sinon l’agent sur sa propre réponse.
Par défaut, chaque déclenchement repart de zéro. Quand le travail se poursuit dans un fil existant plutôt que dans une nouvelle tâche, un déclencheur peut relancer une session qu’il possède déjà. Kortix essaie les modes dans l’ordre et passe au suivant en cas d’échec, afin qu’un déclenchement ne disparaisse jamais simplement.
Relancer une session précise, désignée par son id. Si cette session a disparu ou a échoué, passer au mode suivant.
Générer une clé à partir de la charge utile, puis relancer la session saine la plus récente portant exactement cette clé. Un client, un fil. Le système ne bascule jamais vers la session d’une autre clé.
Relancer la session saine la plus récente créée par ce déclencheur. Un déclencheur épinglé revient ici avant d’aller plus loin.
Créer une nouvelle branche et démarrer un nouvel ordinateur cloud. C’est le comportement par défaut et le dernier recours pour tous les autres modes.
Une session déclenchée est visible par tout le projet, et non uniquement par la personne qui a configuré le déclencheur. Elle s’arrête après 5 minutes d’inactivité : une automatisation lancée à 3 h du matin ne facturera donc pas une machine jusqu’au matin.
Une automatisation n’obtient aucun privilège qu’une personne n’aurait pas. Même isolation, même portée limitée, même unique voie de retour vers main.
Commencez par une tâche et développez à partir de là.