Architecture Overview

Edited by Lawrence Beckwith on September 5, 2026 at 5:45 PM UTC

OtherU's inference and agent components have separate responsibilities. Ember runs the model. Hermes Agent manages conversations and invokes configured tools. Memory services and hardware control are optional integrations around that core.

Request flow

An application sends a request directly to Ember's HTTP API, or a messaging channel delivers it to Hermes Agent. Hermes builds the model request from the conversation and permitted context, then calls Ember. If the response requests a tool, Hermes dispatches it and returns the result to the model for the next turn.

Component Responsibility
Ember Model loading, inference, API responses, and attention-cache management
Hermes Agent Channel routing, tool execution, scheduling, and conversation handling
Hindsight Optional persistent memory and retrieval
Hardware KVM Optional screen capture and keyboard/mouse control of a connected computer

Inference

Ember is a C/C++ engine for DeepSeek-V4-Flash on AMD Strix Halo (gfx1151). The reference deployment uses native Linux, approximately 128 GB unified memory, and Docker with ROCm device access. The current release supports the experimental vision model as well as text requests.

The standard Compose service is available on loopback at port 8080. OtherU's existing internal deployment uses port 8000. Model identity and available endpoints are described in API and Integrations.

Context and persistence

Ember's KV cache stores model attention state to reduce repeated prompt processing. It is distinct from the agent's conversation history and Hindsight's stored memories. Persisting a cache can improve session reuse; it is not a backup of agent state or evidence that a response is correct.

Boundaries and recovery

Ember does not execute the agent's tools. Those tools run with the agent's credentials and host permissions. Each network service and external integration adds its own access and data-handling requirements; see Security Model.

Container restart policies recover the inference process after failures. They do not recover every agent workflow or cancel an action already in progress. Operational checks should distinguish API availability, successful inference, channel delivery, and tool execution.