Skip to main content
Missions are orchestrated, multi-step workflows. These are the operating recipes — the tool sequence for each job an AI client is asked to do. The full tool reference is in Missions.
Always start from discovery: mission_list returns the mission IDs. Never guess a mission ID.

​
Explain a mission

Understand what a mission does before touching it. mission_list → mission_get (passport / manifest / genome / step summary) → mission_flow_get (the execution contract plus per-step agent previews).

​
Start safely

Validate before you run — mission_validate catches an inactive agent, an unresolved approver, trigger issues, and insufficient credits before any work happens. mission_get / mission_status → mission_validate → if healthy, mission_run → mission_status.

​
Diagnose a failure

mission_status (get the run id) → mission_run_trace_get (the failing step, attempts, receipts, timings, cost, tokens, and tool calls) → mission_artifact_get if the run produced an artifact.

​
Run control (human gates)

These are preview → confirm actions gated on a human decision. Show what the control will do and get explicit go-ahead before committing — see Writes & Safety.

​
Edit safely

Prefer draft governance over editing a live workflow in place: mission_draft_get / mission_draft_create → mission_draft_update → mission_change_proposal_preview → mission_validate → mission_draft_publish (or mission_draft_discard to abandon). When draft governance isn’t needed, mission_steps_update is the direct path — it supports list / add / update / remove / reorder on the step set.

​
Improve & compare

  • mission_analytics_get — success / failure per step, retries, durations, approval wait time.
  • mission_economics_get — cost, savings, net value, ROI.
  • mission_compare_versions — what changed in configuration between versions.
  • mission_compare_runs — what changed operationally between runs.

​
Step types

A mission is a sequence of typed steps:

​
Step contracts

Fields that govern how a step behaves:
  • require_receipts — the agent must actually use a tool (no hand-waving a result).
  • no_work_token — a clean exit when there is genuinely no work to do.
  • handoff_prompt — what passes to the next step.
  • output_schema — the shape the step must return.
  • step_key — a stable handle for the step.
  • on_fail — retry / stop / continue / loopback.

​
Membership & triggers

  • Membership roles — owner / lead / member / viewer. This is the visibility boundary: who can see and act on the mission.
  • Triggers — a mission can fire on a schedule or webhook, set via mission_update. These are separate from agent schedules — don’t confuse a mission trigger with an agent’s own schedule.
See Missions for the complete tool and field reference.