How OpenClaw Works: Gateway, Agents, Tools & Channels

OpenClaw is easiest to understand as a local control plane around a model—not as “a chatbot with plugins.” The model chooses actions, but the Gateway, tools, configuration, credentials, channels, and state determine what those actions can actually reach.

The six-layer model

Channel / Control UI
        ↓
      Gateway
        ↓
 Agent + session state
        ↓
 Model provider / local model
        ↓
 Tools, Skills, and plugins
        ↓
 Files, services, and external APIs

When something breaks, find the first failing layer instead of editing all six at once.

Gateway

The Gateway is the long-running process that coordinates client access, channels, service state, and local operations. If Telegram, Discord, and the Control UI fail together, verify the Gateway before debugging each integration.

openclaw gateway status
openclaw gateway probe

A healthy service reports a running runtime and successful connectivity. A probe can also report the capability level its credentials proved.

Agents and sessions

An agent combines defaults, identity, model policy, tools, Skills, and workspace access. A session adds conversation state and can pin a model selection. That pin matters: an explicit user-selected session model is strict and can fail visibly rather than moving through configured fallbacks.

Models and providers

OpenClaw refers to a model as provider/model. Authentication rotates within a provider before the runtime moves to a configured fallback model. Provider setup and model policy are related but separate: adding a model entry does not automatically add it to an allowlist.

openclaw models status
openclaw models list
openclaw models set <provider/model>

Tools, Skills, and plugins

These terms should not be collapsed:

• A tool is an action interface the model can call.
• A Skill is a SKILL.md instruction package that teaches when and how to use tools.
• A plugin can add runtime capabilities and may ship tools or Skills.

Skills are instructions, but instructions can still direct powerful actions. Plugins are code. Both require provenance and permission review.

Channels

Channels connect messaging systems to the Gateway. A channel has at least three states to reason about:

1. Provider transport is connected.
2. The sender or room passes pairing and allowlist policy.
3. The agent and model complete the turn.

An online bot can fail at step two. A working channel probe can still be followed by a model auth error at step three.

State and configuration

Configuration defines model policy, tools, channels, Gateway behavior, Skills, and security choices. State also includes credentials, pairing records, session data, and channel-specific persistence. Back up and protect state; do not commit it to a repository.

The diagnostic ladder

openclaw status
openclaw status --all
openclaw gateway probe
openclaw gateway status
openclaw doctor
openclaw channels status --probe
openclaw logs --follow

This sequence moves from a summary to a shareable report, endpoint reachability, service state, configuration diagnostics, channel transport, and finally live evidence.

Security consequence

The model is only one part of the trust boundary. The practical security question is: if untrusted content influences the model, which tools, credentials, files, channels, and remote systems can the resulting action reach? Design that boundary before optimizing prompts.