Learn
How Mobius works
Mobius gives you two ways to put an agent to work: keep a conversation going, or define a process that can run without a conversation.
Use agent messaging when the next message should shape what happens. Use a loop when the work has a repeatable beginning, sequence, and result.
Both paths use the same agents, integrations, tools, and project boundary. You can start with one path and add the other later without rebuilding the agent.
| Use case | Start with | What Mobius preserves |
|---|---|---|
| A support assistant in Slack | Agent messaging | The conversation in a session |
| A pull request review on every new PR | A loop | The execution in a run |
| A product copilot that remembers a customer | Agent messaging | One session per customer or conversation |
| A nightly account-enrichment process | A loop | One run per scheduled execution |
The concepts in one picture
A project is the workspace boundary. It keeps one team or product's agents, processes, connections, data, and access together.
An agent is the actor. Its definition describes how it should behave, while toolkits, skills, memory, and integrations shape what it can do and know.
From there, work takes one of two paths:
| Conversation path | Process path |
|---|---|
| A person or application sends a message. | A trigger decides that work should start. |
| A session keeps the conversation together. | A loop describes the repeatable process. |
| The agent replies and may use tools. | Steps ask agents, actions, or people to do bounded parts of the work. |
| Later messages continue the same context. | A run records one execution and its result. |
The paths can meet. A loop step can use an agent session when it benefits from history, and a conversation can start a loop when the work should continue as a visible process.
Conversations remember context
An agent session is one durable conversation with an agent. It preserves messages and tool activity so the agent can build on earlier turns.
Sessions are useful anywhere continuity matters: a Slack thread, a support case, an in-product assistant, or a recurring conversation about one pull request. The channel can change without changing the idea. The session is what keeps the conversation coherent.
Use a new session when the subject, audience, or agent behavior should start fresh. Reuse a session when a new message should benefit from what happened before.
Loops make work repeatable
A loop is a reusable description of work. It answers three questions:
- What starts the work?
- What should happen?
- What result should people or systems be able to inspect?
A manual button, schedule, provider event, or inbound request can start the loop. Its steps can ask an agent to make a judgment, call an exact action, wait for an event, or request a human decision.
Start with the smallest useful shape: a manual start and one agent step. Add automation and safeguards after the result is worth repeating.
Runs explain what happened
A run is one execution of a loop. The loop is the plan; the run is the evidence.
Open a run to see what started it, which steps completed, where it is waiting, what it produced, and why it stopped. This makes a run the main place to operate repeatable work, even when the work started unattended.
Runs also separate change from history. Editing a loop changes future work; an existing run keeps the definition and results it started with.
Steps give work clear boundaries
A step is one meaningful unit inside a loop. Choose the type by the kind of responsibility:
| Need | Step to use |
|---|---|
| Judgment, synthesis, or flexible tool use | Agent |
| An exact side effect, such as posting a message | Action |
| Evidence that a condition is true | Check |
| Time or another system to answer | Sleep or wait for event |
| A person or agent to approve, review, or provide information | Interaction |
| Another reusable process to begin | Child loop |
Good step boundaries make the run understandable. They show where judgment ended, where a side effect happened, and where a person took responsibility. They also let later steps use the saved result of earlier work without sharing an entire agent transcript.
The surrounding concepts
The rest of Mobius supports those two paths:
| Concept | Why it exists |
|---|---|
| Integrations | Connect provider accounts so agents and loops can use external systems. |
| Actions | Give agents and steps named operations with clear inputs and side effects. |
| Toolkits and skills | Control what agents can do and reuse task-specific guidance. |
| Tables | Keep structured data that several agents, people, or runs share. |
| Artifacts | Preserve files and other durable outputs for people or later systems. |
| Workers | Run customer-owned code or models in an environment you control. |
| Interactions | Make a human or agent decision an explicit part of a run. |
| Roles and API clients | Decide who and what may act inside a project. |
You do not need all of them to begin. Add a concept when it solves a problem you can name.
A practical way to start
If a person should keep talking, create an agent and send it a message. If the same job should happen repeatedly, put the smallest successful version in a loop and run it manually.
Then inspect the session or run. Change one thing. Once the result is useful, connect the channel, event, schedule, application, or worker that should make it part of real work.
Next
- Create an agent and a first loop in the quickstart.
- Design a conversational experience with agent messaging.
- Make repeatable work with loops.
- Learn how to read execution history in runs.