Automating work
How to run a session on a schedule or from an event using triggers.
Triggers start a session on its own, with no one watching. A triggered session works like any other: the agent does the work, proposes a change request, and waits for review.
Two ways to trigger a session
- On a schedule — run at fixed times. Good for a Monday-morning summary or end-of-day report.
- From an event — run when something happens elsewhere, delivered as a signed webhook.
A scheduled example
Triggers live in your project's manifest (kortix.yaml) as triggers entries. This one runs every weekday morning and writes a digest:
triggers:
- slug: daily-digest
name: Daily digest
type: cron
enabled: true
cron: "0 0 9 * * 1-5"
timezone: America/Los_Angeles
prompt: |
Summarize yesterday's activity and save it as a daily note.(Legacy kortix.toml declares the same thing as [[triggers]], an array of tables with the same fields.)
When the schedule fires, Kortix starts a fresh session and gives the agent the prompt as its first message.
Changes take effect after they're merged
A trigger lives in the manifest, so adding or editing one is a change to your project. It goes live only once it's merged onto your main line: edit the manifest, review and merge, then the trigger runs.
Under the hood
cron is a 6-field expression (second minute hour day month weekday); timezone is an IANA name. Webhook triggers fire on signed POST requests and must reference a signing secret by name (secret_env) — there's no unauthenticated webhook surface. By default (session_mode: "fresh"), each fire spawns a new session on its own branch; set session_mode: "reuse" to instead re-prompt the trigger's existing session, resuming its sandbox and branch so one long-lived session accumulates context across fires. See the triggers reference.