How Mobius works

Mobius runs AI agents and keeps the work around them: instructions, connected tools, conversations, repeatable processes, approvals, files, and records of what happened.

You do not need every Mobius feature to start. The useful first model is:

project
├── agents
│   └── sessions
│       └── turns in their conversations
└── loops
    ├── triggers
    ├── steps
    └── runs
        └── one record of what happened to each step when the loop starts

An agent can have many sessions. A loop can create many runs. A loop may use one agent, several agents, or no agent at all.

Projects keep work separate

A project is the main boundary for work in Mobius. It holds resources such as agents, loops, tables, connected accounts, and run history. Project roles decide who can see or change them.

If Northwind IT manages several clients, it can give Ridgeline Dental and Acme different projects. A loop in the Ridgeline project cannot read Acme's project data just because both projects belong to Northwind.

Some resources can be managed for the whole organization and then made available inside projects. The relevant concept page calls this out when it applies. Start with one project and add another only when its data or access must be separate.

Agents hold reusable behavior

An agent is a named AI worker inside a project. Its main settings answer four questions:

Assigning a toolkit to an agent makes its actions available as tools the agent may call. Mobius also provides built-in tools for features such as memory.

An agent's instructions apply wherever you use that agent. A loop step or a new message supplies the immediate assignment.

For example, Scout's agent instructions can say, "Write short client updates and do not invent missing facts." One loop can ask Scout to summarize backup notes. A conversation can ask Scout to rewrite a ticket reply. The reusable writing rules stay with Scout; the current request changes.

Keep the first agent narrow. It is easier to check an agent that has one clear role and a small set of tools.

Sessions record conversations

A session is the saved record of one conversation with an agent. It contains the messages and related agent activity needed for follow-up requests.

One request and the agent's response form a turn. A turn may include tool calls before the agent replies. Later turns in the same session can use earlier messages. A separate session starts with separate conversation history.

An agent step in a loop also adds a turn to a session. A session is identified by both the agent and a history key. Agent steps using the same agent and key share the earlier messages; a different agent or key uses a different session. The loop's History setting can give every run a fresh key or build a stable key from input such as a ticket number. The run records the loop process; each session records the messages exchanged with one agent.

Starting a session by itself does not create a loop run. Use a conversation when a person's next message should guide the work, such as a technician asking a follow-up question. Use a loop when the steps are known before the work starts.

Loops save a repeatable process

A loop answers three questions:

1. What starts the work?
2. Which steps should Mobius attempt, and in what order?
3. What limits should stop the work if it takes too long or spends too much?

A trigger answers the first question. Every loop can be started manually. You can also add a schedule, an event from a connected system, or an HTTP request from software you operate. You can add more than one automatic trigger. HTTP is the common way software sends a request over a network.

The information that starts the loop becomes the run's input. Steps can read that input, and later steps can also read results from earlier steps.

The saved loop describes the structure, not a guaranteed answer. Agent output can vary from one run to the next. "Repeatable" means Mobius starts from the same ordered steps and settings each time.

Editing a loop changes later runs. A run that has already started continues with the loop version it started with.

Steps separate thinking, action, and waiting

A step is one part of a loop. Steps normally run in order. A condition may skip a step, and a failed step may retry when you have configured retries.

Mobius supports these step types:

Each completed step saves its result under that step's name. A later step can use a result saved by an earlier step. If the loop selects particular values as its output, the run's Output tab shows those values. Otherwise, it shows the full set of saved step results. A skipped or failed step is still recorded, but does not have a successful result.

Separate thinking from actions that have outside effects. Let an agent step draft a reply. Let an interaction step ask a person to approve it. Let an action step send the approved reply. This makes the decision, approval, and send result visible as separate parts of the run.

A loop step is different from the other types: it starts a separate child run and immediately saves that run's ID and starting status. The parent does not wait for the child to finish. Open the child run to see its later result and limits.

Actions do one named thing

An action is a named operation, such as reading a ticket, posting a Slack message, or adding a row to a table. A toolkit is a saved selection of actions. Assigning that toolkit to an agent exposes its actions as tools the agent may call. Some built-in tools, such as agent memory, do not come from an integration action.

You can use an action in two ways:

• An action step calls it at a specific point in a loop. The call and result appear as that step on the run timeline.
• A tool lets an agent decide whether to call the action during an agent step. The call and result appear inside that agent's activity.

Giving an action to an agent does not add human approval. If the action sends, deletes, purchases, or changes something important, put an interaction step before the action or do not give that action to the agent. For an approval interaction, approval continues to the next step; rejection or expiry stops the run before that step.

Runs show what happened once

A run begins each time a loop starts. It records:

• what started the loop and the information that arrived with it;
• which steps started, finished, waited, retried, or failed;
• visible agent, tool, and action activity;
• results saved by the steps; and
• the final status and reason the run stopped.

A run does not expose a model's private chain of thought. It records the messages, visible activity, results, and decisions that Mobius receives.

While work is active, a run is queued or running. A suspended run is waiting for a timer, event, or answer. It is not finished and resumes when its waiting condition is met. Finished runs are completed, failed, or cancelled.

When a run fails, open the failed step first. Its error and earlier successful steps remain in the record. Depending on the failure, you can fix the loop and start a new run or resume the existing run from a supported recovery point. The run page shows the available recovery action.

Interactions add an explicit handoff

An interaction asks a named person or agent to provide information, review work, or approve a decision. It is optional. Work does not receive approval unless you add and target the interaction.

The run becomes suspended while it waits. The interaction records the request, who answered, their answer, and how the request was resolved. It may ask one or more people or agents; its response rule decides how many answers are required. Give every interaction a timeout and decide what should happen if nobody answers.

Limits stop unattended work

The app gives each newly created loop a ten-minute wall-clock limit for each run by default. The clock starts with the run and continues while it is queued, working, or suspended. You can change it. You can also set a spending budget for each run, a cap on agent turns, step timeouts, retry rules, and a threshold that pauses a loop after consecutive failed runs.

These limits cover different problems:

• A time limit stops a run that stays active too long.
• A spending budget stops additional work after recorded spend reaches the limit and Mobius checks it.
• A turn cap limits how many agent turns one run may start.
• A step timeout stops one attempt that takes longer than allowed.
• Retry rules limit how often a failed step is attempted again.
• The repeated-failure threshold pauses the loop so new automatic runs do not keep failing unattended.

When a limit stops work, the run records the limit-specific reason it stopped. A waiting step should also have its own timeout so the error identifies that wait, rather than leaving the run to reach its wider wall-clock limit.

See guardrails for the available limits and what each one measures.

Add other features when the need appears

You can build a useful first loop with one agent step and a manual start. Add the rest when you can name the problem it solves:

Start with one manual run

The quickstart creates one agent, one loop, one agent step, and one manual run. It supplies facts you can check and gives you a clear result to inspect.

Once that works, connect a real source of input. Add approval before an outside action when a wrong result would matter. Add an automatic trigger last.