How to Make OpenClaw Truly Autonomous
Most OpenClaw setups are not autonomous. They are interactive. You type a message, the agent responds, and nothing happens until you type again. That is a chatbot, not an autonomous agent. This guide covers every layer required to make your OpenClaw agents genuinely self-running: SOUL.md decision logic, HEARTBEAT.md scheduling, daemon mode, multi-agent orchestration, monitoring, and the common pitfalls that break autonomy in production.
Why Most OpenClaw Setups Feel Like Chatbots
OpenClaw out of the box is designed for interactive use. You install it, create a SOUL.md, start the gateway, and send messages. The agent responds. This works, but it is fundamentally reactive. The agent does nothing unless prompted.
A truly autonomous agent is different. It wakes up on a schedule, decides what to do based on rules you defined, executes tasks, handles errors, logs results, and goes back to sleep. You check in when you want, not because you have to. The difference between the two setups comes down to five layers that most users skip.
No scheduling layer
Without HEARTBEAT.md or a cron trigger, the agent sits idle forever. It cannot initiate tasks on its own. You are the scheduler.
No decision logic in SOUL.md
A SOUL.md that says 'You are a helpful assistant' gives the agent no rules for autonomous behavior. It needs explicit instructions for what to do when triggered without a human message.
No process management
Running the gateway in a terminal window means it dies when you close the terminal, when your Mac sleeps, or when the SSH session disconnects. No daemon, no autonomy.
No error handling
If an API call fails or a task produces unexpected results, the agent either crashes or enters an infinite retry loop. Without exit conditions and fallback rules, autonomy breaks on the first error.
No monitoring
An agent that runs silently with no health checks, no logging, and no alerts is not autonomous. It is abandoned. You have no way to know if it is working or stuck.
The rest of this guide addresses each layer, with configuration files you can copy and adapt to your setup.
SOUL.md Configuration for Autonomous Behavior
The SOUL.md file defines your agent's personality, rules, and capabilities. For autonomous operation, it needs something most SOUL.md files lack: decision-making rules for when there is no human in the loop.
An interactive SOUL.md says "respond helpfully to the user." An autonomous SOUL.md says "when triggered by heartbeat, check these data sources, apply these rules, produce this output, and stop." The difference is specificity.
# Radar - SEO Analyst Agent
## Identity
You are Radar, an autonomous SEO analyst agent.
You monitor search performance, identify keyword opportunities,
and generate weekly reports without human prompting.
## Autonomous Behavior Rules
When triggered by heartbeat (no human message):
1. Pull the latest GSC data for the past 7 days
2. Compare against the previous 7-day period
3. Identify keywords with rising impressions but low CTR
4. Flag any pages that dropped more than 20% in clicks
5. Generate a structured report with recommendations
6. Send the report to Telegram
7. Stop. Do not continue unless explicitly messaged.
## Decision Rules
- If GSC API returns an error, retry once after 30 seconds.
If it fails again, send an error alert and stop.
- If no significant changes are detected, send a short
"all stable" message instead of a full report.
- Never generate content or modify files during heartbeat runs.
Heartbeat is for analysis and reporting only.
## Exit Conditions
- Maximum 3 API calls per heartbeat cycle
- Maximum 2 minutes of execution time
- If context exceeds 4000 tokens, summarize and stop
## Output Format
Reports use this structure:
- Period: [date range]
- Top movers (up): [keyword, clicks delta, impressions delta]
- Top decliners: [keyword, clicks delta, impressions delta]
- Action items: [numbered list of recommendations]Notice the explicit exit conditions and decision rules. These are what prevent an autonomous agent from going off the rails. Without them, a heartbeat-triggered agent might loop indefinitely, burn API credits, or produce garbage output because it had no stopping criteria.
## Autonomous Behavior Rules
# What to do when no human is present
# Specific, numbered steps — not vague guidance
## Decision Rules
# If-then logic for handling edge cases
# Error handling, retry limits, fallback behavior
## Exit Conditions
# When to stop — token limits, time limits, API call caps
# Prevents runaway sessions and cost spikes
## Output Format
# Where results go — Telegram, file, API endpoint
# Structured format so downstream processes can parse itRule of thumb: If you cannot describe what your agent should do during a heartbeat run in 10 numbered steps or fewer, the task is too complex for a single autonomous agent. Split it across multiple agents with clear handoff points.
HEARTBEAT.md and Scheduling Setup
HEARTBEAT.md is OpenClaw's native scheduling file. It tells the gateway to trigger the agent at regular intervals, with an optional initial message and exit conditions. Without it, the agent only responds to explicit messages.
# Heartbeat Configuration
## Schedule
interval: 6h
## Trigger Message
Run your scheduled SEO analysis for the current period.
## Exit Conditions
- Stop after generating and sending the report
- Stop if any API call fails twice consecutively
- Maximum execution time: 3 minutes
- Clear session after each runThe interval field supports several formats: 5m (minutes), 6h (hours), 1d (daily). The trigger message is sent to the agent as if a user typed it, which means the agent processes it using its SOUL.md rules.
The critical line is clear session after each run. Without session clearing, each heartbeat cycle appends to the previous session. After a few days, the context window fills up, the agent slows down, responses degrade, and API costs spike. Session clearing gives the agent a fresh start every cycle.
Alternative: Cron + CLI Trigger
If you prefer OS-level scheduling (more reliable, works even if the gateway restarts), use cron to invoke the agent via CLI.
# Open crontab
crontab -e
# Run Radar every 6 hours at minute 0
0 */6 * * * /opt/homebrew/bin/openclaw agent --agent radar --message "Run your scheduled SEO analysis."
# Run Echo (content writer) daily at 9 AM
0 9 * * * /opt/homebrew/bin/openclaw agent --agent echo --message "Write today's scheduled article."
# Run Orion (PM) every 30 minutes for task coordination
*/30 * * * * /opt/homebrew/bin/openclaw agent --agent orion --message "Check for pending tasks and delegate."
# Verify your cron jobs
crontab -lImportant: Cron jobs require the full path to the openclaw binary because cron does not load your shell profile. Use which openclaw to find the correct path on your machine.
Gateway Daemon Mode
The gateway is the process that connects your agents to the outside world. If it stops, everything stops. Running it in a terminal window is fine for testing, but for autonomous operation, you need it running as a daemon: a background process that starts on boot, restarts on crash, and survives terminal closures, sleep cycles, and SSH disconnects.
macOS: launchd (Recommended)
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>ai.openclaw.gateway</string>
<key>ProgramArguments</key>
<array>
<string>/usr/bin/caffeinate</string>
<string>-s</string>
<string>/opt/homebrew/bin/openclaw</string>
<string>gateway</string>
<string>start</string>
</array>
<key>WorkingDirectory</key>
<string>/Users/yourusername/openclaw-workspace</string>
<key>EnvironmentVariables</key>
<dict>
<key>ANTHROPIC_API_KEY</key>
<string>sk-ant-your-key</string>
<key>PATH</key>
<string>/opt/homebrew/bin:/usr/local/bin:/usr/bin:/bin</string>
<key>HOME</key>
<string>/Users/yourusername</string>
</dict>
<key>RunAtLoad</key>
<true/>
<key>KeepAlive</key>
<true/>
<key>ThrottleInterval</key>
<integer>10</integer>
<key>StandardOutPath</key>
<string>/tmp/openclaw-gateway.log</string>
<key>StandardErrorPath</key>
<string>/tmp/openclaw-gateway-error.log</string>
</dict>
</plist># Load the service (starts immediately, persists across reboots)
launchctl load ~/Library/LaunchAgents/ai.openclaw.gateway.plist
# Verify it is running
launchctl list | grep openclaw
# Watch logs
tail -f /tmp/openclaw-gateway.log
# Restart the gateway
launchctl unload ~/Library/LaunchAgents/ai.openclaw.gateway.plist
launchctl load ~/Library/LaunchAgents/ai.openclaw.gateway.plistLinux: systemd
[Unit]
Description=OpenClaw Gateway
After=network.target
[Service]
Type=simple
User=yourusername
WorkingDirectory=/home/yourusername/openclaw-workspace
ExecStart=/usr/local/bin/openclaw gateway start
Restart=always
RestartSec=10
Environment=ANTHROPIC_API_KEY=sk-ant-your-key
Environment=NODE_ENV=production
[Install]
WantedBy=multi-user.targetsudo systemctl daemon-reload
sudo systemctl enable openclaw-gateway
sudo systemctl start openclaw-gateway
sudo systemctl status openclaw-gateway
# View logs
journalctl -u openclaw-gateway -fQuick Option: pm2
For a cross-platform solution that works on macOS, Linux, and Windows, pm2 is the fastest path to a managed daemon.
# Install pm2 globally
npm install -g pm2
# Start the gateway as a managed process
pm2 start "openclaw gateway start" --name openclaw-gateway
# Save the process list so it survives reboots
pm2 save
pm2 startup
# Monitor in real time
pm2 monit
# View logs
pm2 logs openclaw-gatewayMulti-Agent Orchestration Patterns
A single autonomous agent is useful. Multiple agents that coordinate with each other are powerful. OpenClaw supports multi-agent setups through the agents.md file and @mention-based delegation. Here are three orchestration patterns that work in production.
Pattern 1: Coordinator with Specialists
One agent (typically a project manager) receives all incoming tasks and delegates to specialist agents. The coordinator decides who handles what based on task type.
# Agent Team
## Orion (Coordinator)
Role: Project manager. Receives all tasks. Delegates to specialists.
Trigger: Every 30 minutes via heartbeat
Skills: Task routing, status tracking, priority assessment
Delegates to: @echo for content, @radar for SEO, @metrics for analytics
## Echo (Content Writer)
Role: Writes blog posts, social content, email copy.
Trigger: On delegation from @orion only
Skills: Writing, editing, keyword integration
## Radar (SEO Analyst)
Role: Monitors search performance, identifies keyword opportunities.
Trigger: Every 6 hours via heartbeat + on delegation from @orion
Skills: GSC analysis, keyword research, competitor tracking
## Metrics (Analytics)
Role: Pulls traffic and conversion data, generates reports.
Trigger: Daily at 8 AM via cron
Skills: GA4 queries, Mixpanel exports, trend analysisPattern 2: Pipeline (Sequential)
Agents work in sequence. Agent A produces output, which becomes input for Agent B. Good for content pipelines where research, writing, and optimization happen in order.
## Pipeline Rules (Radar SOUL.md)
After completing keyword research:
1. Save results to /tmp/keyword-report.json
2. Delegate to @echo with message:
"New keyword report ready at /tmp/keyword-report.json.
Write articles targeting the top 3 opportunities."
3. Stop and clear session.
## Pipeline Rules (Echo SOUL.md)
When receiving a delegation from @radar:
1. Read the keyword report file
2. Write one article per keyword opportunity
3. Save articles to /content/drafts/
4. Delegate to @orion with message:
"3 draft articles ready for review in /content/drafts/"
5. Stop and clear session.Pattern 3: Independent Parallel Agents
Each agent runs on its own schedule, performs its own tasks, and reports results independently. No coordination, no delegation. This is the simplest pattern and works well when agents have non-overlapping responsibilities.
# Radar: SEO check every 6 hours
0 */6 * * * /opt/homebrew/bin/openclaw agent --agent radar --message "Run scheduled analysis"
# Echo: Write daily article at 9 AM
0 9 * * * /opt/homebrew/bin/openclaw agent --agent echo --message "Write today's article"
# Metrics: Daily report at 8 AM
0 8 * * * /opt/homebrew/bin/openclaw agent --agent metrics --message "Generate daily report"
# Social: Post schedule check at 10 AM and 3 PM
0 10,15 * * * /opt/homebrew/bin/openclaw agent --agent social --message "Check and post scheduled content"Which pattern to choose: Start with Pattern 3 (independent agents). Move to Pattern 1 (coordinator) when you have more than 3 agents and task routing becomes manual. Use Pattern 2 (pipeline) only for workflows where output from one agent is required input for the next.
Monitoring and Logging
An autonomous agent without monitoring is a liability. You need three types of visibility: is the gateway process alive, did the agent complete its task, and was the output correct.
Gateway Health Check
#!/bin/bash
GATEWAY="http://localhost:18789/health"
TELEGRAM_TOKEN="your-bot-token"
CHAT_ID="your-chat-id"
STATUS=$(curl -s -o /dev/null -w "%{http_code}" --max-time 10 "$GATEWAY")
if [ "$STATUS" != "200" ]; then
curl -s -X POST "https://api.telegram.org/bot$TELEGRAM_TOKEN/sendMessage" \
-d "chat_id=$CHAT_ID" \
-d "text=OpenClaw gateway DOWN (HTTP $STATUS). Restarting..." > /dev/null
launchctl unload ~/Library/LaunchAgents/ai.openclaw.gateway.plist
sleep 3
launchctl load ~/Library/LaunchAgents/ai.openclaw.gateway.plist
fichmod +x ~/openclaw-workspace/healthcheck.sh
crontab -e
# Add this line:
*/5 * * * * /Users/yourusername/openclaw-workspace/healthcheck.shAgent Activity Logging
Add a logging section to your SOUL.md so the agent writes a structured log entry after every heartbeat cycle.
## Logging Rules
After every heartbeat cycle, append a log entry to
/var/log/openclaw/radar.log with this format:
[TIMESTAMP] [AGENT] [STATUS] [SUMMARY]
Example:
[2026-03-02T08:00:12Z] [radar] [OK] SEO report sent. 3 rising keywords, 0 decliners.
[2026-03-02T14:00:08Z] [radar] [ERROR] GSC API timeout. Retried once. Failed. Alert sent.
[2026-03-02T20:00:15Z] [radar] [SKIP] No significant changes. Short summary sent.Daily Summary via Telegram
#!/bin/bash
TELEGRAM_TOKEN="your-bot-token"
CHAT_ID="your-chat-id"
LOG_DIR="/var/log/openclaw"
TODAY=$(date +%Y-%m-%d)
# Count activity per agent
SUMMARY=""
for log in "$LOG_DIR"/*.log; do
AGENT=$(basename "$log" .log)
OK=$(grep -c "\[$TODAY\].*\[OK\]" "$log" 2>/dev/null || echo 0)
ERR=$(grep -c "\[$TODAY\].*\[ERROR\]" "$log" 2>/dev/null || echo 0)
SKIP=$(grep -c "\[$TODAY\].*\[SKIP\]" "$log" 2>/dev/null || echo 0)
SUMMARY="$SUMMARY\n$AGENT: $OK ok, $ERR errors, $SKIP skipped"
done
curl -s -X POST "https://api.telegram.org/bot$TELEGRAM_TOKEN/sendMessage" \
-d "chat_id=$CHAT_ID" \
-d "text=Daily Agent Summary ($TODAY):$SUMMARY" > /dev/nullCommon Pitfalls and How to Fix Them
These are the issues that break autonomy in practice. Most of them are not OpenClaw bugs. They are configuration gaps that only surface after the agent has been running unattended for a few days.
Context window overflow
The agent accumulates session history across heartbeat cycles until the context window fills up. Responses degrade, API costs spike, and eventually the agent errors out. Fix: add 'clear session after each run' to your HEARTBEAT.md. Each cycle starts fresh.
Runaway API costs
An agent without exit conditions can loop indefinitely, making hundreds of API calls in a single cycle. A stuck retry loop on a failed API call is the most common cause. Fix: set max_turns, max_tokens, or max execution time in SOUL.md. Add retry limits (retry once, then stop and alert).
Silent failures
The agent encounters an error, stops running, and nobody notices for days. The gateway process is alive but the agent is doing nothing. Fix: add the health check and daily summary scripts from the monitoring section. Check for both process health AND output production.
Stale data in agent memory
An agent that does not clear its session carries old data into new cycles. It might reference a keyword report from 3 days ago or repeat recommendations it already made. Fix: session clearing between cycles. If the agent needs persistent memory, use a file or database instead of session context.
Timezone mismatches in cron
Your cron jobs run at system time, but your reports reference UTC or a different timezone. The agent sends a 'daily report' at 2 AM your time or generates a report for the wrong date. Fix: set the TZ environment variable in your crontab header or use UTC consistently across all agent configurations.
Gateway restarts clearing heartbeat state
If the gateway restarts (crash, reboot, manual restart), the heartbeat timer resets. The agent might miss a scheduled run or run twice in quick succession. Fix: use cron as the primary scheduler instead of HEARTBEAT.md for critical tasks. Cron is managed by the OS and is independent of gateway state.
Putting It All Together: The Autonomous Checklist
Here is the complete checklist for making an OpenClaw agent truly autonomous. If you skip any of these layers, autonomy will break at some point.
1. SOUL.md with autonomous behavior rules — Explicit instructions for what to do when triggered without a human message. Decision rules, exit conditions, output format.
2. HEARTBEAT.md or cron schedule — A trigger mechanism that initiates agent work on a regular cadence. Session clearing between cycles.
3. Gateway running as a daemon — launchd (macOS), systemd (Linux), or pm2 (cross-platform). Auto-restart on crash. Survives reboots.
4. Sleep prevention (macOS) — caffeinate, pmset, or Energy Saver settings to prevent system sleep while allowing display sleep.
5. Health monitoring — A script that checks gateway status every 5 minutes and alerts you via Telegram when something is down.
6. Activity logging — Structured log entries after every heartbeat cycle. Daily summary sent to your phone.
7. Error handling — Retry limits, fallback behavior, and explicit stop conditions in SOUL.md. No infinite loops.
8. Cost controls — Max turns, max tokens, and API call caps per cycle. Monitor your provider dashboard weekly.
Once all eight layers are in place, your agents run themselves. You check the daily summary on your phone, review output quality periodically, and adjust SOUL.md rules when the task requirements change. That is what autonomous actually means.
Skip the Manual Setup
CrewClaw generates your SOUL.md, HEARTBEAT.md, agents.md, and deployment config. Define your agent in the playground, download the package, and deploy in minutes.
Related Guides
Frequently Asked Questions
What does it mean for an OpenClaw agent to be truly autonomous?
A truly autonomous OpenClaw agent runs without human intervention. It wakes on a schedule (via HEARTBEAT.md or cron), performs its tasks, handles errors gracefully, logs its actions, and goes back to sleep. You do not need to open a terminal, type a command, or check on it. It reports to you only when something goes wrong or when it has results to share. The key ingredients are a well-written SOUL.md with clear decision rules, a HEARTBEAT.md with a schedule and exit conditions, a daemon-managed gateway, and a monitoring layer.
Can I run multiple autonomous agents on the same machine?
Yes. OpenClaw supports multiple agents on one gateway. Each agent has its own SOUL.md, HEARTBEAT.md, and session. They share the gateway process, API keys, and system resources. Use agents.md to define the team and configure which agent handles which type of task. The gateway routes incoming messages and scheduled tasks to the correct agent automatically. A single Mac Mini or VPS can comfortably run 5-10 agents depending on task complexity and API rate limits.
How often should HEARTBEAT.md trigger tasks?
It depends on the task. For monitoring and reporting agents, every 15-30 minutes is common. For content creation or SEO agents that publish articles, once or twice a day is enough. For agents that watch external APIs or inboxes, every 5 minutes works but you should add exit conditions to avoid burning API credits when there is nothing to do. Start with a longer interval and shorten it once you confirm the agent handles each cycle cleanly without errors or context bloat.
What is the difference between HEARTBEAT.md and a cron job?
HEARTBEAT.md is an OpenClaw-native scheduling mechanism. It runs inside the gateway process, has access to the agent context, and can include conditional logic like exit conditions and retry rules written in natural language. A cron job is an OS-level scheduler that runs a command on a fixed schedule. Cron is more reliable for simple triggers (it runs regardless of gateway state), but it cannot access agent memory or context. Many production setups use both: cron to trigger the agent command, and HEARTBEAT.md to define what the agent does once triggered.
My autonomous agent keeps running out of context. How do I fix it?
Context bloat is the most common problem with long-running autonomous agents. Three fixes: First, add explicit exit conditions in HEARTBEAT.md so the agent finishes each cycle and starts fresh. Second, set max_turns or max_tokens in your SOUL.md to cap how much work the agent does per cycle. Third, avoid appending to session history indefinitely. Use session clearing between heartbeat cycles by adding a post-task cleanup step. The goal is short, focused task cycles rather than one never-ending conversation.
How do I monitor whether my autonomous agents are actually working?
Three layers work together. First, gateway-level health checks: a script that pings localhost:18789/health every few minutes and alerts you via Telegram if the gateway is down. Second, agent-level logging: configure each agent to write structured logs (timestamp, task, result, errors) to a file. Third, output verification: for agents that produce artifacts (blog posts, reports, data), check whether the output actually appeared. A cron job that tails the log file and sends a daily summary via Telegram covers all three layers without you checking manually.
Will an autonomous OpenClaw agent work on a Raspberry Pi?
Yes, with caveats. A Raspberry Pi 5 with 8GB RAM can run a single autonomous agent reliably using an external API provider like Claude or GPT-4. It cannot run local models via Ollama effectively due to limited compute. The Pi is excellent for lightweight agents (monitoring, notifications, data collection) that make API calls and process the results. Use systemd instead of launchd (since the Pi runs Linux), and follow the same daemon, heartbeat, and monitoring patterns described in this guide.