How to Use OpenClaw Task Flow

Task Flow is what you reach for when a job is too big for one detached run but too operationally important to leave as a pile of loosely related tasks. It sits above background tasks and gives the work its own durable identity, which is exactly what you want for multi-step pipelines that survive restarts and human interruptions.

What this feature is really for

The docs frame Task Flow as the orchestration substrate above background tasks. A plain task is a single unit of detached work. Task Flow is the layer that manages several of those units as one flow, with revision tracking and state sync rules. That distinction is useful because it keeps detached execution simple while still giving you a durable object for a report pipeline, approval chain, or other sequence with more than one meaningful checkpoint.

The win is not that OpenClaw gained another abstraction. The win is that you can stop stuffing long operational instructions into ad hoc chat messages and move them into something the gateway can apply consistently. That gives you cleaner sessions, fewer repeated prompts, and much less drift between what you meant and what the agent actually does.

How to set it up without making a mess

The first decision is mode. Managed mode means Task Flow owns the lifecycle end to end and creates the tasks for each step. Mirrored mode means the tasks already exist and Task Flow simply observes them to keep a unified state view. That is a genuinely practical split. If your pipeline is born inside OpenClaw, managed mode is usually the cleanest choice. If cron jobs or other tools already create the tasks, mirrored mode avoids duplication.

# List active and recent flows
openclaw tasks flow list

# Show details for a specific flow
openclaw tasks flow show <lookup>

# Cancel a running flow and its active tasks
openclaw tasks flow cancel <lookup>

• Use a plain task for one background job and Task Flow for multi-step pipelines.
• Choose managed mode when Task Flow should create the step tasks itself.
• Choose mirrored mode when the tasks already come from cron, CLI, or another source.
• Use flow-level state so operators can reason about the whole job instead of one leaf task at a time.

How I would operate it day to day

In day-to-day use, the biggest win is visibility. A weekly report flow is not just “a task that ran.” It is gather-data, then generate-report, then deliver. When one step stalls, you can see which layer failed without reconstructing the story from logs. That makes handoffs better too. Another operator can open the flow, see the active step, and intervene without re-reading the entire session transcript.

Where people go wrong is either overusing Task Flow or underusing it. If the job is one detached command, stay with a plain task. If the job has genuine state transitions, retries, and step ownership, do not fake it with comments and wishful naming. The docs are clear that Task Flow exists to make that middle ground durable. It is worth using when the workflow deserves a first-class object.

A good Task Flow turns a vague “background process” into something operators can inspect, cancel, and trust. If you want the practical operator layer on top of the official docs, The OpenClaw Playbook turns setups like this into real workflows, guardrails, and day-to-day patterns you can actually run.

Revision tracking matters here more than it first appears. Multi-step work tends to attract manual edits, retries, and late clarifications. A flow layer that knows which revision is current protects you from several classes of invisible state drift.