Instructions
The agent's role and behavior, its 'soul'. Plain text you can edit any time.
This page walks the mechanism behind the three things Mobius commits to: survives the night, knows when to ask a human, and runs where your code and data live.
Named operators with persistent memory.
A Mobius agent has identity. It carries its own instructions, a default model, the tools it can call, and durable Tables it reads and writes across runs. Agents use Tables as memory: they record what they've seen, what they decided, and who they answer to, and they can read it back the next time they run.
Default model
The LLM the agent reaches for first. Override on a per-step basis when needed.
Toolkits
Tools the agent can call: integrations, MCP servers, or built-in capabilities.
Skills
Named, reusable procedures that teach the agent how to accomplish a task.
Tables (memory)
Durable structured storage the agent can read and write across runs: context, notes, prior decisions, learned facts.
Environment
An optional isolated workspace for cloning repos, editing files, running commands.
A 1:1 conversation with an agent is durable chat, useful for exploration and coaching. When a conversation produces work that should be tracked, the user or agent creates a run, an interaction, or an artifact explicitly.
Many ways for an automation to start.
Any combination of cron, integration events, webhooks, API calls, or another agent can start an automation. Each trigger carries filters in plain language. The automation around the trigger declares its concurrency policy so parallel fires behave predictably under load. One automation can react to several sources at once.
- Schedule
Cron or interval. Each automation declares its concurrency policy for overlapping fires.
- Integration event
Slack messages, GitHub pull requests, Linear issues, inbound email, and more. Filters use plain-language matchers.
- Webhook
A computed receive URL with optional HMAC signing and JSONPath input mapping.
- API / SDK
Trigger a run from code, a CLI, or a button in your own product.
- Agent-initiated
One agent decides another should run. Same surface; full audit trail.
triggers.yamlYAML
1# A schedule and a Slack event drive the same automation.2triggers:3 - source: schedule.tick4 cron: "0 9 * * 1-5"5 - source: slack.app_mention.created6 filters:7 channel: "#ops"8 9concurrency: forbid # allow | forbid | replace | queue10 One action. Used as a tool during reasoning, or as a deterministic step.
Register an action once. An agent step can call it as a tool while deciding what to do. The next step in the same automation can call it deterministically, with rendered parameters and no LLM in the loop. Reasoning where you need it; deterministic actions where you don't.
As a tool
agent step
An agent decides during its turn that it needs to send a Slack message. It calls the slack.post action as a tool. The agent reasons, the worker executes, the result returns into the agent's context.
As a step
action step
Another automation needs to post the same Slack message every weekday at 9. It calls slack.post directly as a step, with rendered parameters. Mobius runs the action; no LLM is invoked.
pr-review-agent.yamlYAML
1name: pr-review-agent2trigger:3 source: github.pull_request.opened4 5concurrency: queue6 7steps:8 # Reasoning: the agent decides which tools to call.9 - agent: code-reviewer10 prompt: |11 Review pull request #${trigger.pr.number} in ${trigger.repo}.12 Save findings to the artifact "findings".13 save_as: review14 15 - interaction:16 type: request_review17 target: curtis18 artifact: review.artifacts.findings19 timeout: 24h20 save_as: approval21 22 # Deterministic: the same github.comment action, rendered as a step.23 - action: github.comment24 when: approval.decision == "approve"25 parameters:26 repo: ${trigger.repo}27 number: ${trigger.pr.number}28 body: ${review.artifacts.findings.text}29 Illustrative. Exact SDK syntax is firming up during early access.
Runs survive restarts, retry, and resume.
State persists at step boundaries. Runs that hit an intermittent failure retry on configurable backoff. Runs that hit a sleep, an event wait, or a human approval suspend and release their resources; they pick back up when the condition resolves. Every run exposes an event stream over HTTP and SSE so you can follow live or replay.
Survive restarts
If the service crashes mid-run, the restarted service resumes from the last checkpoint.
Retry intermittents
Configurable retry counts and delays per step. Transient failures resolve themselves; persistent ones surface clearly.
Suspend on waits
Sleep until a time, wait_for_event until a matching source event, or interaction until a person or agent responds.
Replay any run
Step starts, tool calls, action results, interactions, artifacts, all in the event stream after the fact.
Agents get real workspaces. What they produce is saved.
When an agent needs to clone repositories, edit files, or run commands, it uses an isolated environment. Sprites.dev is the default provider. Files agents produce, including markdown, images, audio, and video, are saved as artifacts and accessible after the run. Cleanup releases workspaces and other allocated resources automatically.
per-run
A fresh workspace per run. CI-like, parallel-safe by default.
per-agent
A persistent workspace owned by one agent across runs. Defaults to serialized access.
by-automation
A persistent workspace shared by agents inside one automation. Concurrency is explicit.
Artifacts persist
Markdown, images, audio, video, saved with the run and inspectable afterwards.
Workers run where your code lives.
A worker is a small program you run on your own hardware. It opens a long-lived outbound HTTPS connection to Mobius Cloud and waits for work. The agent loop runs in Mobius; tool calls and action calls are routed to your worker; the worker executes them locally and returns the result. Workers can also serve customer-managed LLM calls (an Ollama deployment, a private inference endpoint), so model traffic stays on your network.
Outbound connection
The worker dials Mobius. Your firewall stays as it is and no public webhook receiver needs to be exposed.
Local execution
Private code, sensitive data, and self-hosted models stay on the machine where the worker runs.
Customer-managed models
Route LLM calls through your worker so model traffic stays on your network.
The Five-Step First Run
OK, you've read the mechanism. Here's what the first week looks like.
- 1
Request access.
Founder-led intake. One human reply.
- 2
Define your first agent.
Name it, give it a role, a default model, and a few tools.
- 3
Wire one trigger.
A schedule, a webhook, or an integration event. Whatever fires the work.
- 4
Add the human gate.
Pick the moment you'd want to be asked: request_approval, request_review, or request_information as a peer step type.
- 5
Run it overnight; read the event stream in the morning.
Step starts, tool calls, action results, the interaction, the artifact, all in the timeline.
Free, 3-page PDF
Get the Agent Reliability Checklist
Grade your current setup (DIY script, Routine, Codex/Cursor Automation, n8n hybrid) against the eight things that decide whether an unattended agent survives the night.
Where to next.
Read the docs, see what's included in early access, or talk to Curtis about your first always-on agent.