Mori lives on your desktop. Discord, Telegram, and the Mori Link phone app are remote controls for the same brain — with the same memory, the same tools, and the same guardrails.
Every remote surface runs through a single bot engine with a thin transport layer per platform: Discord, Telegram, and the Mori Link phone app all deliver messages into the same handler and get replies, images, files, and audio back through their own channel. There is no separate cloud agent — the message travels to the Mori app running on your machine, and Mori acts on your actual computer: your files, your browser, your terminal, your screen.
Surfaces can run on their own model and key. If you set a bot provider, model, or API key in Settings, remote chats use those; otherwise they inherit the desktop's active provider. Keys are yours in both cases — Mori is bring-your-own-keys everywhere, and nothing routes through a Studio Mori server for inference.
Reliability is treated as a safety property: every outbound send retries three times with backoff before failing, and if a task errors, Mori tells you what happened and offers a retry. A surface never goes silent.
Mori distinguishes exactly two kinds of people: the verified owner, and everyone else. On Discord and Telegram, verification is anchored to the platform's immutable account ID — not a display name. You set your username once in the app; the first time that user messages the bot, Mori captures their account ID and locks it as the owner ID. From then on the ID is the sole source of truth, so someone copying your display name or handle gets nowhere.
The phone app skips this entirely: Mori Link is signed into your own Studio Mori account and must complete an explicit pairing handshake, so every message from a paired phone is treated as the owner by construction.
Only the owner can run tasks, touch the machine, or approve anything. The split is enforced in the engine before a single tool is available — it is not a prompt-level suggestion.
As the verified owner, a DM to Mori is equivalent to sitting at the desktop chat. Mori has her full toolset: open and search the web, read and write files, run terminal commands, launch apps, drive the browser, and build projects. Specific remote behaviors:
/auto on from any surface runs tasks end-to-end without check-in questions; /auto off restores normal check-ins. Irreversible actions still require confirmation either way.Each chat keeps its own memory: the last 36 messages are held per channel and persisted to your account under a deterministic conversation ID, so after an app restart Mori restores the full thread and stays consistent with what she already did.
Anyone who addresses Mori in a server — by mention, reply, or "hey mori" — gets a conversation. What they never get is your machine. For non-owners:
Any risky step mid-task — a spend, an irreversible action, a purchase — pauses the task and asks you in chat. Approvals are typed objects, not loose pattern-matching on whatever you say next:
Purchases get the fullest version of this flow: Mori sends the cart summary with a screenshot, states the payment label, and only places the order after an explicit yes. She never enters credentials or clicks a final purchase button on her own.
you › order that usb-c hub
mori › 🛒 Anker 555 hub — $34.99, arrives Thu
Ready to place — Visa ····4242. Reply "yes" to place the order.
(approval apr_lx2k9f3a — expires in 2 minutes;
anything but a clear yes is a no)
you › hmm maybe
mori › Didn't catch a clear yes — treating that as a NO
for safety (approval apr_lx2k9f3a).A bare "stop" (or "cancel", "abort", "halt", "never mind") from any surface halts the running task immediately, through the same machinery as the desktop Stop button. Mori confirms the halt, logs the cancellation to the audit log, and offers to pick the task back up.
Messages that arrive while a task is running don't bounce — they fold into the live task as steering notes ("make the header darker" mid-build lands in the build). If a note can't be folded in, Mori says she's still working rather than dropping it. And a wedged task can never lock a chat forever: task locks expire after 10 minutes, after which new messages are taken normally.
Long jobs — builds, shopping runs, deploys — get a short "on it" acknowledgment only if they're genuinely still running after a few seconds, so quick questions never get a spurious ack.
The phone app talks to your desktop over a realtime channel scoped to your signed-in account — but being on the account is not enough to issue commands. Pairing is an explicit handshake: the phone displays a 6-digit code, you type it into the desktop's "Link a phone" screen, the phone validates the claim, and the desktop stores that phone's unique ID. From then on, commands are executed only if they carry the paired phone's ID — anything else on the channel is dropped before it reaches the engine. Either side can unpair at any time, which clears the stored ID immediately.
While a task runs, the desktop streams live status lines to the phone — what Mori is doing and which step she's on — throttled so long tasks don't flood the app. Screenshots and build previews are downscaled and compressed on the desktop to fit the realtime payload cap, so results land on your phone as they happen.
The desktop also announces its presence on the channel (machine name and online state), so the app can show whether your computer is reachable before you send anything.