Skip to main content

Architecture Overview

mimOE is an operating environment for DFC AI Agents and serverless mims (micro intelligence modules). Built on the Device-First Continuum (DFC) architecture, mimOE enables distributed, AI-powered applications that run directly on devices with seamless cloud integration when needed.

What is mimOE?

mimOE is a lightweight runtime that executes serverless mims and AI agents on edge devices such as smartphones, tablets, desktops, and embedded systems. Unlike traditional cloud-first architectures, mimOE implements a device-first approach where processing starts on the device where data originates.

What are mims?

mims (micro intelligence modules) are lightweight, serverless compute units that run on mimOE, from device to multi-cloud, without container overhead. Unlike traditional containers, mims are purpose-built for edge AI and distributed computing.

Core Characteristics

  • Device-First Continuum: Processing starts on-device, with seamless escalation to cloud when needed
  • AI Agent runtime: Purpose-built environment for deploying and running AI agents on-device
  • Serverless mims: Request-driven execution with automatic instance lifecycle management
  • Node-to-node communication: Devices discover and communicate directly without cloud intermediaries
  • Cross-platform: Runs on macOS, Linux, Windows, iOS, and Android
  • AI-ready: Built-in support for on-device ML inference with ONNX and GGUF models

Device-First Continuum (DFC)

The Device-First Continuum represents a fundamental architectural shift from traditional cloud-centric computing.

Traditional Cloud-First Architecture

Cloud-first architecture - all devices route through cloud

In cloud-first architectures:

  • Data and processing happen in the cloud by default
  • Devices are thin clients that send requests to cloud servers
  • Edge computing is an optimization layer (caching, CDN)
  • Offline capability is an afterthought
  • Every interaction requires internet connectivity

Device-First Continuum Architecture

Device-first architecture - devices communicate P2P with optional cloud

In the Device-First Continuum:

  • Processing begins on the device where data originates
  • Devices are capable compute nodes, not just clients
  • Cloud services are available when needed (discovery, sync, heavy compute)
  • Devices can collaborate directly without cloud intermediaries
  • Offline-first is the default assumption

The Continuum

DFC is not anti-cloud. It's about flexibility. Applications can operate anywhere on the continuum from fully local to fully cloud, based on the needs of each use case.

Example scenarios:

ScenarioProcessing LocationWhy
Private photo analysis100% on-devicePrivacy-sensitive data
Local device collaborationDevice mesh (P2P)Low latency, no internet needed
Global user discoveryCloud-assistedRequires global coordination
Heavy ML trainingCloud offloadExceeds device resources

A single application can use different points on the continuum for different operations.

Serverless-on-Device Architecture

mimOE implements a serverless execution model optimized for resource-constrained devices.

One Request, One mim Instance

mim instance lifecycle - request-scoped instantiation and termination

Key principles:

  1. On-Demand Instantiation: mims are created only when needed
  2. Request-Scoped Lifetime: Each instance lives for exactly one request
  3. Clean Termination: Instances are destroyed after response
  4. Memory Efficiency: Resources are immediately released

State Management

Because instances are destroyed after each request, no state persists between requests. This is a fundamental constraint of the serverless-on-device model.

For data that must persist, use:

  • context.storage API (key-value database)
  • External storage services
  • Client-side state management
// ❌ WRONG - This will NOT work
let requestCount = 0; // Lost after each request

export function handler(request, context) {
requestCount++; // Always 1!
return { count: requestCount };
}
// ✅ CORRECT - Use context.storage
export async function handler(request, context) {
const count = await context.storage.get('requestCount') || 0;
const newCount = count + 1;
await context.storage.set('requestCount', newCount);
return { count: newCount };
}

Runtime Components

mimOE consists of several integrated components:

1. Core Runtime

The core runtime handles:

  • HTTP request routing
  • mim lifecycle management
  • Authentication and authorization
  • Resource monitoring and limits

2. Execution Engines

mimOE supports two execution engines:

mimOE JavaScript Runtime

  • ES5-compatible JavaScript engine
  • Lightweight and efficient
  • Full garbage collection
  • context object API injection

WebAssembly (WASM)

  • Standards-compliant WASM execution
  • Near-native performance
  • Custom import functions (not WASI)
  • Memory-safe sandbox

3. Built-in Services

Several services run alongside the core runtime:

MCM (mimik Compute Manager)

  • Deploy and manage mims
  • Version control
  • Configuration management

Model Registry (AI Foundation Package)

  • Model registry and storage
  • ONNX and GGUF support
  • Model lifecycle management

Inference Service (AI Foundation Package)

  • On-device ML inference
  • Automatic model loading
  • Hardware acceleration when available

4. Discovery & Networking

Enables devices to find and communicate:

  • Link local discovery (mDNS-based)
  • Account-based discovery (via mDS cloud service)
  • Proximity discovery (location-based)
  • Tunneling service (NAT traversal)

Cross-Platform Architecture

mimOE is designed for true cross-platform deployment:

mimOE cross-platform architecture - core runtime with JS and WASM engines

Desktop Platforms

  • macOS: Native binary, standalone runtime
  • Linux: Native binary, standalone runtime
  • Windows: Native binary, standalone runtime

Mobile Platforms

  • iOS: Embedded in application, framework integration
  • Android: Embedded in application, library integration
Mobile Integration

On mobile platforms, mimOE runs as an embedded component within your application, not as a standalone process. Example applications demonstrate the integration pattern.

Security Model

mimOE implements defense-in-depth security:

1. Authentication

  • Developer tokens: For deploying mims (MCM API)
  • Access tokens: For calling mims
  • OAuth 2.0 flow: Standard authentication protocol

2. Isolation

  • Process isolation: mims run in isolated contexts
  • Memory safety: No direct memory access between services
  • Sandboxing: Limited system API access

3. Encryption

  • HTTPS/TLS: All network communication encrypted
  • Storage encryption: context.storage data encrypted at rest
  • Token security: Secure token storage and rotation

Platform Capabilities

What mimOE provides to your mims:

HTTP Client (context.http)

Make outbound HTTP requests to any endpoint:

const response = await context.http.get('https://api.example.com/data');

Persistent Storage (context.storage)

Key-value database for each mim:

await context.storage.set('userPrefs', { theme: 'dark' });
const prefs = await context.storage.get('userPrefs');

Discovery (context.edge)

Find and communicate with other mimOE nodes:

const nodes = await context.edge.discover({ mode: 'local' });

Comparison to Other Platforms

FeaturemimOEAWS LambdaKubernetesOllama
Runs on devices
Serverless model
P2P discovery
AI-native
Offline capable~
Cross-platformN/A~
JavaScript + WASM

Next Steps

Now that you understand the architecture, explore:

Deep Dive

For comprehensive technical details, see the SPEC.md product specification in the repository.