Build

A loop is a saved sequence of steps. You can start it yourself, start it on a schedule, or start it when an event arrives.

Each time a loop starts, Mobius creates a run. The run records which steps started, what they returned, and where the process stopped or completed.

The loop is the saved plan. A run is one use of that plan.

Create and verify a small loop

Select the project where you want the loop. You also need an agent. If the project does not have one, follow Create your first agent first.

Then create the loop:

1. Open Build > Loops.

2. Click Create a loop.

3. Click the editable Untitled loop heading and rename it Client update checklist.

4. In the existing Agent step, choose your agent.

5. Replace the step instructions with:

   Write a three-item checklist for reviewing a client update before it is sent. Do not call actions or claim that you sent anything.

6. Leave the settings at their defaults and click Create.

Mobius opens the saved loop. The confirmation reads Client update checklist is ready. A new custom loop starts with one agent step, no automatic trigger, a 10-minute time limit, and Queue selected for overlapping runs. The Manual run card confirms that the Run button and API remain available.

Click Run. Mobius opens the run page, which updates while the run is active. Wait for the status to become Completed, then inspect the Agent entry in the Timeline.

The first test passes when:

• the agent reply contains three checklist items;
• the timeline does not show an action call; and
• the reply does not claim that anything was sent.

Completed means the loop reached the end of its steps. It does not prove that the agent's answer was useful, which is why you must inspect the reply.

Read the run page

The default app editor keeps the step results, so begin with the Timeline when checking an agent reply. API and CLI authors can define a smaller output for another system to consume.

Test with event data

An event is a JSON object supplied when a run starts. It can contain the ticket, account, alert, or other subject that the loop should process.

To try one:

1. Click Edit loop.

2. Change the Agent step instructions to:

   Reply with Received ticket NUMBER, using the ticket number in ${{ event.ticket.number }}. Do not call actions.

3. Click Save changes.

4. Open the menu beside Run and choose Run with event.

5. Replace the Event JSON with:

   {
     "ticket": {
       "number": 4182
     }
   }

6. Click Run with event.

The run's Event tab should show the object you entered. The Agent entry in the Timeline should contain Received ticket 4182. The regular Run button supplies an empty event, so use Run with event when the instructions refer to an event field.

Add steps after the first result works

To add a step, click Edit loop, use Add step, configure the new card, and click Save changes before running the loop again. Unsaved editor changes do not affect runs.

Separate deciding from doing. An agent step can decide what a reply should say. A later action step can send it. This gives you a clear place to inspect or check the result before an external system changes.

The app's Add step menu includes:

Available actions depend on the project's integrations and action catalog. The Steps page explains how later steps refer to event data and earlier step results. The API also supports an Interaction step for requesting information, review, or approval.

An external action can succeed even if a later part of the run fails. Before retrying a send, update, or create operation, inspect the destination and the run timeline for evidence that it already happened. Cancellation and retries do not undo an external change.

Add an automatic trigger later

Manual runs remain available after you add an automatic trigger. Use manual runs to test edits without waiting for a schedule or event.

For a simple schedule:

1. Click Edit loop.
2. Under Triggers, click Add trigger > Schedule.
3. Choose the frequency, time, and timezone.
4. Turn off the trigger's Enabled switch if you are not ready for automatic runs.
5. Click Save changes.

The loop page lists the saved schedule under Triggers. To turn it on later, edit the loop, switch it to Enabled, and save again. Saving the loop is the boundary that applies trigger changes.

Event and HTTP triggers need information from another system. Follow Triggers for their setup and test procedures.

Decide what happens when runs overlap

The concurrency setting applies to the whole loop, regardless of how each run started.

Queue is the default. Keep it when runs change shared data or must stay in order. A queued run keeps the loop version and event captured when it was created.

Use Parallel only when the runs are independent. Use Skip when one active copy is enough. Use Replace when new information makes the older run obsolete. Replace cannot undo an external action that already completed.

Set limits before automatic work begins

The default time limit is 10 minutes of wall-clock time. For a queued run, the clock starts when that run leaves the queue and begins. Once started, time spent waiting or suspended counts toward the limit.

Increase the limit when the process is expected to wait longer. Also review the Budget and maximum agent-turn settings in the loop editor. See Guardrails before allowing a schedule or event to start work without a person present.

Edit history stays attached to runs

Click Edit loop, make the change, and click Save changes. Saving creates a new version of the loop definition.

Each run captures the saved version that exists when the run is created. That includes a run waiting in the queue. Later edits do not change that run's steps, event, or timeline. New runs use the newly saved version.

When messaging fits better

Use agent messaging when a person's next message should decide what happens next. Use a loop when you need named steps, limits, waits, or a separate record for each occurrence.

One agent can support both. A person can chat with an agent for an open-ended question and a loop can use the same agent for a defined step.

Starting another loop

A Trigger loop step starts a child run. Its Timeline entry records the child run ID, and the parent step completes after the child starts. The parent does not wait for the child to finish.

Use this for shared work that can continue independently. If later parent steps need the child's final result, keep the required work in the parent or design an explicit wait using the Steps reference.

Terminal authoring is in the CLI command reference. Exact fields are in the interactive API reference.

Next

• Configure other automatic starts with triggers.
• Learn how steps share data in steps.
• Read one execution in runs.
• Add limits and checks with guardrails.