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

> Explore OpenHuman's Rust core architecture, detailing 18 domain families like Agent, Memory, and Security. Learn how to configure deployments with the DomainSet builder.

- Repository: [Tiny Humans/openhuman](https://github.com/tinyhumansai/openhuman)
- Tags: architecture
- Published: 2026-08-26

---

**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`](https://github.com/tinyhumansai/openhuman/blob/main/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`](https://github.com/tinyhumansai/openhuman/blob/main/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`](https://github.com/tinyhumansai/openhuman/blob/main/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):

```rust
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:

```rust
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:

```rust
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`](https://github.com/tinyhumansai/openhuman/blob/main/src/core/all.rs) registers all available families, while the **`DomainSet` builder** in [`src/core/runtime/builder.rs`](https://github.com/tinyhumansai/openhuman/blob/main/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`](https://github.com/tinyhumansai/openhuman/blob/main/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`](https://github.com/tinyhumansai/openhuman/blob/main/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.