Un trigger avvia una sessione senza la presenza di una persona. Una pianificazione cron la attiva all’orario stabilito; un webhook firmato la attiva in risposta a un evento. In entrambi i casi l’agente ottiene il proprio computer cloud, il proprio branch e la stessa revisione al ritorno.
Il primo giorno del mese alle 06:30
0 30 6 1 * *
Un trigger è un orologio o una firma. Tutto il resto — con quale agente viene eseguito, cosa comunica e in quale sessione confluisce — è la stessa configurazione in entrambi i casi.
Un’espressione cron a 6 campi — secondo, minuto, ora, giorno, mese, giorno della settimana — in qualsiasi fuso orario IANA. Oppure un singolo timestamp run_at, per qualcosa che deve accadere una volta sola e poi restare inattivo.
Un servizio esterno invia una POST all’URL del trigger. Kortix verifica la firma, inserisce il payload nel prompt e avvia la sessione. Un payload che non supera il tuo filtro viene accettato e ignorato.
Ogni trigger di un progetto è una riga: come si chiama, quando si attiva, nel fuso orario di chi, con quale agente e in quale sessione confluisce l’attivazione. Nulla è uno stato nascosto da aprire con un clic.
| Trigger | Cron | Timezone | Agent | Session |
|---|---|---|---|---|
| daily-digest | 0 0 9 * * 1-5Giorni feriali alle 09:00 | America/Los_Angeles | kortix | fresh |
| invoice-sweep | 0 30 6 1 * *Il primo giorno del mese alle 06:30 | Europe/Berlin | finance | reuse |
| oncall-handoff | 0 0 17 * * 5Venerdì alle 17:00 | UTC | support | fresh |
| roadmap-review | 0 0 8 * * 1Lunedì alle 08:00 | America/New_York | planner | pinned |
I trigger risiedono in kortix.yaml insieme agli agenti e alle immagini sandbox. Ognuno indica il proprio agente, la pianificazione o il segreto e il modello di prompt che diventa il primo messaggio della sessione.
# 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 interpreta {{ token.dotted.path }} rispetto al payload che lo ha attivato. Un webhook fornisce {{ body.* }} e gli header della richiesta; un’attivazione cron fornisce {{ cron.schedule }}, {{ cron.timezone }} e {{ cron.scheduled_for }}. Un valore assente viene interpretato come nulla: nessun errore e nessuna parentesi residue nel messaggio letto dall’agente.
Ogni trigger webhook indica un segreto di progetto con cui firmarlo. Un trigger senza segreto viene rifiutato durante la validazione: non esiste un webhook non autenticato da dimenticare di proteggere in seguito.
POST /v1/webhooks/projects/{projectId}/{slug}
X-Kortix-Signature: sha256=<hmac>
HMAC-SHA256 calcolato sul corpo grezzo della richiesta e confrontato in tempo costante. Funziona anche l’header X-Hub-Signature-256 compatibile con GitHub, quindi un webhook del repo non richiede alcun adapter.
Un filtro è un percorso puntato confrontato con lo stesso payload visualizzato dal prompt. Serve a interrompere i loop: una sorgente che segnala entrambi i lati di una conversazione altrimenti avvierebbe l'agente sulla propria risposta.
Per impostazione predefinita, ogni avvio parte da zero. Quando il lavoro è un thread in corso anziché un'attività nuova, un trigger può inviare un nuovo prompt a una sessione che già possiede. Kortix prova le modalità in ordine e passa alla successiva in caso di errore, così un avvio non scompare mai semplicemente.
Invia un nuovo prompt a una sessione specifica, indicata dall'id. Se la sessione non esiste più o ha avuto esito negativo, passa alla modalità successiva.
Genera una chiave dal payload, poi invia un nuovo prompt alla sessione sana più recente contrassegnata con quella chiave esatta. Un cliente, un thread. Non passa mai alla sessione di un'altra chiave.
Invia un nuovo prompt alla sessione sana più recente creata da questo trigger. Un trigger appuntato ripiega qui prima di passare oltre.
Crea un nuovo ramo e avvia un nuovo computer cloud. È l'impostazione predefinita e l'ultima risorsa per ogni altra modalità.
Una sessione attivata è visibile all'intero progetto, non è privata di chi ha configurato il trigger. Si arresta dopo 5 minuti di inattività, così un'automazione avviata alle 3 di notte non continua a generare costi fino al mattino.
Un'automazione non riceve privilegi che una persona non avrebbe. La stessa separazione, lo stesso accesso limitato, l'unica stessa strada verso main.