OpenClaw Workflows: Automations, Task Flow, Hooks, and Approvals

Start With the Operating Requirement

“Build an OpenClaw workflow” is not a single implementation choice. A daily report, a detached coding run, a session-reset script, an ambient monitor, and a five-step approval process have different timing and recovery semantics.

OpenClaw exposes several mechanisms because these jobs are different:

The official automation overview should be the starting point. Do not copy a third-party workflow.yaml and assume OpenClaw has a generic YAML orchestrator with those fields.

The Mechanisms Are Not Interchangeable

Automations Decide When Work Starts

Automations are the built-in scheduler for one-shot reminders, intervals, cron expressions, and authenticated webhook triggers. They persist jobs, wake an agent, and can deliver output to a channel, webhook, or nowhere.

Use an Automation when the key requirement is timing:

• publish a reviewed operations summary at 09:00;
• check an inbox every 30 minutes in an isolated session;
• run a weekly analysis with a selected model;
• trigger a bounded job from an authenticated webhook.

An Automation does not make a risky action safe. The job still needs a narrow tool policy, a stable target, duplicate suppression, and an approval rule where consequences warrant one.

Background Tasks Record Detached Work

The Background Tasks ledger tracks detached ACP runs, subagent spawns, isolated automation runs, and CLI operations. A Task is a record, not a scheduler.

Operators can inspect the ledger with:

openclaw tasks list
openclaw tasks audit

Treat the task record as execution evidence. It can tell you what OpenClaw believes ran and how it ended; it does not by itself prove that an external email arrived, a pull request merged, or a database transaction committed.

Task Flow Coordinates Durable Multi-Step Work

Task Flow sits above Tasks. A managed flow has:

• a durable status;
• bounded JSON state;
• a revision counter;
• links to authoritative child tasks;
• waiting, cancellation, success, and failure transitions.

Use it when a controller must advance a multi-step process and survive Gateway restarts. State transitions require the latest expected revision. This compare-and-set discipline prevents two controllers from silently overwriting each other.

A call that creates managed flow state does not execute work. Similarly, linking a Task does not launch it. Launch work through its supported runtime, capture the canonical run and session identities returned by OpenClaw, and only then link it to the flow.

Hooks React to Events

Internal Hooks run scripts for lifecycle events such as /new, /reset, /stop, session compaction, Gateway startup, or message flow. Plugin hooks intercept typed in-process events such as tool calls.

Hooks are appropriate for deterministic local reactions:

• initialize a session fixture;
• archive bounded metadata on reset;
• reject a tool call that violates an application policy;
• emit a controlled audit event.

They are not authenticated public webhooks. An external service should use the documented webhook ingress or a dedicated plugin, with sender validation and replay protection.

Standing Orders Carry Explicit Authority

Standing Orders are persistent instructions, typically stored in workspace AGENTS.md files and injected into sessions. They are useful for durable policies such as:

• never send externally without approval;
• use a named evidence source for a regulated report;
• route a certain class of request to an owner;
• stop when a budget or data boundary is reached.

Current OpenClaw does not infer permanent commitments from ordinary conversation. The inferred-commitment behavior was removed in release 2026.8.1. This is a useful safety property: persistent authority is visible, reviewable, and version-controlled.

Heartbeat Is Ambient Monitoring

Heartbeat is a system-owned monitor automation, scheduled every 30 minutes by default. It is designed to surface main-session information that requires attention, often silently when there is nothing to report.

Use Heartbeat for ambient awareness. Use a separate Automation for a job with its own exact schedule, isolated context, delivery policy, or audit history. Turning every periodic task into Heartbeat couples unrelated work to the main session and obscures ownership.

A Production Workflow Pattern

Consider a daily incident digest. The unsafe version asks an agent to “read alerts, decide what matters, and notify everyone.” The reliable version separates facts, judgment, and side effects.

Step 1: Define the Contract

Write an application-owned contract before configuring OpenClaw:

{
  "workflow": "daily-incident-digest",
  "version": 3,
  "trigger": "09:00 UTC",
  "inputs": ["approved alert snapshot", "service ownership map"],
  "outputs": ["digest draft", "evidence links", "delivery receipt"],
  "side_effects": ["send to ops channel"],
  "approval": "required when severity >= high",
  "dedupe_key": "date + destination + workflow_version",
  "timeout": "10m",
  "owner": "reliability"
}

This is a design record, not an OpenClaw configuration file. It makes the guarantees testable before model behavior enters the system.

Step 2: Pick One Owner for Each Concern

For a simple report, Automation plus a Task may be enough. Add Task Flow only when there are real resumable stages, such as collect, review, wait for approval, publish, and verify.

Step 3: Separate Read and Write Phases

A robust sequence is:

collect immutable snapshot
  -> normalize and validate
  -> ask model for a draft with evidence IDs
  -> run deterministic policy checks
  -> wait for approval when required
  -> execute one bounded side effect
  -> verify downstream receipt
  -> persist terminal outcome

The model may draft or classify. It should not be the sole authority deciding that its own evidence is complete, its own action is authorized, and its own delivery succeeded.

Step 4: Make Every Boundary Idempotent

Use a stable operation ID across schedule, flow, tool, and downstream service. Before a retry:

1. read the current flow revision;
2. inspect the authoritative task or downstream result;
3. reuse the same operation ID;
4. apply the next transition only if the expected revision still matches;
5. record duplicate suppression as an outcome, not as an error.

Retries should be bounded by error class. Validation and permission failures require correction, not exponential backoff. Transient transport failures may be retried. Unknown outcomes require reconciliation first.

Where Lobster Fits

The optional Lobster plugin runs a constrained multi-step pipeline as one tool call. It supports explicit approval or input checkpoints and returns a resume token, allowing the workflow to continue without rerunning earlier steps.

That model is useful when:

• steps communicate through structured JSON;
• the pipeline should be logged and reviewed as data;
• a side effect must pause for approval;
• deterministic resume matters more than free-form replanning.

Lobster is not enabled by default. Its embedded tool is disabled in sandboxed tool contexts. Enabling it with tools.alsoAllow adds the tool to the active profile; it does not remove other tools. Review the total tool policy, not only the Lobster configuration.

An approval checkpoint is also not a generic listener for a future Slack reply. A real controller must register the external listener, persist correlation, authenticate the response, and resume the exact flow and revision.

Practical Use Cases

Inbox Triage

Safe scope:

• fetch from sender-gated input;
• classify into a fixed taxonomy;
• draft replies;
• require approval before send;
• verify the provider message ID.

Do not let an email body redefine Standing Orders or expand tool permissions. Treat inbound text and attachments as untrusted content.

Repository Maintenance

Safe scope:

• bind the workflow to a repository and base revision;
• create an isolated worktree;
• run allowlisted formatters and tests;
• present the diff and evidence;
• require repository authorization before push or merge.

A passing model review is not a merge authorization. Use branch protection and the repository's native approval model.

Research Digest

Safe scope:

• persist source URL, title, publication date, retrieval time, and excerpt;
• separate source claims from model synthesis;
• deduplicate canonical URLs;
• label inaccessible or secondary sources;
• deliver only after citation and freshness checks.

The output should remain auditable after the source page changes.

Personal Assistant

Safe scope:

• isolate calendar, mail, files, and contacts by account;
• ask before invitations, sends, purchases, or deletions;
• show the exact target and payload at approval time;
• keep memory retention explicit;
• revoke device and provider credentials independently.

Local execution does not imply local data processing if the configured model or tool sends content to a remote provider.

Failure Modes to Test

Combine workflow events with the practices in AI Agent observability: record bounded state transitions, policy decisions, tool outcomes, and costs without defaulting to raw secrets or hidden reasoning.

Rollout Checklist

1. Start with a read-only shadow run and compare it with the human process.
2. Label at least success, no-op, approval, retryable failure, permanent failure, cancellation, and unknown outcome.
3. Add one side effect behind explicit approval.
4. Test duplicate triggers, restart recovery, stale revisions, and revocation.
5. Define per-run step, time, token, and downstream-cost budgets.
6. Review tools and credentials using the AI agent tool security guide.
7. Validate client and invocation behavior against the OpenClaw API guide.
8. Use the Docker deployment guide if the Gateway or sandbox runs in containers.

Sources

• OpenClaw automation overview
• Automations and webhooks
• Background Tasks
• Task Flow
• Hooks
• Standing Orders
• Lobster

Conclusion

OpenClaw workflow reliability comes from assigning timing, execution records, durable state, policy, approvals, and delivery verification to the right mechanisms. Automations schedule; Tasks record; Task Flow coordinates; Hooks react; Standing Orders carry explicit policy; Heartbeat monitors; Lobster optionally runs constrained resumable pipelines. Once those boundaries are explicit, the model can contribute judgment without becoming the scheduler, authorization service, workflow database, and auditor at the same time.