Reference

Steps

A step is one ordered part of a loop. A loop is the saved plan. A run is one execution of that plan.

Mobius records each step separately. On the run timeline, you can see when the step started, whether it waited or retried, and how it finished. This makes a failure easier to locate than one long agent instruction that reads, decides, and changes an outside system all at once.

Steps in one loop run in order. A Trigger loop step is the exception: it starts a separate child run and the parent continues without waiting for that child to finish.

Try one harmless step

You need a project where you can create and run loops. This test does not need an agent or an integration.

Open Build > Loops and select New loop.
Name the loop Step walkthrough.
Remove the Agent step that appears in the new loop.
Select Add step > Sleep and set the duration to 1 second.
Select Create, then select Run on the loop page.

Mobius opens the new run. The run should reach Completed, and its Timeline tab should show one completed Sleep step. If it does not, open the step on the timeline to see the error before changing the loop.

This is the smallest useful check that a step was saved, a run used it, and the timeline recorded it.

The seven step kinds

The app's Add step menu currently shows six kinds. The API also supports an Interaction step for work that must wait for a person.

App label	Use it when	What happens
Agent	A model needs to read, decide, or write	The selected agent follows the step instructions. The step can inherit the loop's agent.
Run action	One known action should run	Mobius calls the selected catalog action with the inputs you provide.
Check	A result must pass recorded assertions	Mobius evaluates expressions or uses a reviewer agent. On failure, it can fail the run, continue, or wait at a gate.
Sleep	Work should pause for a fixed time	The run becomes suspended until the time passes.
Wait for event	Work should pause until a matching event arrives	The run becomes suspended and resumes with the event.
Trigger loop	Another loop should start	Mobius creates a child run and records its ID. The parent does not wait for the child result.
Interaction	A person must approve or answer	The API creates an interaction and suspends the run until it is resolved or expires. This kind is not yet in the app's Add step menu.

Choose boundaries you can operate

Start with one Agent step when you are still learning what the job needs. Split it when the boundary gives you a useful control or a useful fact on the timeline.

A strong default is to separate deciding from changing an outside system:

Agent: Draft the reply.
Check or Interaction: Verify it or ask for approval when needed.
Run action: Send the approved reply.

This separation lets you tell a bad draft from a failed send. It also gives you a place to approve the work before the external action. It does add another checkpoint, so use it for meaningful boundaries rather than every line of an instruction.

Isolate any action that is hard to reverse, not only customer messages. That includes changing a record, deploying software, purchasing something, or deleting data.

Results and references

When a step finishes, its result is saved with the run. Later steps can use that result. Agent steps also receive the run event, routing metadata, run configuration, and results from earlier steps as context.

Keep results small and explicit. For example, a classification step might return an urgency, category, and owner instead of a long explanation. Smaller results are easier to inspect and less likely to break a later action.

When authoring through the API or CLI, use a stable step id for references. A display name is optional and appears on the timeline. For example:

steps:
  - id: classify
    name: Classify the ticket
    kind: agent
    config:
      instructions: Return the urgency and a one-sentence summary.
 
  - id: pause
    name: Pause before the next step
    kind: sleep
    config:
      duration: 1s

This is a step fragment, not a complete loop file.

Text fields can insert values with ${{ ... }}:

text: "Ticket ${{ event.ticket.number }} is ${{ steps.classify.output.urgency }}."

Available roots are:

Root	Contains
`event`	The event object that started the run
`meta`	Trigger source and routing details
`config`	Configuration resolved when the run started
`steps.<id>.output`	The saved result from an earlier step

You cannot refer to a later step. A missing path fails the step instead of quietly inserting an empty value. Open a test run's Event, Meta, and Output tabs to inspect the actual shapes before writing references.

Conditions

A condition skips a step when its expression returns false. Use conditions for rules you can state directly, such as “only for high-urgency tickets.” Put subjective decisions inside an Agent or Check step.

The app currently exposes a condition on Trigger loop steps. The API and CLI support if on every step:

if: steps.classify.output.urgency == "high"

The if value is an expression, not a text template, so it does not need ${{ ... }}. A skipped step remains visible on the timeline and has an empty result.

Waiting and time limits

Sleep, Wait for event, and Interaction steps suspend a run. No step is actively executing while the run is suspended, but the loop's wall-clock limit still counts after the run has started. Check Time limit in the loop settings and make it long enough for the expected wait.

A Sleep step ends at its configured time. For API-authored Wait for event and Interaction steps, also set a step timeout or interaction expiry so an event or answer that never arrives cannot leave the run suspended indefinitely.

Checks: proving it rather than believing it

A Check step records one or more assertions. In the app, each assertion can be:

Expr: a direct expression over the run data and prior step results.
Judge: a prompt evaluated by the built-in reviewer or a selected agent.

Place the Check after the step that produces evidence and before the step that acts on it. Under On fail, choose:

Fail run to stop immediately.
Continue to record the failed check and keep going.
Gate to suspend the run until a selected reviewer decides.

Prefer direct evidence where possible: a returned record, exit code, or artifact is stronger than asking the same agent whether its own work was good. See Guardrails for complete examples.

Retries and side effects

The API and CLI can add retry and timeout policies to a step. retry.max_attempts is the total number of attempts, including the first one. Retries are useful for transient failures, but they are unsafe when the first attempt may have succeeded outside Mobius.

Before retrying an action that sends or changes something:

Check the outside system for the intended result.
Use the provider's idempotency or duplicate-protection feature when it has one.
Do not add automatic retries when an ambiguous response could repeat the side effect.

Mobius can stop waiting for an action response; it cannot recall a message or undo a record change that the provider already accepted.

API and CLI fields

Most app users can stop here. For direct authoring, each item in steps has a kind and config. It can also have id, name, if, retry, and timeout.

Kind	Required configuration
`agent`	`instructions`; the agent can come from the step or loop default
`action`	`action_name`; action inputs go in `parameters`
`check`	`checks`
`sleep`	`duration` or `until`
`wait_for_event`	`event_type`
`interaction`	`protocol` and `targets`
`loop`	`loop_id`

An action may also set execution_location to managed, worker, or environment when the catalog action supports that location. The app shows the available choices after you select an action.

See the interactive API reference for the complete loop schema, expression helpers, per-kind outputs, and create/update requests. Use the CLI command reference for file-based commands and their authentication prerequisites.

Assemble and test the whole job with loops.
Read the recorded execution with runs.
Define when work starts with triggers.
Add limits and evidence checks with guardrails.