OpenClaw Automation Patterns: Building Resilient AI Workflows

As OpenClaw moves from a experimental toolkit to a production-grade framework, the patterns we use to build agents must evolve. We've moved beyond simple "if-then" logic into sophisticated automation patterns that allow agents to reason through complex environments over long durations.

In this guide, we'll dive into the three fundamental patterns used by the Mira fleet: Hooks, Observers, and State-Aware Loops.

The Foundation: Hooks vs. Observers

The most basic pattern in the OpenClaw ecosystem is the Hook. Hooks are event-driven entry points that trigger agent actions based on specific system or external events.

• Pre-Action Hooks: Used for validation and context injection (e.g., checking git status before a push).
• Post-Action Hooks: Used for logging, notification, and cleanup (e.g., updating a sitemap after a blog post).

Observers, on the other hand, are persistent processes that watch a stream of data (like logs, API endpoints, or file changes) and decide when to wake an agent.

Pattern 1: The Observer-Action Loop

This is the workhorse of the Mira fleet. It involves a background process that monitors a resource and spawns a sub-agent when a specific condition is met.

# Example: A simple file-watcher observer
import time
from openclaw import Gateway

gw = Gateway()

while True:
    if os.path.exists("./incoming-data.json"):
        gw.spawn(
            agent_id="mira-wren",
            task="Process the new data in incoming-data.json"
        )
        os.remove("./incoming-data.json")
    time.sleep(60)

Pattern 2: The State-Aware Workflow

One of the biggest challenges in agentic automation is maintaining state across restarts. OpenClaw uses a state.json pattern for every domain-specific loop.

By writing current progress to a persistent file, an agent can be killed and restarted without losing its place in a complex multi-step task.

{
  "last_run": "2026-04-03T11:37:00-07:00",
  "status": "processing_batch",
  "current_focus": "image_optimization",
  "history": [
    "Step 1: Text generated",
    "Step 2: SEO metadata created"
  ]
}

Pattern 3: Error Recovery and Retries

Standard try/catch blocks aren't enough for agents. When an external API fails, an agent needs an exponential backoff strategy or a circuit breaker pattern.

If an MCP server returns a 429 (Rate Limit), the agent should not just fail; it should update its state.json with a retry_after timestamp and exit gracefully, allowing the cron scheduler to wake it back up at the appropriate time.

Frequently Asked Questions