Skip to main content
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

Agent

Runs one of your agents.

Human

An approve / input gate that blocks the run until a person decides.

Wait (time)

Pauses for a number of seconds, or until a set timestamp.

Wait (poll)

Checks a condition on an interval and repeats until it’s met.

Verify

A mechanical check — an HTTP GET or a database row lookup. No AI.

Notify

Fires a message and continues immediately. Never blocks.

HTTP call

Makes an outbound HTTP request and checks the response.

​
Agent

Runs an agent as one step of the mission. 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 for the full approval flow.

​
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.

​
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.
  • {{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, with worked patterns in the Mission Recipes.