OpenClaw Best Practices

Separate Daily Logs from Long-Term Memory

Keep daily logs in memory/YYYY-MM-DD.md files and curated insights in MEMORY.md. This prevents context bloat while preserving important information.

# memory/2026-02-09.md (daily raw logs)
## 14:30 - Client call with Acme Corp
- Discussed Q1 roadmap
- Action: Send proposal by Friday

# MEMORY.md (curated long-term)
## Clients
- **Acme Corp**: Prefers video calls, main contact is Sarah

Use memory_search Before Reading Full Files

Instead of loading entire memory files into context, use memory_search to find relevant snippets first. This dramatically reduces token usage for agents with large knowledge bases.

Project-Specific Memory Files

For complex projects, create dedicated memory files like memory/project-name.md. This keeps project context isolated and prevents pollution of your main memory.

memory/
├── 2026-02-09.md        # Today's logs
├── 2026-02-08.md        # Yesterday
├── client-acme.md       # Project-specific
├── api-integrations.md  # Technical reference
└── meeting-notes.md     # Recurring context

Regular Memory Maintenance

Schedule periodic heartbeat tasks to review daily logs and consolidate important information into MEMORY.md. Think of it like a human reviewing their journal.

# In HEARTBEAT.md
## Weekly Memory Review (Sundays)
- [ ] Review past 7 days of memory/*.md files
- [ ] Update MEMORY.md with significant learnings
- [ ] Archive or delete stale information

Heartbeats vs Cron Jobs

Choose the right tool for the job:

Keep HEARTBEAT.md Lean

Your HEARTBEAT.md file runs on every heartbeat poll. Keep it small to minimize token burn. Rotate through checks rather than running everything every time.

# HEARTBEAT.md - Keep it short!
## Quick Checks (rotate through 2-4 times daily)
- [ ] Urgent emails needing response?
- [ ] Calendar events in next 2 hours?
- [ ] Any clients waiting on deliverables?

# Track last check times in memory/heartbeat-state.json

Use Isolated Sessions for Heavy Tasks

For long-running or resource-intensive tasks, spawn isolated sessions with sessions_spawn. This keeps your main session responsive and prevents context pollution.

Announce Mode for Background Work

Use the announce delivery mode for isolated cron jobs to automatically send summaries back to your main channel when tasks complete.

{
  "sessionTarget": "isolated",
  "payload": {
    "kind": "agentTurn",
    "message": "Generate the weekly report"
  },
  "delivery": {
    "mode": "announce"
  }
}

Hub and Spoke Architecture

Designate one main agent as the coordinator (hub) that dispatches tasks to specialized sub-agents (spokes). The hub maintains context while spokes focus on specific domains.

Specialized Agent Personas

Create distinct SOUL.md files for different agent roles. Each persona should have clear responsibilities and communication styles.

# agents/writer/SOUL.md
## Role: Content Writer
- Focus: SEO content, blog posts, marketing copy
- Style: Engaging, clear, persuasive
- Don't: Make technical decisions, execute code

# agents/coder/SOUL.md  
## Role: Technical Developer
- Focus: Code implementation, debugging, architecture
- Style: Precise, well-documented, testable
- Don't: Write marketing content, make design decisions

Use Labels for Sub-Agent Sessions

Assign descriptive labels to spawned sessions for easy identification and messaging:

# Spawn with a label
sessions_spawn(
  task="Research competitor pricing",
  label="research-q1-pricing"
)

# Send messages using the label
sessions_send(
  label="research-q1-pricing",
  message="Focus on enterprise tiers"
)

Model Selection by Task

Match the model to the task complexity. Use faster, cheaper models for routine work and reasoning models for complex problems:

• Quick queries, summaries: fast Gemini/Claude/GPT mini-class models with low thinking
• General work: Claude Sonnet 4.6, Gemini 3 Pro, GPT-5-class models
• Complex reasoning: Claude Opus 4.6, high-thinking Gemini/GPT reasoning models
• Coding tasks: Codex/ACP harnesses, Claude Code, OpenCode, Gemini CLI, or your preferred coding backend

Monitor Token Usage

Use the /status command or session_status tool regularly to track token consumption. The Web UI now includes a comprehensive usage dashboard.

Avoid Context Bloat

Large context windows are expensive. Reduce context by:

• Using memory_search instead of loading full files
• Keeping workspace files focused and minimal
• Starting fresh sessions with /new when context gets stale
• Using the sessions_history cap feature

Strategic Model Switching

Override models per-session based on task requirements:

# For quick questions, use a faster/default model
/model anthropic/claude-sonnet-4-6

# For complex analysis, use a high-reasoning model
/model anthropic/claude-opus-4-6
/reasoning on

Cache Expensive Results

Store API responses, search results, and computed data in memory files rather than re-fetching. This reduces both token usage and API costs.

The Coordinator Pattern

Assign one agent (e.g., Ana) as the Head Coordinator. This agent is responsible for reading SOUL.md, USER.md, and MEMORY.md at the start of every session to ensure consistency and continuity across the entire workspace.

Standardized Project Context

Use a consistent folder structure for projects. This allows any agent to quickly understand the status of a project by reading a single file (e.g., memory/project-name.md).

workspace/
├── projects/
│   └── project-alpha/
│       ├── context.md    # High-level overview
│       ├── tasks.md      # Active todo list
│       └── logs.md       # Session history

Autonomous Memory Maintenance

Enable your coordinator to proactively prune and organize files. Use heartbeats to trigger "workspace health checks" where the agent moves completed tasks to an archive or updates the main MEMORY.md.

The "Think Before You Speak" Pattern

Encourage agents to use the <think> tag or equivalent internal reasoning before performing tool calls or generating final replies. This improves decision quality and reduces unnecessary tool executions.

Agent operations are moving from demos to day-two reliability

The strongest 2026 agent trend is operational maturity. Teams are no longer impressed by one-off autonomous demos; they want agents that can be scheduled, resumed, audited, silenced, retried, and routed without losing the thread. OpenClaw's recent release work mirrors that shift with channel delivery recovery, queue controls, session routing fixes, and safer defaults across chat surfaces.

• Convert repeatable work into isolated cron jobs when the timing or delivery target matters
• Keep softer periodic checks in HEARTBEAT.md so the coordinator can batch context-aware tasks
• Review failed runs weekly instead of letting silent automation drift become normal

MCP and plugin growth need boring governance

MCP, skills, and external plugins are making agents more useful, but they also widen the blast radius. Treat every new connector like a production integration: know what it can read, what it can write, who can trigger it, and how to disable it quickly.

• Prefer allowlisted tools and scoped credentials over broad machine access
• Document installed skills/plugins in TOOLS.md with owner, purpose, and risk notes
• Re-test high-impact tools after OpenClaw updates, especially browser, file, shell, and channel tools

Context engineering beats bigger context windows

Large context windows help, but reliable agents still depend on clean retrieval, durable notes, and explicit workspace boundaries. The practical pattern is small always-loaded files, searchable memory, and project-specific context that can be pulled only when it matters.

• Keep SOUL.md, USER.md, and TOOLS.md concise enough to load every session
• Use memory_search before full-file reads when history is large
• Split long-running client, product, or research work into dedicated memory/project-name.md files

Multi-channel agents need channel-specific policy

A serious OpenClaw setup usually spans Telegram, WhatsApp, Slack, Discord, WebChat, and node surfaces. Do not assume one reply policy fits all of them. Each channel has different privacy, latency, formatting, and social expectations.

• Use mention requirements in groups and stricter allowlists in personal or client channels
• Set per-channel or per-DM model defaults where cost, speed, or privacy requirements differ
• Use delivery targets deliberately so background work returns to the right chat, thread, or operator

July operator checklist

If you run OpenClaw daily, spend 20 minutes this month tightening the basics. This is the unglamorous work that makes agents feel dependable.

• Run openclaw update status and review the latest release notes before upgrading production gateways
• Audit channel allowlists, group mention rules, and direct-message model overrides
• Pick one recurring manual task and move it into a recoverable cron workflow with clear delivery
• Review memory/ for stale, duplicated, or sensitive context that should be archived or split out
• Write down plugin and MCP access assumptions before adding another connector

Source links (updates + community)

• Recent releases: OpenClaw release feed
• Current release line: 2026.6.11 release notes
• Changelog: main changelog
• Community discussions: GitHub Discussions
• Discord: OpenClaw Discord

Use Allowlists Liberally

Configure allowFrom on all channels to restrict who can interact with your agent. For group chats, enable requireMention.

{
  "channels": {
    "telegram": {
      "allowFrom": ["@yourusername", "@trusted_friend"],
      "groups": {
        "*": { "requireMention": true }
      }
    }
  }
}

Separate Private Context

Only load MEMORY.md in your main session — never in shared contexts like Discord servers or group chats. This prevents personal information from leaking.

Review Skill Permissions

Before installing skills, review their SKILL.md and understand what tools they use. OpenClaw now includes a safety scanner for skill/plugin code.

Keep OpenClaw Updated

Security fixes are released regularly. Run openclaw update status and openclaw update weekly, or use the configured update channel for your install.

Check Gateway Status First

When something isn't working, start with openclaw status to verify the gateway is running and healthy.

Review Session History

Use sessions_history to see what happened in a session. Include tool calls with includeTools: true for full visibility.

Enable Verbose Logging

For persistent issues, increase log verbosity:

# Set debug logging
export DEBUG=openclaw:*

# Or in config
{
  "logging": {
    "level": "debug"
  }
}

Test in Isolation

If a skill or automation isn't working, test it in a fresh session to rule out context issues. Use /new to start clean.