Main Domain Families in the OpenHuman Rust Core: A Complete Architecture Guide

OpenHuman's Rust core organizes functionality into 18 modular domain families—including Agent, Memory, Security, and Web3—that can be selectively loaded at runtime via the DomainSet builder to configure kernel-only, harness, or full-product deployment modes.

The tinyhumansai/openhuman repository implements a modular runtime where distinct functional units called domain families encapsulate related capabilities. Each family owns its controllers, stores, event subscribers, and tool implementations within dedicated source directories under src/openhuman/. This architecture allows the core to compile and launch with only the necessary components, keeping binaries lean while supporting everything from lightweight agents to full desktop applications.

Core Architecture and the DomainGroup Enum

At the heart of this system lies the DomainGroup enum defined in src/core/all.rs. This enumeration registers every available domain family and maps each variant to its corresponding controllers, stores, and event subscribers. The runtime uses this registry to instantiate only the families specified during the build process.

The DomainSet builder in src/core/runtime/builder.rs provides the programmatic interface for selecting families. Developers can invoke DomainSet::harness() to load only foundational families, DomainSet::full() to activate the entire suite, or construct custom sets for specialized deployments. This selection occurs at startup, allowing a single codebase to power embedded agents, desktop applications, or cloud-hosted services depending on the enabled domains.

Foundation Domain Families

These six families constitute the kernel of the OpenHuman runtime. They provide essential capabilities for agent operation, data persistence, and system security.

Agent Family (src/openhuman/agent)

The Agent family implements the core harness, tool-calling dialects, orchestration logic, session management, and artifact handling. It serves as the primary interface between the runtime and autonomous agent behaviors, managing the lifecycle of agent instances and coordinating tool execution across other domains.

Memory Family (src/openhuman/memory)

The Memory family provides hierarchical knowledge storage, retrieval mechanisms, content chunking, and diffing algorithms. It manages the people/address-book, goal tracking, and tool-specific memory implementations that enable long-term context retention across sessions.

Threads Family (src/openhuman/threads)

The Threads family handles conversation thread management, todo lists, goal tracking at the thread level, and thread-filtering logic. It maintains metadata for conversational contexts and provides the structural foundation for multi-turn interactions.

Config Family (src/openhuman/config)

The Config family manages persistent configuration schemas, database migrations, workspace handling, and environment variable overrides. It ensures type-safe configuration access across all other domain families while maintaining backward compatibility through migration helpers.

Security Family (src/openhuman/security)

The Security family implements the approval gate system, credential and keyring management, device trust verification, prompt-injection defenses, and Land-Lock sandboxing. It acts as the security boundary for sensitive operations, requiring explicit user approval for high-risk actions.

Platform Family (src/openhuman/platform)

The Platform family supplies core kernel services including health checks, cost accounting, diagnostic tools ("doctor"), service lifecycle management, and update handling. It monitors system health and manages the operational aspects of the runtime environment.

Automation and Execution Families

These four families enable workflow automation, scheduled tasks, and secure code execution within the OpenHuman ecosystem.

Flows Family (src/openhuman/flows)

The Flows family implements user-defined automation graphs through the TinyFlows engine and Rhai scripting support. It handles schedule-triggered workflow execution and provides the visual programming interface for creating complex automation pipelines.

Skills Family (src/openhuman/skills)

The Skills family manages the skill catalogue and provides runtime environments (Node.js and Python) for executing SKILL.md workflow definitions. It includes specialized skill-executor agents that can interpret and run third-party skill packages in isolated contexts.

Cron Family (src/openhuman/cron)

The Cron family implements the scheduler subsystem for recurring jobs, maintains run-history storage, and provides cron-specific tool implementations. It handles temporal triggers and ensures reliable execution of time-based automation rules.

Sandbox Family (src/openhuman/sandbox)

The Sandbox family creates secure execution environments using Docker containers, CWD-jail mechanisms, and OS-specific sandboxing techniques. It isolates untrusted code execution from the host system, providing defense-in-depth for dynamically loaded skills and workflows.

Integration and Interface Families

These six families manage external communications, blockchain interactions, and media processing capabilities.

MCP (Micro-Control-Plane) Family (src/openhuman/mcp)

The MCP family enables remote-hosted tool execution through the Micro-Control-Plane architecture. It maintains the server registry, audit logging for remote operations, and config-server handling for distributed tool deployments.

Voice Family (src/openhuman/voice)

The Voice family orchestrates speech-to-text (STT) and text-to-speech (TTS) pipelines, manages dictation hotkeys, and handles podcast generation workflows. It abstracts multiple cloud voice providers behind a unified interface for audio interaction.

Web3 Family (src/openhuman/web3)

The Web3 family implements multi-chain cryptocurrency wallet functionality, X-402 payment protocol support, address validation, and transaction building. It enables the agent to interact with blockchain networks and perform crypto-economic operations securely.

Media Family (src/openhuman/media)

The Media family provides generation tools for images, video, and audio content. It acts as a proxy layer to backend media generation services, abstracting provider-specific APIs behind standardized tool interfaces.

Channels Family (src/openhuman/channels)

The Channels family manages external messaging providers including Telegram, Discord, Slack, iMessage, and WhatsApp. It includes associated webview bridges that enable the agent to interact with these platforms through both official APIs and browser automation.

Integrations Family (src/openhuman/integrations)

The Integrations family contains first-party connector implementations for external services such as Twilio, Google Places, and stock-price APIs. It provides the scaffolding for adding new third-party service integrations to the core runtime.

Cloud and Hosted Service Families

These two families support the commercial cloud-hosted deployment of OpenHuman.

Hosted Family (src/openhuman/hosted)

The Hosted family implements cloud-hosted product surfaces including billing management, team administration, referral systems, and orchestration UI components. It differentiates the commercially hosted version from self-hosted deployments.

Medulla Family (src/openhuman/medulla)

The Medulla family handles backend-side "tinyplace" orchestration and payment flow integration. It coordinates complex multi-step transactions and manages the integration between the agent runtime and backend infrastructure services.

Runtime Configuration Examples

You can configure which domain families load at startup using the CoreBuilder and DomainSet APIs. This allows you to create specialized builds for different deployment scenarios.

To create a minimal core with only kernel families (Agent, Memory, Threads, Config, Security):

use openhuman_core::core::runtime::builder::CoreBuilder;
use openhuman_core::core::runtime::builder::DomainSet;

let core = CoreBuilder::new()
    .domains(DomainSet::harness())   // loads only the kernel families
    .services(ServiceSet::none())
    .build()
    .await?;

To enable the full product suite for a desktop application:

use openhuman_core::core::runtime::builder::{CoreBuilder, DomainSet, ServiceSet};

let core = CoreBuilder::new()
    .domains(DomainSet::full())      // activates every domain family
    .services(ServiceSet::desktop()) // starts desktop-specific services
    .build()
    .await?;

To introspect which families are currently active in a running core:

let active = core.context().domains().active_families();
println!("Active domain families: {:?}", active);

Summary

• OpenHuman's Rust core organizes functionality into 18 distinct domain families, each owning specific controllers, stores, and event subscribers under src/openhuman/<family>/.
• The DomainGroup enum in src/core/all.rs registers all available families, while the DomainSet builder in src/core/runtime/builder.rs controls runtime selection.
• Kernel-only mode loads only foundational families (Agent, Memory, Threads, Config, Security, Platform) via DomainSet::harness().
• Full-product mode activates all 18 families including Web3, Voice, Media, and Hosted services via DomainSet::full().
• Domain families cooperate through a shared event bus and JSON-RPC layer, ensuring modularity while maintaining system cohesion.

Frequently Asked Questions

What defines a domain family in the OpenHuman architecture?

A domain family is a logical grouping of related functionality that encapsulates its own controllers, data stores, event subscribers, and tool implementations. Each family resides in its own source directory under src/openhuman/ and can be independently enabled or disabled at compile time and runtime. This modularity allows the core to remain lightweight when running as a simple agent harness while scaling up to full desktop or cloud deployments.

How do I restrict the OpenHuman core to load only specific domain families?

Use the DomainSet builder methods when constructing the core runtime. Call DomainSet::harness() to load only kernel families, DomainSet::full() for complete functionality, or construct a custom selection using the builder pattern defined in src/core/runtime/builder.rs. After building the core, you can verify active families by calling core.context().domains().active_families(), which returns the currently loaded domain set.

Where is the definitive list of available domain families cataloged?

The canonical enumeration of all domain families exists in the DomainGroup enum located in src/core/all.rs. This file serves as the registry that maps each family variant to its implementation modules, controllers, and initialization logic. When adding new functionality to OpenHuman, developers must register the new family in this enum to make it available to the DomainSet builder.

What is the difference between kernel-only and full-product deployment modes?

Kernel-only mode (activated via DomainSet::harness()) loads only the six foundation families—Agent, Memory, Threads, Config, Security, and Platform—providing a minimal runtime suitable for embedded agents or headless automation. Full-product mode (activated via DomainSet::full()) enables all 18 domain families including Web3 wallets, voice processing, media generation, and cloud-hosted services, supporting the complete desktop application experience with all integrations active.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}