How Mobius works

Mobius keeps the useful setup around an AI task so people can reuse it without sharing credentials, copying prompts, or combining their private chats.

Picture Northwind's morning operations brief. The source sits in an account the company uses. Scout knows how to turn that source into a brief. Maya can ask Scout for one by hand, a colleague can ask in a separate conversation, and a routine can prepare the checked version every weekday.

named account
    ↓ access granted to Scout
saved assistant definition
    ↓ used in a conversation or routine occurrence
separate result with its own audience and record

Each part answers a different question. Keeping them separate is what lets the company share useful behavior without opening every account or conversation.

Connect a named account

A connection identifies one account in another service: a particular Slack workspace, Google account, GitHub installation, or other provider account. It also records whether a person or the organization controls that connection and which identity will act.

Connecting the account does not make it available to every assistant. A grant lets one eligible assistant use that account in its conversations and routines. The acting identity and the account's allowed result audience are still checked each time.

Save the behavior people should reuse

An assistant holds the maintained version of the work: its instructions, model, tools, skills, and account access. The app and API call this saved resource an agent.

Scout's instructions might say which source to use, how to organize the brief, and what to do when a job has no owner. Maya improves those instructions once. Later work with Scout reads the current saved definition, so colleagues do not need a private copy of the prompt.

Mobius does not silently train Scout on everyone's messages. A person improves it by editing the saved instructions, deliberately sharing useful knowledge, or changing a tool, skill, or account grant. Earlier messages stay in their original conversations, and the saved change leaves its own record.

Keep each conversation separate

A session is the record of one conversation with an assistant. It contains the messages and visible activity needed for follow-up requests. One request and the resulting assistant work is a turn.

Maya and her colleague can both use Scout without entering the same session. They get the same saved behavior and separate conversation histories. Sharing the assistant does not publish either person's messages, private memory, or results to the other.

The assistant's audience and the person's organization permissions are both required. Audience answers who may reach this Scout. Permissions answer whether that person may use it, inspect configuration, or edit it. Who can use an assistant covers the full distinction.

Repeat checked work with a routine

A routine runs saved instructions on a schedule or when a source event arrives. Each occurrence starts its own session. If the routine began as a proposal in Maya's chat, that chat records where the idea came from; its private messages do not become context for later occurrences.

A routine proposed in a conversation is personal. To place the work in company custody, an authorized person creates it from Routines > New routine, picks The business, and names at least one responsible person. Custody, responsibility, permission to manage, following, and access to run results are separate relationships.

Read and write actions follow the same account grants used in a manual conversation. Immediately before dispatch, Mobius revalidates the exact connection, live grant, account binding, and container audience. It does not automatically ask a person to confirm an external action that changes data. An MCP call is retried automatically only when the server positively marks it read-only and idempotent, without marking it destructive. A changing action does not gain an automatic retry.

Choose recipients deliberately

The people who may use Scout are not automatically the people who may receive every result inside Mobius. A private mailbox result may stay with the person who controls the connection, while a company connection can allow a routine's container to retain a result for its team audience.

That container audience does not approve arbitrary recipients passed to an email, Slack, or other delivery action. The current runtime has no separate controller-consent check for each outbound destination. Keep destination permissions and instructions narrow. When a person must review a recipient or message before it leaves, instruct the assistant to open an interaction and wait for that decision. This review follows the instructions; it is not a hard gate added to every delivery.

Inspect what happened

Mobius keeps the messages, visible tool activity, deliberate interactions, results, cost, and final status it receives. Open the conversation or routine run when you need to see what was requested, which account acted, or why the work stopped.

That record proves what Mobius and its tools reported. It does not prove that a person read a Slack post or that an outside system completed a later step. For important work, check the destination too.

The objects behind the work

Once the flow is clear, the technical relationships are straightforward:

The organization is the tenant boundary, but it is not a promise that every member can read every resource. Audience, ownership, and permissions narrow reach inside it.

Add only what the task needs

Start with one assistant and supplied facts. Add a named account when the task needs live input. Add a routine when the manual result is worth repeating. Use tables, files, or deliberately shared memory when information should outlive one conversation.

For the working path, create and share Scout, then connect its first account. Developers can use the same configured assistant through the API.