TaskFlow Workflows

TaskFlow is what you reach for when one background job turns into a real workflow. If a plain task is one truck making one delivery, TaskFlow is the dispatcher tracking the whole route, the handoffs, the delays, and whether the next truck should even leave the depot.

That is the key distinction. OpenClaw already has cron for timing and tasks for detached work records. TaskFlow sits above both when your automation has multiple dependent steps and you do not want progress to vanish just because the gateway restarted at the wrong moment.

According to the official OpenClaw docs, TaskFlow is the flow orchestration layer above background tasks. It manages durable multi-step flows, tracks its own state and revisions, and keeps sync semantics clear while individual tasks remain the actual unit of detached work.

What TaskFlow is actually for

Most confusion starts here. People hear "workflow" and assume every automation should use it. That would be like using a warehouse system to remember you need to mail one envelope.

TaskFlow is for work like this:

• step A must finish before step B starts
• some steps need waits, approvals, or retries
• child tasks may run in the background and report back later
• you need durable progress across gateway restarts
• you want one place to inspect or cancel the whole run

If that sounds like your automation, TaskFlow probably belongs in the design.

Where it fits in real automations

The clean mental model is simple:

• Cron: decides when the work starts
• TaskFlow: decides how the multi-step run advances
• Tasks: record each detached unit of work

Think of an airport. Cron is the timetable. A plain task is one aircraft movement. TaskFlow is the control tower making sure departures, landings, gates, and handoffs happen in the right order without collisions.

A good example is a weekday market briefing. The schedule belongs in cron. The actual run might need a preflight check, data collection, summarization, approval, and delivery. That is TaskFlow territory because each stage depends on the previous one and the whole chain needs durable visibility.

What state, waits, and child tasks buy you

This is where TaskFlow stops sounding abstract and starts paying rent.

Durable state

TaskFlow stores workflow progress separately from the live chat turn. If the gateway restarts halfway through a long sequence, the flow still knows what was already done and what remains. That matters for any workflow you would be annoyed to rerun from scratch.

Waits

Some work naturally pauses. You may be waiting for a subagent, a browser step, a human approval, or an external system to finish processing. With TaskFlow, the pause is part of the workflow instead of a fragile piece of improvisation hidden in a prompt.

Child tasks

Flows coordinate tasks, they do not replace them. A flow can launch multiple detached tasks over its lifetime, track which one belongs to which step, and keep the larger run understandable. That is a lot cleaner than mentally stitching together a pile of independent background jobs after the fact.

Managed mode vs mirrored mode

OpenClaw's docs describe two sync modes, and the difference matters.

Managed mode

TaskFlow owns the lifecycle end to end. It creates the child tasks, advances the flow automatically, and decides when the next step should begin. Use this when TaskFlow is the real conductor of the workflow.

Mirrored mode

TaskFlow watches externally created tasks and keeps the flow state synchronized without owning task creation. This is useful when jobs already come from somewhere else, such as cron or CLI operations, and you still want one unified flow view.

The easy shortcut is this: managed mode runs the play, mirrored mode watches the scoreboard.

Revision tracking is more useful than it sounds

Revision tracking sounds like boring plumbing until two different things try to advance the same flow at once. Then it becomes the reason your workflow does not drift into nonsense.

OpenClaw uses revision tracking for conflict detection, which means concurrent updates to a flow can be handled deliberately instead of silently stomping on each other. If you are coordinating several background actors, that guardrail matters.

When TaskFlow is better than plain cron jobs or standing orders

Standing orders define authority. Cron defines timing. Neither one by itself gives you durable multi-step orchestration.

• Use standing orders when the main problem is what the agent is allowed to do repeatedly.
• Use cron when the main problem is when something should happen.
• Use TaskFlow when the main problem is coordinating several dependent steps after the run begins.

In practice, the strongest automations often use all three together. Standing orders give the rules. Cron wakes the run up. TaskFlow keeps the moving parts aligned.

Example shape: scheduled workflow with preflight and approval

The official docs recommend separating schedule, orchestration, and reliability checks into layers. That is sensible. Timing should not be where your whole workflow logic lives.

openclaw cron add   --name "market-intel-brief"   --cron "0 7 * * 1-5"   --tz "Europe/Berlin"   --session session:market-intel   --message "Run the market-intel workflow. Verify source freshness before summarizing."

That cron job should start the workflow. Inside the flow, the steps might look more like this:

1. preflight: verify browser, credentials, quota, and network reachability
2. collect: gather source data as structured JSON
3. summarize: generate the brief from clean inputs
4. approve: preview delivery and require sign-off if needed
5. deliver: publish only if approval passed

That is the real value of TaskFlow. Each step has a job. Each handoff is explicit. Each failure has somewhere sane to live.

When TaskFlow is overkill

This is the part people need to hear. Not every automation deserves orchestration machinery.

• A one-shot reminder does not need TaskFlow.
• A single background analysis run usually does not need TaskFlow.
• A cron job that just sends one report and exits often does not need TaskFlow.
• A simple heartbeat check definitely does not need TaskFlow.

If there are no meaningful branches, waits, retries, or dependent stages, a plain task is easier to read and easier to debug. The best workflow tool is the one you did not overuse.

Operational habits that make TaskFlow worth it

• Keep step boundaries obvious
• Run preflight checks before expensive model work
• Pass structured data between steps when possible
• Use approvals for risky external delivery
• Inspect flows and tasks separately when debugging
• Cancel the whole flow when the larger objective is no longer valid

That last point matters. OpenClaw supports cancelling a running flow and its active tasks. If the business goal died, stop the whole chain. Do not let stale automation keep marching out of habit.

The practical rule of thumb

If your automation can be explained as one detached job, use a task. If it can be explained as "first this, then that, then wait, then maybe approve, then deliver," use TaskFlow.

That is the whole game. TaskFlow is not there to make OpenClaw feel more enterprise. It is there to keep multi-step work durable, inspectable, and less brittle when real life interrupts the run.