How Mobius works
Mobius runs AI agents and keeps the work around them: instructions, connected tools, conversations, approvals, files, and records of what happened.
You do not need every Mobius feature to start. The useful first model is:
organization
└── agents
└── sessions
├── turns (one request and the agent's response)
└── routines (turns the agent takes on a schedule)An agent can have many sessions. A session can have many turns. A routine adds turns to the session it was created in.
The organization holds the work
An organization is the boundary for work in Mobius. It holds resources such as agents, sessions, tables, connected accounts, and the record of what agents did. Roles decide who can see or change them.
If Northwind IT manages several clients, it can give Ridgeline Dental and Acme their own organizations. An agent in Ridgeline's organization cannot read Acme's data, and each organization has its own administrators, membership, and billing.
Inside one organization, a single agent can still be narrowed to a few named people or to one person. See who an agent is for.
Agents hold reusable behavior
An agent is a named AI worker. Its main settings answer four questions:
| Question | Mobius setting |
|---|---|
| How should it behave? | Instructions |
| Which AI should answer? | Model, such as Claude or GPT |
| What may it do or look up? | Tools, which are the actions the agent may call |
| What facts should it keep for later? | Agent memory |
Granting an action to an agent makes it available as a tool 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. Each 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 conversation can ask Scout to summarize backup notes. Another 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.
The same session is reachable from every doorway: the Mobius app, Slack, Telegram, email, or your own software. A conversation that started in Slack is the same session you can read in the app. See agent messaging.
A session is where you look to answer operational questions:
- What was the agent asked, and what did it answer?
- Which tools did it call, and what came back?
- Did a turn fail, and why?
- What did the work cost?
The session records what Mobius and its tools report. For an important external change, also verify the result in the outside system. A successful API response does not prove, for example, that a person read a message.
Turns show what happened once
A turn begins each time someone, or a routine, sends the agent a request. It records the request, the agent's visible activity, the tool calls and their results, the reply, and the reason the turn stopped.
A turn 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 turn is queued or running. A turn that is waiting
for a timer, an event, or an answer to an interaction
is waiting. It is not finished and resumes when its waiting condition is met.
Finished turns are completed, failed, or cancelled.
When a turn fails, its error stays in the transcript alongside every earlier message. Fix what caused it and send the next message; the session keeps the history either way.
Routines repeat work on a schedule
A routine is agent work that repeats, or that runs once at a future time, and returns to the conversation where you asked for it.
You ask for one in the conversation itself ("check this every weekday at 8am") and the agent proposes a routine: the instruction it will repeat, the schedule, who sees the result, which connections it may use, and the most it may spend. Nothing is scheduled until a person approves that proposal.
Each occurrence adds an ordinary turn to the same session, so the routine's
work reads like the rest of the conversation. The routine's occurrence list
records every fire: completed, failed, skipped, or missed. You can
pause, resume, edit, or cancel a routine without changing the session or agent
it belongs to.
A routine has two spending ceilings: one for a single occurrence, and a rolling 24-hour one across all of them. An occurrence that reaches its per-occurrence ceiling stops there and is recorded, rather than continuing to spend.
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. An agent holds its own selection of actions, which is what exposes them as tools it may call. Some built-in tools, such as agent memory, do not come from an integration action.
The agent decides whether to call an action during a turn. The call and its result appear inside that turn's activity.
Giving an action to an agent does not add human approval. If the action sends, deletes, purchases, or changes something important, either withhold that action or instruct the agent to open an interaction before calling it.
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 an interaction is opened and targeted.
The turn becomes waiting while the interaction is open. 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
Every agent turn has a wall-clock limit of ten minutes by default, adjustable per agent and per turn. The clock starts with the turn and continues while it is queued, working, or waiting.
Alongside it:
- A routine's per-occurrence ceiling stops one occurrence once recorded spend reaches the limit.
- A routine's rolling 24-hour ceiling stops further occurrences after the day's spend reaches the limit.
- An organization's usage limits stop work when the org or a person exhausts their allowance.
- A waiting interaction's own timeout resolves it, rather than leaving the turn to reach its wider wall-clock limit.
When a limit stops work, the turn records the limit-specific reason it stopped.
See guardrails for the available limits and what each one measures.
Add other features when the need appears
You can do useful work with one agent and one conversation. Add the rest when you can name the problem it solves:
| Need | Feature |
|---|---|
| Bring in or change data in another service | Integrations and actions |
| Keep facts for one agent across later work | Agent memory |
| Share rows that people and agents can edit | Tables |
| Keep a report, image, or other produced file | Artifacts |
| Run tools or models on a machine you control | Workers |
| Control what each person or piece of software may do | Organizations and access |
Start with one conversation
The quickstart creates one agent and asks it one question you can check. It gives you a clear result to inspect before anything runs unattended.
Once that works, connect a real source of input. Ask for approval before an outside action when a wrong result would matter. Add a routine last.