What Is OpenClaw

⏱️ 15 min

OpenClaw is not simply “ChatGPT installed on a computer.” Its official documentation describes it as a self-hosted AI agent gateway: channels send requests to the Gateway, the Gateway owns sessions, routing and channel connections, and the agent can then use models, tools or skills.

That distinction matters. A chatbot mainly returns answers. OpenClaw may also read files, invoke tools, run scheduled work or write to external systems. More capability creates a larger permission and operations surface.

The architecture in one view

Channels / Control UI
          ↓
       Gateway
   ┌──────┼────────┐
Sessions Routing Connections
          ↓
        Agent
   ┌──────┼────────┐
 Model   Skill     Tool
          ↓
  Logs / Approval / Rollback

The official docs call the Gateway the single source of truth for sessions, routing and channel connections. Treat it as the control plane, not as the model itself.

What each component owns

Component	Responsibility	Common misread
Channel	Receive and send messages	A channel is an entry point, not the complete authorization boundary
Gateway	Manage connections, sessions and routing	One Gateway is not hostile multi-tenant isolation
Session	Hold conversational context	A session key selects routing; it is not an authorization token
Agent	Combine model, context and behaviour	Visibility and action permissions must be controlled separately
Skill	Package reusable instructions and resources	Provenance, dependencies and external effects still need review
Tool	Read, compute or take an external action	File, shell, network and browser tools have real side effects

Good first tasks

Start with one low-risk, reversible task:

access a personal assistant through one private channel;
organize non-sensitive files in one named directory;
turn a fixed source into a draft for human confirmation;
call one read-only tool inside an explicit allowlist;
create a reminder without sending a commitment on the user's behalf.

Do not make the first project an assistant that can read every file, execute arbitrary shell commands, listen to every group and send messages automatically. That is a large failure radius, not a better prototype.

Self-hosted does not mean data never leaves the machine

The Gateway may run on your device or server. Data destinations still depend on:

the model provider;
the messaging channel;
external tools and APIs;
logging, backup and monitoring storage.

“Runs locally” identifies the Gateway location. It does not replace a data-flow inventory.

Choose a first use case

Goal	Recommended baseline	Keep disabled for now
Reach a personal assistant from a phone	One private channel plus pairing/allowlist	Groups, cron and write-capable file tools
Automate repeated information work	Fixed input, draft output and human confirmation	Automatic sending, deletion and unrestricted network access
Isolate work roles	Prove one agent first, then evaluate multi-agent routing	Shared credentials and shared high-privilege workspaces

Practice: define the system boundary

Write four lines for the first OpenClaw use case:

Operator: who may request work?
Input: which messages, files or systems may be read?
Action: what may the agent do, and what requires approval?
Rollback: how is failure stopped, reversed and reported?

Done means another operator can use these four lines to accept or reject a proposed permission.