From Events to Visible Automation

OpenHuman’s durable turn can answer a request, but a useful assistant also has to know when a request arrives without a person typing it. This chapter follows the path from an external event to a guarded workflow run. The focus is the boundary between noticing and acting: how OpenHuman triages noise, lets the agent propose a visible graph, and keeps trusted automation configuration separate from untrusted event data.

Always-on does not mean always escalate

A connected service can play several roles in OpenHuman. It can expose tools the agent calls on demand, feed the local memory pipeline, contribute evidence to personalization, and publish live events. That combination is powerful because one new email or project update can become both memory and a possible action. It is also dangerous as a default execution policy. A busy inbox can produce many events, and most do not deserve a full reasoning turn.

OpenHuman’s trigger pipeline therefore inserts a fast triage step between an incoming event and the main orchestrator. The event arrives through the integration boundary in a normalized form, reaches the local core, and is classified into one of four broad outcomes: drop, acknowledge, react, or escalate.

A dropped event is noise or an irrelevant duplicate. It may be recorded in history without interrupting the user or spending a full agent turn. An acknowledged event is worth remembering but does not require an action; the system can persist a short memory note. A reacted event goes to a narrow reactor for a small, bounded response, such as recording a structured fact or handling a simple acknowledgement. An escalated event is handed to the full orchestrator because it needs multi-step reasoning, several tools, or a decision that cannot be reduced to one small action.

This separation is a cost and latency mechanism, but it is also a safety boundary. The triage agent decides how much of the system should be activated. It does not turn every webhook into permission to run the full tool surface. A cheap classification can absorb routine noise, while the deeper agent is reserved for events that earn the additional context, model calls, and potential side effects.

Consider a new message in a connected work channel. If it is an automated status notice that has appeared repeatedly, the appropriate outcome may be a quiet acknowledgement or a drop. If it contains a new decision about a project, the system may store it in memory so it can be recalled later. If it is a small, well-understood event that warrants marking or recording, a reactor may handle it. If it asks for a reply that requires checking several systems, the event can be escalated to the orchestrator. The important distinction is between “this happened,” “remember this,” and “do something about it.”

The pipeline also provides an operational trail. The documented trigger system keeps history of what arrived and what the classifier decided, exposes settings and opt-out behavior, and routes selected outcomes into notifications or background activity. That visibility matters because a quiet assistant can fail in two opposite ways: it can interrupt the user with every event, or it can act without leaving a useful explanation of why an event was considered important.

Triage also lets importance and action remain separate. A notification can be worth surfacing without authorizing a write to an external service.