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.
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
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
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:
| Scenario | Processing Location | Why |
|---|---|---|
| Private photo analysis | 100% on-device | Privacy-sensitive data |
| Local device collaboration | Device mesh (P2P) | Low latency, no internet needed |
| Global user discovery | Cloud-assisted | Requires global coordination |
| Heavy ML training | Cloud offload | Exceeds 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
Key principles:
- On-Demand Instantiation: mims are created only when needed
- Request-Scoped Lifetime: Each instance lives for exactly one request
- Clean Termination: Instances are destroyed after response
- 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.storageAPI (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:
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
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
| Feature | mimOE | AWS Lambda | Kubernetes | Ollama |
|---|---|---|---|---|
| Runs on devices | ✓ | ✗ | ✗ | ✓ |
| Serverless model | ✓ | ✓ | ✗ | ✗ |
| P2P discovery | ✓ | ✗ | ✗ | ✗ |
| AI-native | ✓ | ✗ | ✗ | ✓ |
| Offline capable | ✓ | ✗ | ~ | ✓ |
| Cross-platform | ✓ | N/A | ✗ | ~ |
| JavaScript + WASM | ✓ | ✓ | ✓ | ✗ |
Next Steps
Now that you understand the architecture, explore:
- Request Lifecycle: How requests are processed
- Platform Constraints: Technical limitations to be aware of
- Getting Started: Set up your development environment
- JavaScript Development: Build your first mim
For comprehensive technical details, see the SPEC.md product specification in the repository.