> ## Documentation Index
> Fetch the complete documentation index at: https://agents.concierca.ch/llms.txt
> Use this file to discover all available pages before exploring further.

# Mission Recipes

> Operating recipes for missions: explain, start safely, diagnose, control, edit, and compare.

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](/for-agents/missions).

<Note>
  Always start from discovery: `mission_list` returns the mission IDs. Never guess a mission ID.
</Note>

## 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)

| Action         | Tool                      | Effect                                   |
| -------------- | ------------------------- | ---------------------------------------- |
| Pause          | `mission_pause`           | Reversible — stops before the next step  |
| Resume         | `mission_resume`          | Continues from the first unfinished step |
| Cancel         | `mission_cancel`          | Terminal — the run ends                  |
| Unblock budget | `mission_budget_increase` | Releases a run parked on budget          |

<Warning>
  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](/for-agents/ai/writes-and-safety#the-human-gate).
</Warning>

## 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:

| Type        | What it does                                                        |
| ----------- | ------------------------------------------------------------------- |
| `agent`     | Runs an agent (config includes `require_receipts`, `no_work_token`) |
| `human`     | Approval or input from a person                                     |
| `wait_time` | Waits a fixed duration                                              |
| `wait_poll` | Waits until a condition is met                                      |
| `verify`    | Checks a condition before continuing                                |
| `notify`    | Sends a notification                                                |

## 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-agents/missions) for the complete tool and field reference.