Map the Gateway and its operating surfaces

Verifiedon 2026-07-302026.7.1-2

The useful mental model

OpenClaw is not a chat bot embedded inside each messaging service. Its long-lived Gateway is the control point: it owns channel connections, routing, and session state. Operator clients such as the CLI, Control UI, and macOS app connect to the Gateway; nodes connect to the same WebSocket server but declare a node role and explicit capabilities. The Gateway is therefore the first box to draw, not an invisible wire between a chat app and a model.

operator client ──┐                         ┌── model provider
Control UI / CLI ─┼── WebSocket ── Gateway ─┼── agent workspace + state
paired node ──────┤          │              ├── tools / plugins
chat channel ─────┘          └──────────────┴── outbound channel reply

Gateway owns routing and sessions. A session key selects context; it is not authority.

Lab: build an operating map

On paper or in a local diagram, make six labelled boxes: inbound channel, Gateway, agent, model provider, tool or node, and outbound recipient. For every real box, add:

1. the accountable owner;
2. the identity used at the boundary (for example a paired device, provider credential, or channel account);
3. the data that crosses it; and
4. the stop rule before an external action.

Keep hostnames, phone numbers, tokens, recipient names, and private paths out of the map. A question mark is better evidence than an invented connection.

Check your map

Answer these without looking at the diagram: Which component is the source of truth for sessions? Which surfaces are merely clients? What capability has a node explicitly declared? If your diagram says that a session ID authenticates an operator, correct it: routing context is not an authorization boundary.

Check your understanding