OpenClaw Tutorial: Self-Hosted AI Agent Build Guide

OpenClaw is a free, open-source AI agent framework that turns large language models into autonomous personal assistants capable of running 24/7 on your own hardware. Originally published in November 2025 under the name Clawdbot by Austrian developer Peter Steinberger, it was renamed to OpenClaw in January 2026 and has since become one of the fastest-growing open-source projects in history, surpassing 250,000 GitHub stars in roughly 60 days. Unlike chatbot interfaces that wait for your input, OpenClaw operates proactively through a heartbeat daemon, scheduled tasks, and deep integrations with messaging platforms you already use. This guide covers architecture, installation, configuration, security hardening, and enterprise deployment patterns based on our evaluation of the framework for client environments.

At Petronella Technology Group, we evaluate AI agent frameworks for clients in regulated industries including healthcare, defense contracting, and financial services. We have deployed and tested OpenClaw alongside other frameworks like CrewAI, LangChain, and AutoGPT to understand where each one fits. We wrote this guide because OpenClaw introduces a fundamentally different approach to agent configuration that favors operators over developers, and the security implications of that design choice deserve careful analysis.

What’s New in OpenClaw 2026 (Release Tracker)

OpenClaw shipped six tagged releases between January and May 2026, with the 2026.4.x series consolidating the project’s response to the security findings that emerged after its viral growth in February. If you are running an older 2025 build or one of the early 2026.1.x or 2026.2.x previews, the upgrade path is straightforward but the security delta is significant. This section tracks every public release on the 2026.4 branch, what changed, and what existing operators should test before upgrading.

v2026.4.15 (April 15, 2026). The current stable release. Closes seven security advisories that were filed during the post-launch security review, hardens the Gateway WebSocket handshake so unauthenticated control-plane probes are rejected before any session is allocated, ships Landlock and seccomp profile templates inside the official Docker image, fixes a memory-poisoning bug in the Active Memory plugin where attacker-controlled MEMORY.md content could bypass the relevance filter, and tightens the default skill-installation flow so unsigned skills require an explicit acknowledgement flag. Recommended track for all production deployments. The release notes also rename several legacy CLI flags; check the migration table at openclaw.ai/changelog/2026.4.15 before upgrading.

v2026.4.14 (April 14, 2026). Backport branch for organizations that cannot move to 2026.4.15 immediately. Receives security patches but no new features. Reverts the experimental websocket multiplexer that destabilized 2026.4.13.

v2026.4.12 (April 12, 2026). Introduces the codex_provider environment variable that lets operators route code-related actions to a different LLM than the default conversational provider. Also adds initial Landlock support behind a feature flag and improves Telegram channel reconnect behavior. The 2026.4.12 build is still widely deployed because of the codex_provider addition and is receiving backports through May.

v2026.4.11 (April 11, 2026). First release of the v2026.4 line. Refactors the heartbeat task parser so natural-language timing expressions are evaluated with a deterministic resolver, eliminating the off-by-one execution drift that operators reported in 2026.3.x. Also formalizes the AGENTS.md routing schema and adds a strict-mode parser for it.

v2026.3.31 (March 31, 2026). Final 2026.3.x release. Recommended only for users who are pinned to that line by an enterprise change-control window; everyone else should be on 2026.4.x. Receives critical-only patches through end of June 2026.

v2026.2.x and earlier. Considered end-of-life. The Active Memory plugin in these versions is vulnerable to the memory-poisoning issue patched in v2026.4.15. If you are still running a 2026.2 build, treat it as a security incident on its own and prioritize the upgrade ahead of any other work.

Upgrade checklist. Before upgrading any production agent, take a snapshot of the workspace directory, run openclaw doctor against the current install, review the changelog for renamed CLI flags, and stage the upgrade against a non-production agent for at least one full heartbeat cycle. The release cadence under the foundation steward model is roughly six weeks between minor versions; subscribe to the security advisory mailing list at openclaw.ai/security if you operate agents in regulated environments.

What Is OpenClaw and What Problem It Solves

Most interactions with large language models follow a request-response pattern. You open a chat interface, type a question, receive an answer, and close the tab. The model has no memory of previous conversations unless you manually provide context. It cannot act on your behalf when you are not at the keyboard. It does not know your preferences, your schedule, or the tools you use daily.

OpenClaw closes that gap. It is an autonomous AI agent that runs as a background service on your own hardware, connects to the LLM provider of your choice, and interfaces with you through messaging platforms like WhatsApp, Telegram, Discord, Slack, Signal, iMessage, and over 20 other channels. Instead of opening a separate chat app, you message your AI assistant through the same apps you already use for communication.

The framework is model-agnostic. It supports Anthropic Claude (Opus, Sonnet, Haiku), OpenAI GPT-4 and GPT-5 family models, Google Gemini 2.5 Pro and Flash, xAI Grok models, Mistral Large and Codestral, and DeepSeek V3 and R1. You can also run local models through Ollama or any OpenAI-compatible API endpoint for complete data isolation.

The core insight behind OpenClaw is that agent behavior should be defined in configuration, not code. The centerpiece of this philosophy is the SOUL.md file, a plain Markdown document that defines your agent’s identity, personality, capabilities, and behavioral rules. Changing how your agent behaves is as simple as editing a text file. This makes the framework accessible to operators and system administrators, not just software developers.

Peter Steinberger, already well-known in the iOS development community as the founder of PSPDFKit, built the initial prototype during a single coding session. He released it under the MIT license with no commercial restrictions, no dual licensing, and no open-core limitations. Companies can build products on OpenClaw, fork it, modify it, and redistribute it without legal friction. That licensing decision, combined with the practical utility of the tool, drove its explosive adoption.

Architecture: Gateway, Workspace, and Heartbeat

OpenClaw’s architecture consists of three primary components that work together to create a persistent, proactive AI assistant.

The Gateway

The Gateway is a long-lived daemon process that serves as the single control plane for all messaging channels, sessions, tools, and events. It is the always-on boundary between humans, messaging channels, and agent execution. The Gateway manages connections to all messaging surfaces including WhatsApp (via Baileys), Telegram (via grammY), Slack (via Bolt), Discord (via discord.js), Google Chat, Signal, BlueBubbles for iMessage, IRC, Microsoft Teams, Matrix, and many more.

Control-plane clients such as the macOS app, CLI, web UI, and automations connect to the Gateway over WebSocket on the configured bind host (default 127.0.0.1:18789). This architecture means the Gateway is the single process you keep running. Everything else connects to it.

The Workspace

OpenClaw agents do not live in databases or configuration panels. They live in plain text files inside a workspace folder, typically at ~/.openclaw/workspace/. When the Gateway starts an agent session, it reads these files and assembles the agent’s identity, behavior rules, memory, and task schedule on the fly. The workspace includes several key files:

• SOUL.md defines the agent’s personality, values, tone, and behavioral boundaries
• AGENTS.md configures multi-agent routing and specialized sub-agents
• HEARTBEAT.md schedules proactive tasks using natural language
• MEMORY.md stores accumulated knowledge and preferences as Markdown
• USER.md stores information about the human user
• TOOLS.md configures which tools and skills the agent can access

Because everything is plain text, you can version control your agent configuration with Git, review changes in pull requests, and roll back to previous versions. This is a significant advantage over frameworks that store configuration in databases or opaque binary formats.

The Heartbeat

The heartbeat system is what makes OpenClaw proactive rather than reactive. Unlike standard LLM interactions that only respond to human input, the heartbeat daemon wakes the agent periodically (every 30 minutes by default) to assess the state of the world and execute scheduled tasks. HEARTBEAT.md uses natural language scheduling, not cron syntax. You write tasks like “Every Monday at 9 AM, summarize my unread emails” or “Every 2 hours, check for new security advisories.” When the heartbeat fires and finds a task whose time has come, it executes it autonomously.

This design turns OpenClaw from a chatbot into a continuous agent. It can monitor RSS feeds, check email, summarize daily activity, remind you of deadlines, and run maintenance tasks without any human prompting.

Key Features and Capabilities

OpenClaw ships with a broad set of capabilities that cover most personal and professional automation needs.

Multi-channel messaging. Connect to 25+ messaging platforms through a single agent. Your assistant is reachable wherever you already communicate. The multi-channel inbox means you can message it from WhatsApp on your phone during a commute and continue the same conversation from Slack on your desktop.

Multi-agent routing. Route inbound channels, accounts, or peers to isolated agents. Each agent gets its own workspace and per-agent sessions, allowing you to run separate agents for personal tasks, work tasks, and client-facing interactions without cross-contamination.

Voice wake and talk mode. OpenClaw supports voice interaction for hands-free operation. This is particularly useful for accessibility and for workflows where you need to interact with the agent while your hands are occupied.

Live Canvas. An agent-driven visual workspace that allows the agent to create and manipulate visual content collaboratively with the user.

First-class tools. Built-in tools include browser automation, canvas rendering, node-based workflows, cron scheduling, session management, and native actions for Discord, Slack, and other platforms.

100+ AgentSkills. Preconfigured skill packages that allow the AI to execute shell commands, manage file systems, perform web automation, control smart home devices, interact with productivity tools, and integrate with 50+ third-party services.

Local-first memory. All memory is stored as Markdown files and JSONL transcripts on your local machine. Your data never leaves your infrastructure unless you explicitly configure a cloud LLM provider. Even then, the memory files themselves stay local.

Active Memory plugin. An optional sub-agent that runs before the main reply, automatically pulling in relevant preferences, context, and past details from memory files without requiring the user to manually say “remember this” or “search memory.”

Installation and Setup Guide

OpenClaw runs on macOS, Linux, Windows (via WSL2), iOS, and Android. The following installation methods are available, ordered from simplest to most configurable.

One-Line Install (Recommended for Getting Started)

The quickest path to a running agent:

curl -fsSL https://openclaw.ai/install.sh | bash

This script installs Node.js if it is not already present, installs OpenClaw globally, and runs the onboarding wizard. The onboarding prompts you for your preferred LLM provider and API key, then generates initial workspace files. Total time from command to working agent: under five minutes.

npm Install

If you already have Node.js 18+ installed:

# Install globally
npm install -g openclaw

# Verify installation
openclaw --version

# Start the agent (runs onboarding on first launch)
openclaw start

Docker Install

Docker provides the strongest isolation and is the recommended method for production deployments and for environments where you want to limit what the agent can access on the host system.

# Pull the official image
docker pull openclaw/openclaw:latest

# Run with basic configuration
docker run -d \
  --name openclaw \
  -p 3000:3000 \
  -v ~/.openclaw:/root/.openclaw \
  openclaw/openclaw:latest

Docker Compose (Recommended for Production)

For production deployments, the included Docker Compose setup provides a more complete configuration:

# Clone the repository
git clone https://github.com/openclaw/openclaw.git
cd openclaw

# Run the setup script (builds image, runs onboarding, generates .env)
./scripts/docker/setup.sh

# Start the stack
docker compose up -d

The setup script handles onboarding automatically, prompting for provider API keys, generating a Gateway token, and writing everything to the .env file before starting the Gateway via Docker Compose.

Prerequisites

All installation methods require Node.js 18+ and npm 9+ (included with Node.js). For Docker installations, you need Docker Engine 20.10+ and Docker Compose v2. For local model support, Ollama must be installed separately and running before OpenClaw starts.

Configuring Your Agent with SOUL.md

SOUL.md is the first file OpenClaw reads at the start of every session. It is injected into the system prompt before every message, making it the foundation of your agent’s behavior. Think of it as a character sheet that defines who your agent is and how it should act.

A basic SOUL.md file looks like this:

# Soul

## Identity
You are Atlas, a technical assistant for an IT services company.
You specialize in cybersecurity, compliance frameworks, and
infrastructure management.

## Communication Style
- Be direct and technical. Avoid marketing language.
- When you don’t know something, say so clearly.
- Provide specific commands, config examples, and file paths.
- Default to security-first recommendations.

## Values
- Accuracy over speed. Verify before recommending.
- Privacy by default. Never suggest sending sensitive data
  to third-party services without explicit approval.
- Compliance awareness. Consider CMMC, HIPAA, and SOC 2
  implications in every recommendation.

## Boundaries
- Never execute destructive commands without confirmation.
- Never access files outside the designated workspace.
- Never share credentials, API keys, or sensitive data in chat.
- Always recommend backups before system changes.

The SOUL.md file supports any Markdown formatting. You can include detailed instructions, reference documents, decision trees, and behavioral rules. The entire contents are injected into the system prompt, so the length directly affects token usage per message. Keep it focused on the behavioral rules that matter most.

An important security consideration: SOUL.md is the primary target for prompt injection attacks. A compromised SOUL.md means a permanently altered agent. Treat this file with the same security posture as SSH keys or API credentials. Store it in version control, monitor it for unauthorized changes, and restrict file system permissions on production deployments.

Workspace Files: AGENTS.md, HEARTBEAT.md, and MEMORY.md

AGENTS.md

AGENTS.md configures how inbound messages are routed to different agent instances. You can run multiple specialized agents within a single OpenClaw deployment, each with its own workspace files and session history.

# Agents

## Security Agent
- Channels: #security-alerts, #incident-response
- Soul: security-agent/SOUL.md
- Tools: network scanning, log analysis, threat intel

## Help Desk Agent
- Channels: #it-support, WhatsApp (support number)
- Soul: helpdesk-agent/SOUL.md
- Tools: ticketing system, knowledge base search

This multi-agent routing enables you to isolate different responsibilities. Your security monitoring agent does not have access to your personal scheduling tools, and your help desk agent does not have access to security scanning capabilities. Isolation reduces the blast radius if any single agent is compromised.

HEARTBEAT.md

HEARTBEAT.md is the scheduling brain of your agent. Write tasks in natural language, and the heartbeat daemon executes them on schedule. The 2026.4.11 release tightened the natural-language timing parser so off-by-one execution drift is no longer a routine issue, but you still need to be deliberate about how you phrase each task. Anchor every cadence to a specific clock time when possible because absolute times like “every Tuesday at 14:00” resolve more precisely than relative intervals like “every 168 hours.”

# Heartbeat Tasks

## Daily
- Every morning at 8:00 AM, check for new CVEs affecting our
  infrastructure stack and summarize findings in #security-alerts.
- Every weekday at 5:00 PM, compile a summary of today’s
  resolved and unresolved tickets.

## Weekly
- Every Monday at 9:00 AM, generate a security posture report
  for the past week.
- Every Friday at 3:00 PM, review and clean up expired
  temporary access grants.

## Periodic
- Every 2 hours during business hours, check uptime monitoring
  endpoints and alert on any degradation.

Heartbeat tasks compose well with other workspace files. A task that says “Every morning at 7 AM, review my calendar and message me a summary” will pull preferences from MEMORY.md (which calendars to include, which time zone to use), pull tools from TOOLS.md (calendar API access, messaging channel), and respect the behavioral rules in SOUL.md (tone, length, escalation criteria). The natural-language scheduling is both a strength and a risk. It is far more readable than cron syntax, but for critical scheduled tasks you should still verify execution timing in the first few cycles by tailing the Gateway logs and confirming that the scheduled task fires when you expect.

For more complex schedules, group tasks by frequency under Daily, Weekly, Monthly, and Periodic headings, and keep each bullet to a single sentence describing both the when and the what. Avoid nesting conditional logic inside heartbeat tasks; if a task needs branching behavior, route it through a skill so the conditional logic lives in code rather than in the natural-language scheduler. Operators running compliance evidence collection on heartbeat schedules should also pair each task with a corresponding entry in MEMORY.md that records when the task last ran successfully, so auditors can reconstruct the schedule from the workspace files alone.

MEMORY.md

MEMORY.md stores accumulated knowledge as the agent operates. It records user preferences, past decisions, project context, and any information the agent or user marks as worth remembering. Because it is stored as a local Markdown file, you can inspect, edit, or delete specific memories at any time. There is no opaque vector database to query. Your agent’s memory is a text file you can read in any editor.

Active Memory Plugin Deep Dive

The Active Memory plugin is one of the most useful and most security-sensitive additions in the 2026.4 line. It is an optional sub-agent that runs before the main reply and automatically pulls relevant context from MEMORY.md, USER.md, and recent transcripts so the user does not have to manually say “remember this” or “search memory.” In practical terms, the plugin scores stored notes against the current conversation, surfaces the highest-relevance items, and injects them into the system prompt before the main model generates a reply. The result is an agent that feels like it actually remembers you instead of one that needs to be told everything every session.

Internally, Active Memory does three things. First, it parses MEMORY.md into discrete blocks (each H2 or H3 heading is a block) and stores a lightweight index of the headings and the first 200 characters of each block. Second, on each inbound message, it scores each block against the message using a fast local relevance model. Third, it injects the top three to five blocks into the system prompt, capped at a configurable token budget so the plugin cannot blow up your context window on every turn. The plugin runs entirely inside the Gateway process; nothing about Active Memory leaves your machine other than the blocks it ultimately includes in the LLM API call, which travel with every other message in your conversation.

The security caveat is the reason we recommend treating Active Memory as a deliberate enablement decision. The plugin reads MEMORY.md on every turn, and any content in MEMORY.md is a candidate for injection into the system prompt. If an attacker can write to MEMORY.md, they can effectively rewrite your agent’s behavior by planting instructions disguised as “memories.” This is called memory poisoning, and it is the bug that v2026.4.15 patches in the relevance filter. After applying that patch, Active Memory still ingests every block but applies stricter signature checks before treating any block as authoritative instructions versus contextual information.

Our deployment recommendation is straightforward. On single-user agents running on your own laptop, enable Active Memory and let the plugin do its job. On multi-user agents or any agent that takes input from public channels (Discord servers, public Slack workspaces, support inboxes), either disable Active Memory entirely or enable file-integrity monitoring on MEMORY.md so any unauthorized write triggers an alert. For agents in regulated environments, pair Active Memory with a daily diff job that captures any change to MEMORY.md as a tracked audit event and routes the diff to your SIEM. The plugin is powerful enough to be worth the operational effort; just do not treat it as a passive feature.

Diagnostics with openclaw doctor

The openclaw doctor subcommand is the most useful diagnostic tool in the framework, and it should be your first stop whenever an agent misbehaves. Doctor runs an environment audit that catches the majority of installation, upgrade, and configuration problems before you escalate to a GitHub issue or a Discord question.

# Run the full diagnostic
openclaw doctor

# Run a specific check
openclaw doctor --check workspace
openclaw doctor --check provider
openclaw doctor --check skills

# Output as JSON for scripting
openclaw doctor --json > doctor-report.json

A complete doctor run checks the Node.js and npm versions against the supported matrix, validates that the Gateway bind host is reachable on the configured port, confirms that the workspace directory is readable and writable, parses SOUL.md and HEARTBEAT.md to surface syntax issues, tests outbound connectivity to your configured LLM provider, validates the metadata for every installed skill and flags any that fail signature checks, and reports the resolved values of all OPENCLAW_* environment variables including codex_provider, codex_model, and any provider-specific overrides.

The patterns that most commonly trip up new operators are environment variables that look right but resolve to empty strings, workspace files saved with the wrong line endings on Windows, skills installed into the global directory that conflict with workspace skills of the same name, and Gateway tokens that drift between the .env file and the docker-compose.yml. Doctor catches every one of these without any guessing.

For production deployments, we recommend running doctor as part of your CI/CD pipeline before each rollout and again immediately after the new container comes up. The JSON output makes it trivial to gate a deploy on a clean doctor result. We also recommend running doctor against the current install before any upgrade between minor versions because the report makes it obvious which CLI flags or configuration keys have been deprecated in the new release.

AgentSkills: Extending Your Agent

OpenClaw uses a skills system where each skill is a directory containing a SKILL.md file with metadata and instructions. Skills can be bundled with OpenClaw, installed globally, or stored in a workspace. Workspace skills take precedence over global skills, which take precedence over bundled skills.

The community has published over 160 production-ready agent templates through repositories like awesome-openclaw-agents, covering 19 categories. Categories include file management, web automation, shell command execution, smart home control, music and audio platforms, productivity tools, and more.

A basic skill directory structure looks like this:

my-skill/
  SKILL.md       # Metadata (YAML frontmatter) + instructions
  requirements/  # Optional dependencies
  examples/      # Usage examples

And the SKILL.md file contains:

---
name: security-scanner
description: Run network security scans and parse results
tools: [shell, file-read, file-write]
---

# Security Scanner Skill

When the user asks to scan a network or check security:
1. Confirm the target IP range or hostname
2. Run nmap with service detection: `nmap -sV -sC [target]`
3. Parse the output and highlight:
   - Open ports that should be closed
   - Services running outdated versions
   - Default credentials detected
4. Save the report to ~/reports/scan-[date].md

Critical security warning: A security audit of skills published to ClawHub (the community skill registry) revealed that roughly 12% of submitted skills contained malicious code. Skills can execute arbitrary shell commands, read and write files, access network services, control browsers, and schedule cron jobs. Treat third-party skills as untrusted code. Read every SKILL.md before enabling it. Prefer running untrusted skills inside Docker sandboxing, which is available but requires explicit configuration.

Shell Command Execution and Sandboxing

The built-in shell tool and many community skills can execute arbitrary shell commands on the host. This is what makes OpenClaw genuinely useful as an automation layer, and it is also the single biggest source of operational risk in the framework. By default, the shell tool runs as the user that started the Gateway, which is why we recommend never running OpenClaw as root and never running it under a service account that has write access to anything more than the workspace directory.

To sandbox shell execution effectively, deploy OpenClaw in Docker with a non-root user inside the container, drop all Linux capabilities with cap-drop ALL and add back only what specific skills require, mount sensitive host paths read-only or do not mount them at all, apply a seccomp profile that blocks kernel calls the agent does not need (the templates shipped in v2026.4.15 cover the common cases), and use network namespace isolation so the container cannot reach hosts outside the explicit allow list. For higher-assurance environments, run each agent in its own container and enable Landlock to enforce filesystem isolation at the kernel level even if the seccomp profile is bypassed.

Operators who need to retain a shell tool for legitimate automation but want to constrain what it can execute have two effective patterns. The first is a command allow list enforced by the skill wrapper rather than by the LLM; the wrapper validates the executable against an explicit list before passing the call to the kernel. The second is a hard timeout on every shell invocation paired with output capture, so even if a command escapes the allow list it cannot run unbounded and its output is always available for forensic review. We use both patterns in the regulated client environments where shell tooling cannot simply be disabled.

Security Considerations and Hardening

OpenClaw’s power comes from its ability to execute actions on your behalf, which means its security posture directly affects your infrastructure. The framework has faced significant security scrutiny since its rapid adoption, and the findings are worth understanding before deployment.

Known Security Challenges

Within the first 24 hours of widespread adoption, security researchers identified over 40,000 exposed OpenClaw instances accessible from the public internet. Later scans found over 135,000 publicly accessible instances, many running over unencrypted HTTP. Analysis showed that 63% of observed deployments had known vulnerabilities. The project has published 92 security advisories since launch.

These numbers reflect the tension between ease of installation and secure deployment. The one-line installer gets you running in minutes, but production hardening requires deliberate effort.

Hardening Recommendations

Bind to localhost only. The Gateway binds to 127.0.0.1:18789 by default. Never change this to 0.0.0.0 unless you have placed a reverse proxy with authentication in front of it. Exposing the Gateway to the internet without authentication gives anyone full control of your agent.

Run in Docker with sandboxing. Docker deployments should use non-root execution, dropped capabilities (cap-drop ALL), read-only filesystem mounts, and network namespace isolation. The official Docker image supports these configurations. For highly sensitive environments, Landlock and seccomp profiles provide additional kernel-level sandboxing.

Separate API keys by scope. Do not give your agent a single API key with broad permissions. Create scoped keys for each integration (email read-only, calendar read-only, file access limited to specific directories). This limits the damage from prompt injection attacks.

Monitor SOUL.md and MEMORY.md integrity. Memory poisoning attacks can permanently alter your agent’s behavior by injecting instructions into memory files. Use file integrity monitoring (AIDE, Tripwire, or inotify-based tools) to detect unauthorized changes to workspace files.

Keep the Gateway behind authentication. If you expose the web UI or API endpoints, use TLS 1.3 and require authentication. The Gateway supports token-based authentication which should be enabled for any deployment accessible from more than one machine.

Review skill code before installation. Never install skills from ClawHub or community repositories without reading the SKILL.md and any associated scripts. OpenClaw has a VirusTotal partnership for scanning skills, but automated scanning cannot catch every malicious payload, especially those that rely on prompt injection rather than executable code.

Use Cases: Cybersecurity, Compliance, and AI Development

Security Operations

OpenClaw’s heartbeat system makes it well-suited for continuous security monitoring. You can configure it to check CVE databases on a schedule, parse vulnerability scan results, correlate findings against your asset inventory, and surface critical issues through your team’s messaging channels. The agent can watch for new security advisories related to your technology stack and provide plain-language summaries of technical bulletins.

For incident response, an OpenClaw agent can serve as a real-time coordination tool. Team members communicate through the same Slack or Discord channels the agent monitors, and the agent can pull up relevant runbooks, previous incident notes, and system documentation on request.

Compliance Monitoring

Compliance frameworks like CMMC, HIPAA, and SOC 2 require continuous monitoring and periodic evidence collection. An OpenClaw agent can be configured to check compliance-relevant system states on a schedule: verify that backups ran successfully, confirm that access reviews are up to date, check that security patches are applied within required timeframes, and compile evidence artifacts for auditors.

However, it is critical to note that OpenClaw itself holds no SOC 2, HIPAA, GDPR, ISO 27001, or FedRAMP certifications. The self-hosted architecture means the agent inherits your infrastructure’s compliance posture. For healthcare environments handling PHI, you must either use a HIPAA-eligible AI provider with a signed BAA, deploy self-hosted models like Llama for complete data isolation, or implement PHI detection and redaction before any data reaches the LLM API.

AI Development Workflows

For teams building AI applications, OpenClaw can automate development workflow tasks: monitoring training job progress, summarizing experiment results, managing model versioning, and coordinating between team members working on different components. The AI development infrastructure we build for clients often includes agent-based monitoring and alerting that tools like OpenClaw can provide.

Developers working with dedicated AI development systems benefit from having an always-on agent that can check on long-running training jobs, alert when resources are underutilized, and provide quick answers about framework-specific configurations without leaving the terminal.

OpenClaw vs Other AI Agent Frameworks

The AI agent landscape in 2026 includes several mature frameworks, each serving different audiences and use cases. Here is how OpenClaw compares to the most commonly evaluated alternatives.

Choose OpenClaw if you want a self-hosted personal assistant that works through your existing messaging apps, requires minimal code, and can act proactively on a schedule. It is the strongest choice for non-developers who want AI automation without building a custom application.

Choose CrewAI if you need multiple specialized agents collaborating on complex workflows like research pipelines, content production, or data analysis chains. Its native crew abstraction makes multi-agent coordination cleaner than any alternative.

Choose LangChain if you need maximum flexibility and are building a custom AI application where you control every aspect of the agent loop, tool integration, and memory management. It is a toolkit, not a product, and requires the most development effort.

Choose AutoGPT if you want to experiment with fully autonomous agent behavior. It pioneered the autonomous agent concept but has fallen behind in active development and production readiness compared to the alternatives.

For a deeper head-to-head analysis of OpenClaw against Hermes Agent specifically, including architecture diagrams and production deployment trade-offs, see our OpenClaw vs Hermes Agent comparison guide. If you are evaluating Hermes Agent on its own merits, our Hermes Agent framework guide covers its self-improving learning loop in depth.

Getting Started Tutorial

This tutorial walks you through installing OpenClaw, configuring a basic agent, connecting it to a messaging channel, and setting up a scheduled task. We assume a Linux or macOS system with Node.js 18+ installed.

Step 1: Install OpenClaw

# Install globally via npm
npm install -g openclaw

# Verify the installation
openclaw --version
# Expected output: openclaw v2026.4.15

Step 2: Run Onboarding

# Start OpenClaw for the first time
openclaw start

# The onboarding wizard will prompt you for:
# 1. Your preferred LLM provider (Anthropic, OpenAI, Google, etc.)
# 2. Your API key for that provider
# 3. A name for your agent
# 4. Basic personality preferences

After onboarding completes, OpenClaw creates the workspace directory at ~/.openclaw/workspace/ with default SOUL.md, AGENTS.md, HEARTBEAT.md, and MEMORY.md files. Run openclaw doctor immediately after onboarding to confirm everything resolved correctly.

Step 3: Customize SOUL.md

Open the generated SOUL.md file and customize it for your use case:

# Open in your preferred editor
nano ~/.openclaw/workspace/SOUL.md

Replace the default content with instructions specific to your role. If you work in IT, you might include rules about security-first recommendations, compliance awareness, and preferred tools. If you work in content production, you might include style guidelines, brand voice rules, and editorial standards.

Step 4: Connect a Messaging Channel

Connect your preferred messaging platform. For example, to connect Telegram:

# OpenClaw CLI
openclaw connect telegram

# Follow the prompts to:
# 1. Create a Telegram bot via @BotFather
# 2. Enter the bot token
# 3. Send a test message to verify the connection

Once connected, you can message your agent directly through Telegram. The agent responds with the personality and rules defined in your SOUL.md.

Step 5: Add a Scheduled Task

Edit HEARTBEAT.md to add your first proactive task:

# Open HEARTBEAT.md
nano ~/.openclaw/workspace/HEARTBEAT.md

# Add a simple task:
## Daily
- Every morning at 8:30 AM, check the weather forecast
  for Raleigh, NC and send a summary to me on Telegram.

The heartbeat daemon will pick up this task on its next cycle and begin executing it on schedule. Monitor the OpenClaw logs to verify timing:

# View Gateway logs
openclaw logs --follow

Step 6: Install a Skill

Extend your agent with a skill from the community or create your own:

# Create a custom skill directory
mkdir -p ~/.openclaw/workspace/skills/system-health

# Create the SKILL.md
cat > ~/.openclaw/workspace/skills/system-health/SKILL.md << 'EOF'
---
name: system-health
description: Check system health metrics
tools: [shell]
---

# System Health Check

When asked about system health or server status:
1. Run `uptime` to check system uptime and load
2. Run `df -h` to check disk usage
3. Run `free -h` to check memory usage
4. Summarize findings in a clear, concise format
5. Flag any metrics that exceed safe thresholds:
   - Disk usage above 80%
   - Memory usage above 90%
   - Load average above CPU count
EOF

Restart the Gateway to load the new skill, and your agent will use it whenever you ask about system health.

Enterprise Deployment Patterns

For organizations deploying OpenClaw beyond personal use, several architectural patterns improve security, reliability, and compliance posture.

Reverse proxy with SSO. Place the Gateway behind Nginx or Caddy with your organization’s SSO provider (Okta, Azure AD, Keycloak). This adds authentication, rate limiting, and audit logging at the network layer before traffic reaches the Gateway.

Separate agents per team. Run isolated OpenClaw instances for different teams (security, engineering, support), each in its own Docker container with its own workspace files, API keys, and skill sets. This provides workload isolation and limits the blast radius of any compromise.

Centralized logging. Forward Gateway logs to your SIEM (Splunk, Elastic, Grafana Loki) for monitoring, alerting, and compliance evidence. All agent interactions, tool executions, and errors should be captured in your centralized logging pipeline.

GitOps for workspace files. Store all workspace files (SOUL.md, AGENTS.md, HEARTBEAT.md, skills) in a Git repository with branch protection and required reviews. Deploy workspace changes through CI/CD pipelines that validate configurations before applying them to production agents. This prevents unauthorized modifications and provides a complete audit trail.

Network segmentation. Place the OpenClaw container in a network segment with access only to the specific services it needs. If the agent only needs to reach the LLM API, Slack, and your internal monitoring endpoints, block all other outbound traffic. This limits the damage from prompt injection attacks that attempt to access unauthorized resources.

How Petronella Technology Group Uses AI Agents

At Petronella Technology Group, we build AI automation infrastructure for businesses that need to move faster without compromising security or compliance. Our AI services practice includes deploying, securing, and managing agent frameworks for clients across regulated industries.

Our approach to AI agent deployment follows the same principles we apply to all client infrastructure: defense in depth, least privilege, and continuous monitoring. When we deploy agent frameworks for clients, we start with a threat model specific to their environment, select the right framework for their use case (not every client needs OpenClaw), and harden the deployment against the attack vectors we have seen in production.

For clients building AI applications, our AI development systems provide the compute foundation, and agent frameworks like OpenClaw provide the automation layer. We have seen clients reduce manual monitoring effort by 60-70% after deploying properly configured agents for routine security checks, compliance evidence collection, and infrastructure health monitoring.

If you are evaluating AI agent frameworks for your organization, our team has hands-on experience with the security and operational trade-offs of each major platform. We combine CMMC-RP, CCNA, CWNE, and DFE certifications with practical AI deployment experience to help clients adopt these tools safely. For a deeper look at how we use AI development tools in our own workflow, see our Claude Code CLI guide. For strategic guidance on building an AI-powered operation, our AI consulting services in Raleigh, NC cover everything from framework selection to production deployment and ongoing security monitoring.

To speak with our team directly, call us at (919) 348-4912 or visit our contact page to schedule a free consultation.

Frequently Asked Questions

Is OpenClaw free to use?

Yes. OpenClaw is released under the MIT license with no commercial restrictions. The software itself is completely free. However, you still need to pay for LLM API access from whichever provider you choose (Anthropic, OpenAI, Google, etc.), unless you run local models through Ollama or a similar tool. Running local models eliminates all recurring costs but requires capable hardware.

Is OpenClaw safe for handling sensitive business data?

It depends entirely on your deployment configuration. The self-hosted architecture means data stays on your infrastructure, which is a strong foundation. However, the default installation does not enable sandboxing, the skill system can execute arbitrary shell commands, and the community skill registry has had documented cases of malicious submissions. For sensitive environments, run OpenClaw in Docker with strict sandboxing, use local models to keep data off third-party APIs, restrict skill installations to reviewed and approved packages, and monitor workspace files for unauthorized changes.

Can OpenClaw replace a help desk or support team?

OpenClaw can handle routine, well-defined support tasks: answering common questions from a knowledge base, routing tickets, collecting initial information, and escalating complex issues to humans. It cannot replace the judgment, empathy, and creative problem-solving that human support teams provide. We recommend using it to augment your team by handling repetitive queries, not as a full replacement.

How does OpenClaw handle multiple users or team access?

Multi-agent routing through AGENTS.md allows you to configure separate agents for different channels, teams, or individuals. Each agent gets its own workspace with isolated memory and configuration. For team deployments, combine this with your organization’s SSO provider at the reverse proxy layer to control who can access which agent.

What happens to my data when I use a cloud LLM provider?

When your agent sends a message to a cloud LLM provider, the conversation content (including SOUL.md instructions and any context from memory) is transmitted to that provider’s API. Each provider has its own data retention and usage policies. Anthropic, OpenAI, and Google all offer API terms that exclude customer data from training, but you should verify the current terms for your provider. For complete data isolation, run local models through Ollama. Your local memory files (MEMORY.md, SOUL.md, transcripts) always stay on your machine regardless of which LLM provider you use.

How does OpenClaw compare to Claude Code or Cursor for development work?

These tools serve different purposes. Claude Code and Cursor are development-focused tools designed for writing and editing code within a project context. OpenClaw is a general-purpose personal assistant that can be configured for development tasks but excels at cross-platform communication, scheduling, and operational automation. Many developers use both: Claude Code for active development sessions and OpenClaw for background monitoring, notifications, and routine tasks.

What happened to Peter Steinberger and who maintains OpenClaw now?

In February 2026, Steinberger announced he was joining OpenAI and that a non-profit foundation would be established to provide future stewardship of the OpenClaw project. The project continues under active community development with regular releases (the latest stable release as of May 2026 is v2026.4.15). The transition to foundation governance is still underway.

What is the latest OpenClaw 2026 release and what changed?

As of May 2026, the latest stable release in the public registry is v2026.4.15, published on April 15, 2026. It closes seven security advisories from the post-launch review, hardens the Gateway WebSocket handshake, ships Landlock and seccomp profile templates inside the Docker image, fixes a memory-poisoning bug in the Active Memory plugin, and tightens the default skill-installation flow so unsigned skills require an explicit acknowledgement flag. The 2026.4.x branch is the recommended track for production. v2026.4.11, v2026.4.12, and v2026.4.14 are still receiving backports for organizations on slower upgrade cadences. Major releases land on roughly a six-week cycle under the foundation steward model.

How does the openclaw doctor command help with installation problems?

The openclaw doctor subcommand runs an environment diagnostic that checks Node.js and npm versions, validates that the Gateway bind host is reachable on the configured port, confirms that the workspace directory is readable and writable, parses SOUL.md and HEARTBEAT.md to surface syntax issues, tests outbound connectivity to your configured LLM provider, and reports any skills that fail metadata validation. Run it before opening a GitHub issue or asking on Discord because most setup problems map directly to a doctor finding. It is also the recommended first step after upgrading between major versions.

How does the codex_provider environment variable work?

The codex_provider environment variable lets you route code-related agent actions to a different LLM than the default conversational provider. For example, you can set codex_provider=anthropic-claude-opus while leaving the default provider on a cheaper model for general chat, so the agent escalates to a stronger reasoning model only for code analysis, refactoring, or shell-command authoring. The variable accepts any provider identifier recognized by the Gateway and can be combined with codex_model to pin a specific model version. This split-provider pattern keeps token costs predictable while preserving reasoning quality where it matters.

How does the Active Memory plugin work and is it safe to enable?

The Active Memory plugin is an optional sub-agent that runs before the main reply and automatically pulls relevant context from MEMORY.md, USER.md, and recent transcripts so you do not have to manually ask the agent to remember things. It scores stored notes against the current conversation, surfaces the highest-relevance items, and injects them into the system prompt. It is safe to enable in single-user deployments after applying the v2026.4.15 memory-poisoning patch. In multi-user or untrusted-channel deployments, enable file-integrity monitoring on MEMORY.md, restrict who can write to the memory file, and disable Active Memory on agents that take input from public channels until your team has reviewed the plugin source.

Can OpenClaw execute shell commands and how do I sandbox that?

Yes. The built-in shell tool and many community skills can execute arbitrary shell commands on the host. By default this runs as the user that started the Gateway, which is why we recommend never running OpenClaw as root. To sandbox shell execution, deploy OpenClaw in Docker with a non-root user, drop all Linux capabilities with cap-drop ALL, mount sensitive host paths read-only, apply a seccomp profile to block kernel calls the agent does not need, and use network namespace isolation so the container cannot reach hosts outside its allowed list. For higher-assurance environments, run each agent in its own container and use Landlock to enforce filesystem isolation at the kernel level.

How do I write heartbeat tasks for periodic agent jobs?

HEARTBEAT.md uses natural-language scheduling. Write each task as a bullet under a heading like Daily, Weekly, or Periodic and describe both the cadence and the action in plain English. Examples that work reliably include “Every morning at 8 AM, summarize my unread email,” “Every Monday at 9 AM, generate a security posture report,” and “Every 2 hours during business hours, check uptime endpoints.” For critical schedules, verify timing through openclaw logs --follow for the first few cycles. If the agent drifts on timing, anchor the cadence to a specific clock time rather than an interval (every Tuesday at 14:00 is more precise than every 168 hours).

Getting Help and Next Steps

OpenClaw’s documentation lives at docs.openclaw.ai, and the GitHub repository at github.com/openclaw/openclaw is the primary source for issues, discussions, and contributions. The community is active on Discord, where you can find help with configuration, skill development, and deployment questions.

If your organization needs help evaluating, deploying, or securing AI agent frameworks for regulated environments, Petronella Technology Group can help. Our team combines deep cybersecurity expertise with practical AI deployment experience to build automation that works within your compliance requirements. Contact us for a free consultation, or explore our AI services to see how we help businesses adopt AI safely.

About the Author: Craig Petronella is the CEO of Petronella Technology Group, a cybersecurity and IT infrastructure firm in Raleigh, NC. With CMMC-RP, CCNA, CWNE, and DFE certifications and over 30 years in IT, Craig’s team evaluates and deploys AI agent frameworks for clients in healthcare, defense, and financial services.

Related Reading

For existing users tracking new releases, breaking changes, and migration guidance this year, see our OpenClaw 2026 release tracker.

From Tutorial to Production: What Changes

The build steps in this tutorial get you to a working OpenClaw agent on a developer laptop. Moving the same agent into a production environment that handles regulated data requires a different posture. The four gaps that consistently surface during our client engagements:

• Inference endpoint. A local model on a developer machine is fine for iteration. Production needs a dedicated GPU node with health monitoring, capacity headroom for peak prompt rates, and a deterministic model-version pin for the lifetime of any audit window.
• Audit logging. The tutorial agent writes logs to disk. Production needs structured audit records shipped to a SIEM with tamper-evident retention - NIST 800-171 3.3.1 and 3.3.8 if you are in CMMC scope, 164.312(b) if you are HIPAA.
• Retrieval pipeline. A single vector store works for a tutorial. Regulated workloads need segmented indexes per data classification so a public-class query cannot accidentally surface CUI or PHI through retrieval-augmented generation.
• Tool authorization. The tutorial uses unscoped tool calls. Production needs per-tool authorization tied to identity, with a default-deny posture and explicit approve rules.

The Hardening Sequence We Use

When we take a working OpenClaw tutorial-grade build through to a production deployment for a regulated client, the sequence is repeatable. Step one is environment provisioning on dedicated GPU nodes with the runtime version pinned for the engagement. Step two is the audit-pipeline retrofit: structured logs out of the OpenClaw runtime, into a SIEM, with retention configured for the assessment window. Step three is retrieval segmentation: separate vector indexes per data classification, with the agent loop wired to select the right index based on the request context. Step four is tool authorization: every tool wrapped in an authorization check tied to the calling identity, default-deny, explicit approve rules per data class. Step five is the tabletop validation: walk an assessor through a sample run against documented evidence, fix the gaps before the real assessment.

Most of the hardening is mechanical once the pattern is established. The decision that takes the most calendar time is upstream of the build: which audit framework applies, what evidence the assessor expects, and how the agent fits the existing system security plan. That is the conversation worth having before you write the first line of OpenClaw configuration.

Companion Reading