OpenClaw Task Flow CLI - Managing Multi-Step Agent Workflows from the Command Line

If you're running OpenClaw agents in production, you'll spend more time in the CLI than you might expect. The web interface is fine for setting things up and reviewing results, but when a flow stalls at 2am or you need to quickly check what's running across your gateway, the command line is where you'll live.

OpenClaw's flow commands are tucked under openclaw tasks flow - they're subcommands of the tasks CLI, not a standalone flows command. This trips people up early on. You type openclaw flows and get nothing. It's openclaw tasks flow. Small thing, but it saves you the thirty seconds of confusion.

We've been running OpenClaw for clients through our managed service offering, and the CLI flow commands are part of our daily operational toolkit. Here's what each command does and when you'd use it.

The Three Flow Commands

The flow CLI has three commands. Just three. This is one of the things I appreciate about OpenClaw's design - it doesn't drown you in subcommands.

Listing Flows

openclaw tasks flow list
openclaw tasks flow list --json

This shows you every flow that exists on your gateway. Running flows, completed flows, failed flows - all of them. Without the --json flag, you get a human-readable table. With --json, you get structured output that you can pipe into jq or feed into monitoring scripts.

When do you use this? All the time. It's the first command you run when you want to understand what's happening. Is that weekly reporting flow still running? Did the data sync flow from last night complete? Are there any flows stuck in a running state that shouldn't be?

In practice, we wrap openclaw tasks flow list --json into a simple monitoring script that checks for flows that have been running longer than expected. If a flow that normally takes 20 minutes has been running for two hours, something's probably wrong. The JSON output makes it easy to parse flow states and durations programmatically.

Inspecting a Flow

openclaw tasks flow show <lookup>

This gives you the detail on a specific flow. The <lookup> parameter is the flow identifier - either the flow ID or the flow name, depending on how you have things set up.

The output shows you each step in the flow, its current state, and the underlying task details. This is where you figure out what went wrong when a flow fails. Did step 2 error out? Did step 3 never start? Is the flow waiting on an external dependency that isn't responding?

I find myself using flow show most often for debugging production issues. A client says "the morning report didn't arrive." You run flow show morning-report and immediately see that step 1 (data extraction) succeeded but step 2 (report generation) failed with a timeout error. Now you know where to look.

Cancelling a Flow

openclaw tasks flow cancel <lookup>

This cancels a running flow. The currently executing step gets terminated, and the remaining steps never run.

Use this carefully. Cancelling a flow mid-execution can leave data in an inconsistent state if the current step was writing to a database or external system. It's safe for read-only operations and for flows where each step is idempotent (can be safely re-run). It's less safe for flows that make irreversible changes.

We've had situations where a flow was running against a staging environment but someone had accidentally pointed it at production. Cancelling fast was the right call. But for routine "this is taking too long" situations, I'd usually prefer to wait for the current step to finish and then cancel, rather than interrupting mid-step.

Practical Patterns We Use

Health Checks

Our standard health check for OpenClaw gateways includes a flow status review. We run:

openclaw tasks flow list --json | jq '[.[] | select(.status == "running")] | length'

This gives us the count of currently running flows. We compare that against expected baselines. If there are normally 2-3 flows running during business hours and suddenly there are 15, something is spawning flows unexpectedly. If there are normally 3 and there are 0, flows might have stopped being triggered.

Post-Incident Review

When a flow fails, the sequence is usually:

1. openclaw tasks flow list - find the failed flow
2. openclaw tasks flow show <flow-id> - identify which step failed
3. Check the underlying task logs for the failed step
4. Fix the issue
5. Re-trigger the flow

This is straightforward but having the CLI commands memorised makes the process fast. Every minute matters when a client's morning reports are delayed and their team is waiting.

Cleaning Up Stale Flows

Sometimes flows get stuck - not failed, not completed, just... sitting there. This happens occasionally when a gateway restarts mid-flow or when an external dependency times out in a way that the flow manager doesn't detect.

The fix is usually openclaw tasks flow cancel <stale-flow-id> followed by re-triggering the flow. We keep a runbook of known stuck states and their resolution steps. Most of them come down to "cancel and retry."

Where Flow Commands Fit in the Bigger Picture

The flow CLI is one piece of a larger operational picture. OpenClaw's background tasks, cron scheduling, and hooks all interact with flows. If you're new to OpenClaw, I'd suggest reading about Task Flow orchestration for the conceptual model, and the background tasks guide for understanding the individual tasks that flows coordinate.

The official OpenClaw documentation is the canonical reference, and links out to the full Task Flow and tasks CLI reference docs. What I've covered here is the operational perspective - how these commands get used when you're actually running agents in production rather than just setting them up.

Should You Be Using Flows?

If your AI agents are doing single-shot tasks - answer a question, process a document, generate a response - you probably don't need flows. Background tasks are sufficient.

Flows become valuable when you have multi-step processes where the output of one step feeds into the next, or where you need to track the overall progress of a sequence of operations. Think data processing pipelines, multi-stage content generation, or automated workflows that span several agent interactions.

The threshold we use at Team 400: if you find yourself writing code to check whether task A finished before starting task B, you should be using a flow instead. Let OpenClaw handle the orchestration while your code focuses on what each step actually does.

If you're running OpenClaw agents and want help setting up production workflows - or if you're evaluating OpenClaw for your agentic automation needs - reach out to our team. We've been building and operating these systems long enough to have opinions about what works and what's a waste of time.