#OpenClaw Architecture & Features

OpenClaw's architecture is refreshingly down-to-earth: a single Node.js process carries all the capability. Understanding it helps you deploy, tune, and troubleshoot.

#The Single-Process Gateway Model

OpenClaw runs as one persistent Node.js process whose five subsystems cooperate. Everything else — routing, tools, memory, state — lives inside that one process on your machine.

┌──────────────────────────────────────────────────────────────┐
│              OpenClaw Gateway (single Node process)          │
│                                                              │
│  ① Channel Adapters  ② Session Manager  ③ Queue             │
│                                                              │
│  ④ Agent Runtime ─────────────────────  ⑤ Control Plane     │
│     (assemble context + agent loop)        WebSocket :18789  │
└──────────────────────────────────────────────────────────────┘
        │                                          │
        ▼                                          ▼
  Chat platforms (WhatsApp/Telegram/…)     Dashboard / CLI / App
        │
        ▼
  ┌──────────────────────────┐      ┌────────────────────────┐
  │ ~/.openclaw + workspace   │      │  LLM Provider (model)  │
  │ Markdown/YAML memory+skills│     │  Anthropic/OpenAI/local│
  └──────────────────────────┘      └────────────────────────┘

#The Five Subsystems

The control plane listens on 127.0.0.1:18789 by default, and the Dashboard is http://127.0.0.1:18789/. The security of this port matters — a cross-site WebSocket hijacking flaw once made it a critical vulnerability (see Security).

#The Agent Loop

The agent runtime runs a classic sense–think–act loop:

1. Assemble context: load relevant memory, available tools/skills, current history
2. Call the LLM: hand it to the chosen model; get a reply or a tool call
3. Execute tools: run shell / browser / email, etc., where tool policy allows
4. Write back: feed tool output back to the model, keep reasoning until done
5. Consolidate: update Markdown/YAML memory and draft skills as needed

#Local Storage Layout

OpenClaw stores state as plain text, making backup, versioning, and auditing easy:

~/.openclaw/              # Global state directory
├── openclaw.json         # Main config (provider, tool policies, model routing, autonomy)
├── memory/               # Long-term memory (Markdown/YAML)
├── skills/               # Skills (SKILL.md)
└── ...
<workspace>/
├── HEARTBEAT.md          # Heartbeat checklist (autonomy tasks)
├── SKILL.md / skills/    # Workspace-level skills
└── ...                   # Conversation and project files

Adjust paths with environment variables:

#Heartbeat: Making the Agent Proactive

One of OpenClaw's signature capabilities is the Heartbeat scheduler: it "wakes" the agent at a configurable interval so it can run without being prompted.

heartbeat fires (default every 30 min)
   → agent reads the workspace's HEARTBEAT.md checklist
   → decides whether action is required
   → if yes: perform the task and report
     if no:  respond HEARTBEAT_OK

With Anthropic OAuth, the default interval is roughly hourly. Besides the heartbeat, webhooks, cron, and teammate messages can also invoke the agent loop. See CLI & Automation.

#Key Features at a Glance

• Minimal deployment: single process, plain-text state, starts on 2GB/2 cores
• Reuses chat apps: no custom frontend needed
• Transparent & auditable: memory/skills are readable text, Git-able
• Model-agnostic: cloud or local, with fallback chains
• Born autonomous: Heartbeat + Webhooks + Cron
• Console-managed: local Dashboard / CLI / desktop app

#Next Steps

• Installation & Usage — get the gateway running
• Memory System — how plain-text memory is organized
• CLI & Automation — Heartbeat and trigger mechanisms