Build

A loop is a reusable description of work that Mobius can run on demand or in response to something happening.

Use a loop when a successful agent experiment should become repeatable. A pull request review, morning brief, account-enrichment pass, or approval process is easier to operate when its start, major decisions, side effects, and result are visible in one place.

The loop is the plan. A run is one execution of that plan. Editing the loop changes future runs without changing the history of work that already happened.

What a loop helps you express

Every loop answers four questions:

That structure is useful even for short work. It separates an agent's judgment from exact side effects and makes the boundary between them visible.

Start with a manual trigger and one agent step. Add an action only when the loop needs to change another system. Add waits, approvals, and automation after the basic result is worth repeating.

Loops and agent messaging

Loops and agent messaging are two different ways to use the same agents.

A loop can still use an agent session for history. The run remembers process progress; the session remembers conversation context.

Design the steps around responsibility

Good loops have a small number of meaningful steps. Each boundary should tell an operator what kind of responsibility moved:

• Use an agent step for judgment, synthesis, or flexible tool use.
• Use an action step for an exact side effect.
• Use a check when evidence must be evaluated before continuing.
• Use a wait when time or another system owns the next move.
• Use an interaction when a person or agent must answer, review, or approve.

For example, a pull request loop might have three steps: draft a review, ask a person to approve it, and post the approved review. That is easier to inspect and change than one prompt that tries to do all three jobs.

Declared inputs

Inputs describe what a caller must provide without tying the loop to one start path. A manual run, an HTTP request, and a product backend can all provide the same account ID, repository, or topic.

Declare only values that are part of the loop's public contract. Information that comes from an event stays with the event. Results from earlier work stay with the step that produced them.

In later steps, Mobius makes the run's inputs, triggering event, metadata, and prior step outputs available as context. Give important steps stable names so their results remain understandable when the loop grows.

Triggers start runs

A loop can start manually, on a schedule, from a provider event, or through an inbound HTTP request. These are different entry points into the same process, not different kinds of loops.

Begin with a manual trigger while you are shaping the result. Choose the production trigger after you know who or what should own the start:

Title and describe each run

Give runs titles that help an operator recognize the subject, such as “Review pull request #418” or “Enrich account Acme.” Add a short description when the title needs context such as a repository, customer, or source system.

Run names should identify the work, not restate its status. The run page already shows whether it is active, waiting, failed, or complete.

Make the result explicit

A declared output gives the loop a stable result even when its internal steps change. Use it for the small structured value that another system or person cares about: a classification, decision, summary, or set of identifiers.

Use an artifact when the result is a file or needs to be retained and downloaded. Use step output for intermediate values that only later steps need.

Concurrency policy

Concurrency answers a product question: what should happen if new work arrives while this loop is already active?

Start with overlap for independent event-driven work. Choose a stricter policy when the loop shares a scarce resource, processes an ordered stream, or makes older work obsolete.

History and limits

An agent step may start fresh or reuse a session tied to a pull request, customer, incident, or other stable subject. Reuse history when earlier agent work genuinely improves the next run. Start fresh when each result should be independent.

Every unattended loop also needs bounds. Time limits, retry limits, budgets, checks, and approval gates keep a bad input or stalled dependency from turning into open-ended work. The guardrails guide explains how to choose them.

Work with loops in the app

Open Build > Loops to create a loop. Add the smallest useful steps, keep the manual start path, and run it once. The editor shows which parts are ready before you start.

After the run finishes, inspect its timeline and output before adding another trigger or step. A short loop you understand is a better foundation than a complete process you have not observed.

Saving a loop makes the new definition available to future runs. Pause the loop before a risky change when schedules or events could start work while you edit it.

Use the CLI command reference for terminal authoring and the interactive API reference for application code and exact fields.

Next

• Choose a start path with triggers.
• Choose responsibilities with steps.
• Inspect one execution with runs.
• Add safety bounds with guardrails.