Routines

A routine runs the same instructions on a schedule or when an event arrives. Each occurrence leaves a run you can inspect for its result, action activity, and cost. Event routines can keep one conversation per followed item.

Use a routine after a request works well by hand and only the timing changes: prepare the morning brief, review yesterday's backup results, or triage each new issue. Keep using a conversation when the next message should decide what happens.

Create a routine in the app

Open Routines and select New routine. The form asks for:

Choose Mine while you are still shaping the work. Choose The business when the work should remain available independently of one person's account. Only an organization administrator can create a business-owned routine, and the form requires at least one responsible person.

The creator follows the routine automatically. Adding another follower to a private routine expands who can read its existing and future results, so the form asks you to confirm that change.

Select Create routine when the instructions, accounts, custody, and limits are ready. You can also ask an assistant to propose a scheduled personal routine from a conversation. That path creates nothing until the named person selects Approve routine, and the resulting routine still needs its exact accounts reviewed.

Where the files go

Save files to names one Library folder. A new routine arrives with routines/<name> filled in; edit it, browse for another folder, or clear it to save at the top level of the Library. It is a stored setting, so renaming the routine never moves where its files go.

Every file an occurrence produces without a folder of its own lands there: files the assistant writes, attachments it saves from Gmail, Outlook, Google Drive, or OneDrive, generated images and video, and documents it creates. If the assistant names a file with a folder in it, such as contracts/inbound/acme.pdf, that wins.

Assistants have the same setting, used when they are working in a conversation rather than a routine. In the Library you can create folders, move and rename files from the row menu, and select several files to move at once; moving a file keeps its ID, its version history, and every conversation that points at it.

Scheduled and event routines

A routine has exactly one trigger.

For a schedule, choose the time, days, and timezone. For an event, choose a connected integration and an event such as github.issues.opened. You can use a trailing wildcard such as github.issues.* and add a condition:

event.repository.full_name == "acme/api"

The assistant receives the normalized { event, meta } envelope as data, not as trusted instructions. The source events guide explains the envelope and condition syntax.

With Each event, event routines run one occurrence at a time. Another matching event waits behind the active occurrence. If it is still queued six hours later, Mobius records it as skipped rather than acting on stale information. A condition that evaluates to false creates no run; a condition error creates a failed run so you can diagnose it.

Follow a thread

For an event routine, choose What to follow after selecting the watched account. Choices come from the provider: each pull request, issue, email thread, channel, or customer. The routine still runs only on the event type you picked, and the events of that type for one item share a conversation and workspace. For example, a routine on pushes to a pull request groups each pull request's pushes, but it does not receive the pull request's reviews. To group all of an item's activity, set the event type to the provider's pattern, such as github.*; the routine then receives every event the target covers. You can also add a condition.

A routine on pull request or review events follows Each pull request unless you choose otherwise. Choose Each event to start fresh every time.

Each event starts a fresh conversation. One ongoing conversation keeps all matching events together. Custom thread key accepts an expression over event and meta; test it against a recent event before saving. The target and custom expression cannot change after creation; create a new routine to follow something else.

Each followed item gets one conversation. Later events append to it, so the assistant can refer to its earlier responses. Different items can run at the same time, up to the concurrency limit (5 by default). A burst waiting behind an active thread collapses into the newest event; earlier runs show Coalesced and their summaries reach the assistant with the next turn.

Open the routine's Threads view for each item's state, event count, activity, and cost. Select its title to read the conversation, or its event count to see its runs. A completed terminal event closes the thread. After 14 days without an event it shows as idle; the next event reopens the same conversation.

Advanced settings control the idle period, concurrency, and turn limit (25 by default). At the turn limit, further events are recorded as skipped. A person who manages the routine can resume that thread or raise the limit. Resuming allows future events; it does not replay skipped ones. Events caused by the watched GitHub App or Slack bot are skipped as self echoes. GitHub user mode cannot distinguish those echoes and does not skip them.

Open a run's conversation

Creating a routine from a chat does not make the routine reuse that chat. The original conversation records where the idea came from. Scheduled and Each event occurrences get a new conversation. A followed thread reuses its own conversation. Both contain the instructions, source event when present, tool calls, questions and their outcomes, and assistant responses.

Open Routines > Runs or open a routine and choose Runs. Select Open run to read its conversation. Routine conversations stay out of the ordinary conversation list, which keeps scheduled work from crowding out the chats you started yourself.

A run can be:

The result headline comes from the final assistant answer. Opening a completed or failed run marks it read for you alone.

Follow, wait on, and manage

The People view keeps three jobs separate:

One person can hold more than one relationship. A responsible person does not receive unread results unless you also add them as a follower. Following does not grant permission to edit.

While you follow a routine, choose All results or Failures only beside the Following button. With Failures only, email and Teams notifications reach you only when a run fails or needs someone to fix it.

Private sharing is deliberate. The current owner must confirm a named person's access, and that confirmation belongs to the person's current organization membership. Leaving and rejoining does not revive it. The share reaches this routine, its run conversations, and its artifacts; it does not expose the chat where the routine was first discussed or another resource mentioned in the instructions.

Open a private routine's People view to add Read and follow or Manage routine access. A private manager cannot invite more people, transfer custody, or delete the routine.

Change, test, pause, or cancel

Use Edit routine to change its name, instructions, trigger, spend limits, accounts, or who may change it. Later occurrences use the saved version; earlier runs keep their own record. Change history shows the routine's lifecycle and management changes.

New routines start with changes limited to the personal owner, named managers, and organization administrators. A team routine has no personal owner. From Edit routine > Who may change it, an authorized manager can choose Anyone who can reach it for a team-managed routine.

Use Run now from the routine's row menu to test the current configuration. It queues one occurrence under the normal account, credit, and time limits without moving the schedule. Only one occurrence can be active at once, and a manual run that cannot start within ten minutes becomes stale.

Pause first when something looks wrong. Pausing keeps the configuration and schedule. Resume rechecks every exact account grant before the routine becomes active again. Cancelling ends future occurrences.

Connected accounts and external changes

An account binding names one exact connection and grant. A Google account used to watch for an event is separate from the account the assistant may use for an action; one never silently becomes the other.

If a bound connection is revoked, replaced, or no longer reaches the routine's audience, Mobius pauses the routine for account repair. Open the routine's Accounts section, replace or remove the unavailable account, then resume. Mobius does not switch to another account on its own.

Reading or changing data through a connected account can proceed under its grant. Mobius does not insert an automatic approval before built-in, MCP, custom HTTP, or worker actions. It rechecks the routine's exact account binding and grant immediately before a provider action, and a denied account never falls through to another connection.

When a routine should wait for a person before an external change, say so in its instructions: have the assistant call mobius.interaction.open and wait for the answer. Asking alone does not hold the run. Name the responder, include the proposed destination and content, and tell the assistant what to do after approval, rejection, dismissal, or expiry. This review is part of the workflow you designed; it is not an automatic dispatch gate. See interactions and guardrails.

Memory and custody

A personal routine runs with its owner's personal context. It can read the assistant's shared memory and that owner's private memory, and memory it writes goes back to the owner's private layer.

A business-owned routine has no human initiator. It reads and writes the assistant's shared memory. Use business custody only for information that the assistant may use across its audience. See agent memory.

When somebody leaves

For each personal routine owned by a departing member, an administrator must choose Transfer to person, Hand to team, or Delete during offboarding. A transfer clears its exact account bindings. Handing it to the team also pauses it until an administrator supplies suitable organization accounts and resumes it. Delete cancels future occurrences.

A routine already owned by the business does not depend on its creator's personal custody, but its people and account choices still matter. Before a responsible person leaves, name another person and update any interaction targets in the instructions. Team custody makes continuity manageable; it does not make account access or human coverage repair itself.

Limits

A new routine starts with 50 credits per occurrence and 200 credits across a rolling 24 hours. Changing these defaults does not change the limits of routines that already exist. Both must be positive, and the daily ceiling must cover at least one occurrence. A run's spend includes its model calls, its subagent runs, and the summaries Mobius makes of large tool results. Enforcement happens between operations, so one in-flight model or action call may take the final recorded spend slightly beyond a ceiling. A run stopped at its per-run limit shows Failed with a note that names the limit and says who can raise it; its routine channel and notification carry the same note. Anyone who may change the routine can raise Credits per run in Edit routine so such runs finish.

Each person may own ten active routines by default. Team-owned routines do not currently share that per-person count. Each occurrence also uses the assistant's active-work time limit; time spent waiting for an event or interaction does not consume that budget.

API and CLI

The API exposes /v1/routines for list and create, /v1/routines/{id} for read and update, lifecycle actions, people, and the occurrence ledger. The generated CLI presents the same operations under mobius routines.

API creation requires an agent, instructions, exactly one schedule or event, and explicit per-occurrence and rolling 24-hour ceilings. Use the app for the ordinary setup path. An authenticated human can use the API or CLI to administer the same model, but routine creation rejects a service principal or API-key identity.

Next

• Build a reviewed morning brief to Slack.
• Decide who owns work in your work and the team's work.
• See what pauses a turn in interactions.
• Inspect event payloads in source events.