OpenClaw is a control plane that connects large language models to an operating system and messaging apps, running continuously as a background daemon. The architecture — Gateway, HEARTBEAT.md, cron scheduler, plain-text configuration — determines what the tool can do and how it behaves.
The Gateway
The core of OpenClaw is the Gateway — a single Node.js daemon that runs as a background service on your machine. Everything else in the OpenClaw ecosystem is a client of the Gateway or an extension of it.
The Gateway’s job is to sit between your LLMs and your communication channels. It maintains persistent connections to the messaging apps you configure (WhatsApp, Slack, Telegram, Discord, Signal, Microsoft Teams, and more), receives messages from them, routes them to the appropriate LLM with the right context, executes any tool calls or shell commands the LLM requests, and delivers the response back to the channel the message came from.
You interact with your OpenClaw agent the same way you’d message a colleague: open WhatsApp, send a message, get a response. The Gateway is the invisible infrastructure that makes that work.
The daemon runs persistently — it doesn’t start when you open a chat and stop when you close it. It’s always there, which is what makes scheduled monitoring and proactive behavior possible. Think of it as a microservice you happen to run on your own hardware rather than in the cloud.
Model Agnosticism (BYOK)
OpenClaw is built around a bring-your-own-keys model. You connect it to whichever LLMs you want to use:
- Claude (Anthropic) — strong at code and analysis
- GPT-4o / o3 (OpenAI) — broad capability
- Gemini (Google) — useful with a generous free tier
- DeepSeek — cost-effective for high-volume tasks
- Llama via Ollama — local inference, no API costs, no data leaving your machine
You’re not locked into any single provider. This matters in practice for two reasons. First, different models have different cost profiles — you can route low-complexity monitoring tasks to a cheaper model and complex analysis to a more capable one. Second, model capability is still evolving rapidly; BYOK means you adopt new models as they appear without waiting for OpenClaw to update an internal integration.
The model-agnosticism also means your data never goes through OpenClaw’s servers. The API call goes from your machine directly to the LLM provider. OpenClaw routes the conversation; it doesn’t see the content.
The HEARTBEAT.md System
The most architecturally distinct feature of OpenClaw is the HEARTBEAT.md file and the proactive loop it enables.
Every 30 minutes (configurable), the Gateway reads a file at ~/.openclaw/HEARTBEAT.md. This file is a checklist you write yourself — a list of conditions the agent should evaluate and actions it should take if those conditions are met.
A simple example:
# Heartbeat Checklist
- [ ] Check if there are any urgent Slack messages from clients- [ ] Review if any scheduled dbt tests have failed in the last hour- [ ] Flag if any API costs have exceeded daily thresholdsThe agent reads this list, evaluates each condition using whatever tools and information it has access to, and acts if it finds something that warrants action. If a client sent an urgent message, it flags it. If a dbt test failed, it reports it. If everything is fine, it does nothing.
This is the proactive layer — the thing that makes OpenClaw different from tools that only respond when you ask. The agent isn’t waiting for your prompt. It’s checking its checklist, like a colleague who knows what to look out for and tells you when something’s wrong.
For data people, the HEARTBEAT.md can be tuned to the things that matter: source freshness, cost anomalies, pipeline status, test failures. The result is a monitoring loop that runs without you asking for it, using natural language instructions rather than custom scripts.
Plain Text Everything
OpenClaw’s configuration, conversation history, and memory are stored as local Markdown and YAML files. No proprietary database, no binary formats, no cloud sync required.
The primary directories:
~/.openclaw/├── config/ # YAML configuration for channels, models, API keys├── memory/ # Markdown files for persistent agent memory├── cron/│ └── jobs.json # Persisted cron job definitions├── skills/ # Skill directories with SKILL.md files└── HEARTBEAT.md # Proactive monitoring checklistEvery file in this structure is human-readable and human-editable. You can open jobs.json and modify a cron expression directly. You can read the agent’s memory files to see what it has stored about your projects. You can back up the entire directory with Git and restore it on another machine.
Configuration as text follows the same pattern as dbt_project.yml, profiles.yml, and CLAUDE.md: text is auditable and version-controllable.
The practical benefit extends to debugging. When an OpenClaw cron job behaves unexpectedly, you don’t need to decode a binary state file or query a database. You cat the relevant Markdown file and read what the agent has in memory. The debugging workflow is the same one you apply to any text-based tool.
The security implication is a double-edged sword. Plain text files are easy to inspect and audit — but API keys stored in YAML are also easy to exfiltrate if the machine is compromised. This is the same risk profile as any credentials-in-config-file approach; the difference is that attackers actively targeting OpenClaw installations now know exactly which file paths to look for. See OpenClaw Security Risks — What’s Documented for the specific threat landscape.
Shell Access as a First-Class Capability
The Gateway can execute shell commands. This is not an add-on; it’s fundamental to how OpenClaw does anything on your system.
When you ask OpenClaw to “run dbt test and tell me what failed,” the agent:
- Identifies that it needs to run a shell command
- Calls
dbt test --target prodvia the Gateway’s shell execution tool - Captures stdout and stderr
- Parses the output using its LLM capabilities
- Returns a formatted summary to your messaging channel
The agent can run any CLI command: dbt test, dbt run, bq query, snowsql, git status, psql. This is what makes pipeline monitoring and warehouse queries possible without custom API integrations.
Browser automation is also available through full Chrome DevTools Protocol control — navigate pages, fill forms, take screenshots, handle cookies. This is relevant for analytics engineers managing client dashboards that expose data only through a web interface and don’t have APIs.
The Cron Layer
Layered on top of the Gateway is a built-in cron scheduler. Standard five-field cron expressions with timezone support, jobs that persist across restarts, configurable session modes (isolated or main), and delivery targeting for specific messaging channels.
This is covered in depth in OpenClaw Cron Scheduler Mechanics. The architecture point is that the cron scheduler is native to the Gateway — not an external tool calling the Gateway. When a cron fires, it creates an agent session directly inside the Gateway process, which means it has full access to the agent’s memory, skill files, and tool capabilities without additional configuration.
What This Means for the “Always On” Property
The combination of Gateway-as-daemon, HEARTBEAT.md proactive loop, and cron scheduler creates the always-on property that distinguishes OpenClaw from session-based tools like Claude Code.
Claude Code is powerful but transient. You open it, work on something, close it. The session ends. For continuity between sessions, you rely on CLAUDE.md to document project state that Claude can read at the start of the next session.
OpenClaw never closes. The Gateway runs indefinitely. Memory persists between sessions automatically — in Markdown files the agent can read and write. The agent can develop a model of your projects, your client preferences, and your recurring failure patterns over days and weeks, not just within a single conversation.
Scheduled test summaries in Slack, recurring failure pattern recognition, and proactive source freshness flags all follow from the daemon architecture and persistent memory.
The tradeoff is the attack surface this creates. An always-on process with shell access, credential access, and connections to multiple messaging channels is a significant security boundary to manage. See OpenClaw Security Risks — What’s Documented and Security Posture for AI Agents for what that means in practice.