Coming soonOOMU is launching soon. Downloads will open at launch.
OOMU
← All documentation

Explanation

System Design Overview

How OOMU runs on your desktop.

OOMU is a desktop application, not a cloud service. This single design decision shapes everything else: your data stays on your Mac, your assistants are available offline, and the cloud is something OOMU reaches for deliberately; not the place your work lives. This page explains how the pieces fit together.

The shape of the application

OOMU is built as two cooperating halves inside one application:

  • The interface; a modern web-technology front end (React) that renders everything you see and interact with.
  • The desktop engine; a native, compiled core (Rust) that does the real work: running models, reading files safely, storing your data, and enforcing security.

These two halves are packaged together into a single native macOS application using Tauri. There is no server, no browser tab, and no website. When you quit OOMU, nothing keeps running in the background on someone else's machine, because there was never a someone else's machine.

┌─────────────────────────────────────────────┐
│                 OOMU.app                     │
│                                              │
│   Interface (React)                          │
│        │                                     │
│        │  the Application Bridge             │
│        ▼                                     │
│   Desktop Engine (Rust)                      │
│     • Local model runtime                    │
│     • Encrypted local database               │
│     • Safe file access (sandbox)             │
│     • Cloud provider connectors              │
│     • Capability (Mod) system                │
└─────────────────────────────────────────────┘
        │                         │
        ▼                         ▼
   Your Mac's disk          Cloud providers
   (local, private)         (only when chosen)

The Application Bridge

The interface never reaches into your filesystem, database, or models directly. Instead it asks the engine to act, through a well-defined set of commands; the Application Bridge.

This is more than an implementation detail; it's a safety boundary. Because every sensitive action flows through named commands in the engine, there is exactly one place where rules are enforced: which paths can be read, how data is stored, what a capability is allowed to do. The interface can only ask; the engine decides. For the developer-facing details, see the Application Bridge API.

Thinking locally: the on-device model

OOMU ships with the ability to run a capable language model entirely on your Mac, using a built-in, optimised inference runtime. No network connection is required, and there is no per-question cost.

This local engine is the default. For the bulk of everyday work; drafting, summarising, answering questions, reasoning over a document you've attached; OOMU never needs to contact anyone. The first time the model loads it warms up; after that, answers are fast.

Local inference is what makes OOMU's privacy promise real rather than aspirational. The private path isn't a setting you have to find; it's the default behaviour.

Reaching out: cloud providers, on your terms

When a task genuinely benefits from a frontier cloud model, OOMU can call one, but only providers you have configured with your own API key. OOMU supports the major providers; Anthropic, OpenAI, Google Gemini, xAI, Mistral, OpenRouter, and others, and talks to their official endpoints directly from your machine.

OOMU's router decides when this is worth it. With Auto-Route, OOMU scores each message's complexity and picks the engine per turn: easy prompts stay on the free local model, and only the harder ones escalate to a cloud provider you've nominated. You stay in control; Auto-Route can be turned off for any conversation to pin it to a fixed engine. See Smart Model Routing and Hybrid AI Economics.

Two kinds of request: conversation vs. action

Not every message is the same. OOMU classifies each one:

  • Conversation; a question or a piece of writing. OOMU answers directly and streams the reply.
  • Action; a request that needs to read or change files, run a command, or fetch current facts. OOMU compiles a plan, runs it through an approval-gated process, and keeps a record of what it did.

This separation means casual conversation stays light and instant, while anything that touches your workspace goes through deliberate, auditable steps. The records of those steps live in your local database (the intents, actions, and certificates tables; see Local Database Schema).

Organising the work: Projects and Tasks

Above single messages, OOMU has two organising structures that turn it from a chat app into a coworker:

  • A Project is a workspace boundary. It groups the folders OOMU may read, its knowledge and memory, your standing instructions, and one data policy; the rule for whether the cloud may be used at all. The engine enforces that policy *before* any network call, so "keep everything on this device" is a real guarantee, not a UI preference.
  • A Task is the canonical record of a unit of work. Every runtime; a workflow run, a scheduled Routine, a browser or app-control session, an artifact build, a delegated helper; reports into one task registry with a shared lifecycle you can inspect, cancel, resume, and safely retry. Retries reuse idempotency records, and on restart OOMU reconciles unfinished tasks with the runtime that owns them rather than guessing they succeeded.

This is the backbone of the "sovereign Mac coworker" model: configure a Project once, delegate or schedule work, intervene only when asked, and inspect exactly what happened. See The Delegated-Work Loop.

Remembering: the encrypted local store

Everything OOMU keeps; your assistants, conversations, settings, installed capabilities, workflow definitions; is stored in an encrypted SQLite database on your Mac. The encryption key is derived from a device secret held in the macOS Keychain, so the store is readable only by OOMU, only on your machine.

This is covered in detail in Privacy & Sandboxing and Local Database Schema.

Extending: the capability system

OOMU can be extended with Mods; self-contained .oomu capability packages. Rather than the open-ended, machine-wide access of traditional plugins, a Mod runs inside OOMU's safety model: it's installed into your workspace, declares what it needs, and only ever acts through the engine's sandbox and permission system. You decide which assistants and which Projects use it.

Mods are now signed capability bundles: a signature proves *who* published a package, kept deliberately separate from whether OOMU has *reviewed* it. Installation is transactional, shows an exact capability diff first, and any attempt to use an undeclared capability fails closed at runtime.

See Adding Custom Capabilities, Building a Custom Capability Package, and the Capability Package Specification.

Automating: workflows and connected tools

Beyond single conversations, OOMU can run workflows; saved sequences of steps that draft, summarise, call tools, gate on your approval, and produce files. You describe a workflow in plain language and OOMU composes it, on-device, from a capability catalogue of things it can actually do. Workflows can run on demand or on a schedule, and consequential steps pause for your approval.

That catalogue includes tools from connected MCP (Model Context Protocol) servers; the standard way OOMU reaches external tools and data sources. A connected server's tools become available both to your assistants and as workflow steps; anything not connected is shown as unavailable rather than failing silently. See Building Automated Workflows.

Workflows can run on a schedule as Routines, under a durable background helper, and deliver results to a messaging channel (Signal, Telegram, WhatsApp, Discord); the same channels through which an authorized owner can steer or approve work remotely.

Producing and acting: outputs, apps, and helpers

A coworker has to produce things and operate tools, not just talk:

  • Documents. OOMU builds real Word, PDF, Excel, and PowerPoint files from a structured model using packaged, version-pinned builders, then renders and verifies them before calling them done. Each carries a signed provenance receipt. See Generating Documents.
  • Connected services. Google Workspace, Slack, Microsoft 365, and your Apple apps connect through a credential layer where secrets live in the Keychain and every connector is origin-bound. Reads are direct; writes are approval-gated. See Connecting Services.
  • Guarded automation. OOMU can operate its contained browser and qualified Mac applications through observed, reference-based actions; never arbitrary scripts or blind clicks; pausing for takeover and verifying outcomes. See Automating Your Mac.
  • Bounded delegation. For research-heavy work, a parent Task can fan out to a bounded set of read-only helpers in isolated contexts. Helpers gather; only the parent synthesises and commits mutations, behind your approval.
  • Multimodal input. Voice, screenshots, and images become first-class, provenance-tracked Task inputs, with capture off by default.

Governing and localising

Two more layers round out the desktop experience:

  • Sovereign Trust lets you grant OOMU folder-scoped, time-bounded permission to act, with daily resource budgets; a precise dial on top of the sandbox. See Privacy & Sandboxing.
  • Localisation; OOMU's interface is available in multiple languages, selectable in settings.

The design in one sentence

OOMU keeps your data and your default intelligence on your own Mac, treats the cloud as an optional tool rather than a home, and routes every sensitive action through a single, enforceable boundary in its native engine.