> ## 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.
# Flow & Steps
> The step editor and the seven step types, step contracts, the 20-step limit, and variables & templating.
The **Flow** tab is where a mission's chain of steps lives. It is drawn as a horizontal track — **Trigger → step → step → … → Complete** — above an editable step list. This is the heart of a mission: the steps run **strictly in order, one at a time**, and step *n+1* only starts when step *n* succeeds.
## The step editor
* **Add step** at the bottom of the list opens the step-type picker.
* **Drag** a step by its handle to reorder it.
* The **pencil** opens a step to edit its configuration; the **trash** deletes it.
* **Inspect** on an agent step opens the step inspector — the agent's mandate, tools & apps, data access, knowledge, memory, permissions, budget, typed inputs/outputs, and per-mission performance, with a link to the agent's own page.
A mission can hold at most **20 steps**. That is plenty for real workflows and keeps a run readable and affordable. If you're bumping into the limit, it's usually a sign the mission should be split in two.
## The seven step types
Runs one of your agents.
An approve / input gate that blocks the run until a person decides.
Pauses for a number of seconds, or until a set timestamp.
Checks a condition on an interval and repeats until it's met.
A mechanical check — an HTTP GET or a database row lookup. No AI.
Fires a message and continues immediately. Never blocks.
Makes an outbound HTTP request and checks the response.
### Agent
Runs an agent as one step of the mission.
| Option | Meaning |
| -------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Agent** | Which agent runs this step. |
| **Require receipts** | The agent's answer only counts if it actually made **at least one tool call**. A pure text reply with no tool use fails the step. Use it when the step must *do* something, not just talk about it. |
| **No-work token** | A word the agent may return as its last line to say *"nothing to do this time"*. When it does, the run ends **silently** — no owner digest. This is the basis for scheduled missions that should stay quiet on empty days. |
An agent step costs exactly **1 credit**. An agent used as a decision gate can end its answer with `VERDICT=READY` to pass the step or `VERDICT=FAILED` to fail it.
### Human
Pauses the run and asks a person to decide. See [Running & Approvals](/guide/mission-runs) for the full approval flow.
| Option | Meaning |
| ------------------ | ----------------------------------------------------------- |
| **Approver** | Who is asked to decide. |
| **Instruction** | What you want them to check or provide. |
| **Notify** | Where the request is pushed — in-app inbox and/or Telegram. |
| **Deadline** | How long they have before it's overdue. |
| **Return-to-step** | Where the run goes back to if they reject. |
### Wait (time)
Pauses the run for a fixed **number of seconds**, or **until a specific timestamp**. Nothing runs while it waits.
### Wait (poll)
Repeatedly checks a condition: wait an **interval**, run a **probe**, and repeat up to a **maximum number of attempts**. Use it to wait for something to become true — a file to land, an order to ship — without a fixed delay.
### Verify
A **mechanical** pass/fail check with **no AI involved**: either an **HTTP GET** (does this URL respond as expected?) or a **database row check** (does this record exist / have this value?). Cheap, deterministic, and honest.
### Notify
Sends a **fire-and-continue** ping and moves on immediately. A notify step **never blocks** the run — use it to keep people informed mid-flow without waiting for a reply.
### HTTP call
Makes an outbound HTTP request to a system of your choice.
| Option | Meaning |
| ---------------------------- | ----------------------------------------------------------------------------- |
| **URL / Method** | The endpoint and verb (GET, POST, …). |
| **Headers / Body** | What to send. |
| **Expect status / contains** | The response is checked against an expected status code and/or expected text. |
| **Timeout** | Up to **60 seconds**; the step fails if the call runs long. |
## Step contracts
Contracts are the small rules that make a step *trustworthy* — they decide when an output is allowed to count and what happens when it doesn't.
An agent's answer only passes if it made **at least one real tool call**. No tool calls → the step fails. This stops an agent from *claiming* it sent the email when it never did.
If the agent's last line is exactly the configured token, the run **ends silently** with no owner digest. Scheduled missions use this so they only speak up when there's actually something to report.
You can require a step's output to match named, typed fields — `{ fields: [{ name, type, required }] }`. The output is **validated** on every run; if it doesn't match, the step fails rather than passing bad data downstream.
Each step carries a **handoff prompt**: the trusted instruction *you* wrote for that step. The previous step's output is passed in as **fenced, untrusted DATA** — the agent treats it as material to work on, never as new instructions. This is what keeps one step's output from hijacking the next.
Each step's **On failure** setting decides what happens when it fails:
* **Retry once, then stop** — try one more time, then stop the run.
* **Stop immediately.**
* Optionally **loop back** to an earlier step and try the sequence again, up to a maximum number of iterations (**default 3**).
When the loopback cap is reached, the mission doesn't spin forever — it **auto-escalates to the owner** as a human step so a person can decide what to do.
## Variables & templating
Steps don't work in isolation — they can read mission variables and each other's output.
* **Step key** — give a step a short `step_key` so later steps can reference it.
* **`{{vars.key}}`** — insert a mission variable (a static value or a connection reference; secrets stay hidden). Variables are managed in [Build › Variables](/guide/mission-build).
* **`{{steps.key.output.field}}`** — insert a field from an earlier step's (contracted) output.
Templating is how, for example, step 1 fetches an order id and step 3 uses `{{steps.fetch.output.order_id}}` in its handoff prompt — the chain passes data forward cleanly, and the output schema guarantees the field is really there.
Building missions from an AI client? The exact tools for editing the flow — `mission_steps_update`, `mission_flow_get` — are in the [Missions API reference](/for-agents/missions), with worked patterns in the [Mission Recipes](/for-agents/ai/mission-recipes).