Skip to main content
This page covers two things that happen around a mission’s steps: how a mission starts on its own (triggers), and how you change a live mission safely (drafts).

​
Triggers — starting a mission automatically

A mission can fire without anyone clicking Run. Triggers are configured in Settings › Triggers, and a mission can use a schedule, a webhook, or both.
Mission triggers are separate from agent schedules. An agent can have its own schedule for its own runs — that has nothing to do with a mission trigger. A mission trigger starts the whole mission. Don’t expect one to drive the other.

​
Schedule trigger

Run the mission on a cron schedule — a standard 5-field cron expression, evaluated in the mission owner’s timezone. Use it for anything recurring: a weekday morning report, an hourly check, a monthly summary.
Pair a schedule with a no-work token on the first agent step (see Flow & Steps) so a scheduled mission stays quiet on days when there’s nothing to do, instead of sending an empty digest.

​
Webhook trigger

Let an outside system start the mission by calling a webhook URL that contains a secret. When it fires, the incoming payload lands in the run context, so the mission’s first step can read it — for example, a new order or form submission that kicks off the flow.
  • Secret in the URL — the secret is what authorizes the call. Keep the URL private; rotate the secret if it leaks.
  • Payload in context — step 1 can reference the incoming data through the mission’s variables and templating.

​
Duplicate policy

Because a webhook can fire more than once for the same thing, a mission has a duplicate-subject policy to avoid processing the same business subject twice:
Use reject when re-processing the same order, ticket, or record would cause harm (a double charge, a duplicate email). Use allow when repeats are legitimately independent events.

​
Drafts — changing a live mission safely

You don’t edit a running mission in place. Bigger changes go through a draft: a private working copy you shape, preview, and validate before it goes live — with a version captured so you can always roll back.
1

Create a draft

Cut a draft from the live configuration. The live mission keeps running untouched while you work on the copy.
2

Update the draft

Make your changes — steps, contracts, variables, triggers — on the draft.
3

Preview the change

A change-proposal preview shows exactly what will differ between live and the draft before anything is committed.
4

Validate

Run pre-flight validation on the draft (agents assigned, approvers set, webhook secret present, enough credits, ordering proven) — read-only, no runs. See Build › Test.
5

Publish or discard

Publish to make the draft live — this captures a version first so you can compare or roll back — or discard to throw the draft away and leave live as it was.
Publishing is refused while a run is active. Finish, pause, or cancel the current run first. This guarantees a run always executes one consistent version of the mission from start to finish — the flow can’t change under a run that’s already going.
Every publish snapshots the previous configuration, so Versions (in Build) always has a clean history to diff and restore from.
From an AI client, the draft flow is mission_draft_create → mission_draft_update → mission_change_proposal_preview → mission_validate → mission_draft_publish (or mission_draft_discard). See the Missions API reference and Mission Recipes.