MOS uses one Orchestrator and a crew of specialists.

The Orchestrator is the primary coordinator — it interprets what you're asking for and decides what needs to happen. Specialists have bounded roles: Radar watches, the Strategist plans, the Challenger objects, the Dev prepares patches. Each one can have its own prompt, model and permissions where the product supports it.

The crew below isn't a cast of independent fictional personalities — every card corresponds to an actual, configurable role in the product. And in normal use, you don't coordinate them yourself: you talk to MOS, and MOS decides who's involved.

The Orchestrator is the front door to MOS.

You reach it by talking to MOS — the Manager conversation, the same one that greets you the moment you sign in. You give it an objective in plain language; it interprets your intent and constraints, turns that into tracked Work where appropriate, and delegates bounded pieces of it to specialists when their skills are the right fit. When a decision or an approval is genuinely yours to make, it asks — it doesn't guess.

You never need to manually assemble a crew to get started. One conversation is the whole interface.

A mission is MOS turning intent into controlled execution.

1. 1. You give MOS an objective.
2. 2. MOS understands it and plans the approach.
3. 3. Specialist agents can be delegated parts of the work.
4. 4. Controls and approvals apply where they should.
5. 5. Execution produces real Work, events and results.
6. 6. Outcomes can feed the next round of decisions.

This is never an unbounded loop — every run is bounded, and every step lands in an append-only Activity ledger you can inspect.

Conversation becomes Work.

You start by talking to MOS. When an objective is real enough to track, MOS turns it into Work — visible under Active, Completed and Projects. Projects group related Work together for broader context. You don't need to understand any internal distinction between a goal and a mission to use MOS; you just need Work, and Work is what you see.

MOS doesn't require you to keep a chat window open.

Where configured, sweeps, reviews and follow-ups run on a schedule. Work that's in progress keeps executing within its bounded run. None of this is unrestricted — anything that spends money or acts on the outside world still waits for your approval, exactly as if you were watching.

See what MOS did.

Activity is the operational record. Its History tab is the persisted, structural trail of what actually happened. Its Live tab shows what's happening right now — mission timelines and scout runs — and is honestly live-only: it doesn't pretend to be a history after you reload. Ordinary back-and-forth chat with MOS isn't itself logged as a History entry; Activity records operations, not every conversational turn.

MOS is model-independent.

Hosted MOS is BYOK — connecting your own OpenRouter account is the required onboarding path today, and it's free. There's no opaque allowance hiding provider costs inside a subscription. From there, different crew members can inherit the Orchestrator's model or use one of their own where the product supports it, and advanced or local providers can be configured for those who want them. The bartender below shows the full menu.

MOS can coordinate more than native Crew members.

Native agents live inside MOS. A generic custom-HTTP gateway is the real, working escape hatch for connecting an external agent or runtime of your own — it receives a bounded mission and sanitized context, never your keys or vault contents, and outbound calls go through the same egress guard every external request does. Names like Hermes or Jarvis in the panel above are illustrative examples of the kind of runtime that could connect this way — not integrations MOS ships today. An external agent never becomes a trusted root actor: it stays subordinate to the same mission and approval controls a native agent has.

What MOS can know.

MOS can work with connected knowledge — Memory, the Document Vault, and Workspaces — as context for what it does. Where that content actually goes depends on the workflow: through the local Runner's Private Local Memory, chunking, embedding and search all stay on your own machine, and MOS only ever receives the final answer and its references — never the raw chunks. Through the hosted Document Vault, OCR and semantic indexing run through your connected AI provider, so that content does leave your own infrastructure. It is not accurate to say nothing private ever leaves your machine across the board — it depends on which path you're using, and MOS never funds either one for you.

Monitoring is useful only when something changes.

Radar watches the topics and signals you configure, and grades evidence rather than asserting it. “No material change” is a completely valid result — MOS doesn't manufacture activity or invent percentages just to look busy. When something does matter, it surfaces in the right MOS surface or channel for how you've set it up.

The Dev can prepare changes. MOS separates preparation from approval.

Real work, real limits: the Dev reviews, builds in an isolated branch, and runs tests there — never against production. Nothing merges without your approval, and that approval is bound to the exact patch, not a general permission.

Some decisions shouldn't belong to an LLM.

The Treasury Guardian is deterministic logic, not a conversational model — spending limits and policies are enforced independently of whatever a prompt says. Sensitive actions can require your explicit approval, an emergency stop exists for the whole system, and the Activity ledger gives you traceability after the fact. AI proposes; policy decides whether it may proceed.

MOS is simple first. Studio is there when you want the machinery.

Day to day, MOS is a New task button, your recent Work, and a conversation. Studio is a collapsed, opt-in area of the sidebar for everything underneath that:

Local AI lives under Studio → Operate. MOS can detect a local model server you run yourself — LM Studio, Ollama, or vLLM for advanced setups — through a small local Runner you install and pair once. MOS doesn't manage, deploy or configure that server for you; it detects it and lets you route work to it. It's real and working today, with real scope: no automatic model downloads, no GPU marketplace, nothing distributed. None of this is required to use MOS.

MOS prefers “unknown” to invented precision.

No fictional dashboard data, ever. Revenue only counts when there's a real source behind it. Costs are labeled reported, estimated, or unknown — never silently guessed. Runtime is measured execution, not a pretend billable hour. An estimate never quietly becomes a verified outcome.