What OpenHuman Can—and Cannot—Promise

OpenHuman is not experienced through one interface or one kind of run. The same core can appear as desktop chat, a connected messaging channel, a scheduled task, a workflow, a notification, or a voice interaction. This chapter tests what that breadth means in practice. It connects shared memory, policy, and observability to the freshness, credential, cost, and provider boundaries that determine whether an early-beta system is ready for a particular workflow.

One core, many surfaces

A shared core is valuable because users should not have to teach the assistant a different identity every time they change the interface. OpenHuman’s documented channel model normalizes inbound messages, sends replies through the originating channel, and can deliver proactively when a trigger, scheduled job, or background process has a suitable destination. The web chat, external messaging surfaces, notifications, and workflow activity are different entry points into related execution machinery.

That breadth also increases the need for policy consistency. A tool call that requires approval in desktop chat should not become harmless merely because a message arrived through another channel. A scheduled workflow may have a different authorization origin from an interactive turn, but the difference must be explicit. Credentials, reply targets, threads, typing indicators, and delivery capabilities vary by channel; the underlying question remains the same: which agent run owns the state, which tools are visible, and which side effects are allowed?

The channel documentation describes many messaging providers, including Telegram, Discord, the built-in web surface, iMessage, Slack, WhatsApp, and native email. Those are not interchangeable transports. Some use managed account linking, some require user-owned credentials, some are local-only, and some depend on webhook reachability or platform permissions. A channel is therefore part of the trust boundary, not just a user-interface skin.

Voice makes the same point more strongly. OpenHuman documents local audio capture, speech-to-text and text-to-speech paths, a mascot surface, and meeting participation that can write transcripts into the local memory system. The experience may feel conversational, but the data path is not necessarily local at every stage. The current voice documentation describes hosted speech boundaries, while other repository text uses different language about the speech engine. The safe claim is that voice extends the same memory-and-agent architecture while adding audio consent, provider, and retention questions.

Notifications and activity views provide a second kind of interface: they show what happened when the user was not watching the main chat. A triaged integration item can become an alert; a background run can produce a success or failure notification; an approval request can require attention. This is where the architecture’s observability promise reaches ordinary use. If the system is proactive, the user needs a place to see not only the result but the fact that a decision was made in the background.

The shared core also creates a maintenance obligation. A channel can normalize a message correctly and still expose a different reply target, credential model, or approval surface from desktop chat. Email can be a powerful inbound channel but also a new way for an unknown sender to prompt the agent. A meeting transcript can become useful memory but may involve people who never chose OpenHuman as their assistant.