OpenClaw Workboard and Task Flow: Operator Patterns for Visible Agent Work

OpenClaw now has two official surfaces that matter for agent-owned work:

• Workboard: the optional Gateway-local board for agent-sized cards and linked task/session context.
• Task Flow: the durable orchestration layer for multi-step work above individual background tasks.

CoClaw treats OpenClaw v2026.6.1, published June 3, 2026, as the stable baseline for this guide. Later beta notes are useful to watch, but they are not required for the patterns below.

This page does not replace the official Workboard or Task Flow docs. It gives the operator contract that should exist before a card, flow, cron job, or human asks an agent to keep working after the live chat has moved on.

Quick Choice

If the work is one line and one owner, start with TASKS.md. If the work needs card-level ownership, board recovery, or task/session linkage on the Gateway, use Workboard. If the work is a sequence with waits, retries, child tasks, or restart recovery, use Task Flow.

Stable Baseline

Use the official docs for exact commands and current UI details:

• Workboard plugin
• Automation overview
• Task Flow

The stable shape to rely on is deliberately modest:

• Workboard is optional and Gateway-local.
• Workboard visibility helps with resumption and inspection.
• Task Flow coordinates multi-step flows; background tasks remain the detached work records.
• Cron and heartbeat are scheduling/periodic mechanisms, not project-management systems.
• CoClaw patterns are policy and evidence guidance, not canonical Workboard UI documentation.

Do not require beta-only behavior in operating runbooks unless your team has explicitly chosen that beta and recorded a rollback plan.

The Operator Contract

Before moving work into Workboard or Task Flow, write the contract in the card, flow notes, workspace file, or linked issue:

1. Owner: the human or team accountable for the outcome.
2. Agent boundary: which agent may work, which tools it may use, and which workspace or data it may touch.
3. Authorization source: the message, issue, standing order, or runbook that allows the work to start.
4. Stop condition: the signal that should pause or cancel work, such as cost threshold, failed preflight, missing approval, stale claim, sensitive data exposure, or deadline miss.
5. Escalation path: who gets notified and where the agent records the blocker.
6. Evidence requirement: the artifact, log, task id, flow id, proof note, diff, screenshot, or report needed before anyone can mark the work done.
7. Rollback or recovery: how to undo the change or recover the prior state if the work mutates files, config, credentials, remote systems, or user-facing content.

That contract is more important than the card status. A done label without evidence is just a label.

Visibility Is Not Authorization

Workboard can make work visible and resumable. It does not, by itself, grant authority.

Keep these controls separate:

• Least privilege: expose only the tools, files, channels, providers, and plugins the agent needs for that card or flow.
• Approvals: require explicit approval for destructive operations, external sends, credential changes, deployments, payments, or irreversible writes.
• Audit logs: preserve task records, flow state, Gateway logs, card events, source links, and workspace artifacts so another operator can reconstruct what happened.
• Rollback: define restore steps before the agent mutates production config, public content, shared data, or user-visible integrations.
• Ownership: assign a human owner even when an agent is the worker. The owner decides whether to stop, retry, escalate, or accept residual risk.

If a card cannot name those controls, it is not ready for autonomous or background execution. Keep it in triage, backlog, or a plain TASKS.md checklist until the boundary is clear.

Workboard Pattern

Use Workboard when the operator needs card-level visibility over local Gateway work:

1. Create or triage a card with a short goal, owner, and evidence requirement.
2. Link the source of authority: chat message, issue, incident, standing order, or runbook.
3. Add the stop condition and escalation path before agent work starts.
4. If an agent claims or runs the card, require heartbeats or progress notes during longer work.
5. Review the linked task/session, artifacts, proof, and logs before moving to done.

Workboard should be small operating memory, not a replacement for team project management. Keep GitHub Issues, Linear, Jira, or incident systems as the system of record when they already own cross-team planning, compliance, or customer commitments.

Task Flow Pattern

Use Task Flow when a single card or task is not enough:

1. Split the outcome into sequential or branching steps.
2. Decide whether the flow owns the child tasks or mirrors tasks created elsewhere.
3. Put preflight checks before expensive or irreversible work.
4. Record checkpoints, retries, and revision changes so restart recovery is understandable.
5. Cancel the flow when the stop condition fires; do not rely on a later human noticing stale work.

Task Flow is the orchestration layer. Individual background tasks still matter because they are where detached work is inspected and audited.

TASKS.md Still Has a Job

Do not delete the low-tech board pattern just because Workboard exists.

Use TASKS.md when:

• the Gateway dashboard is not part of the workflow,
• the team wants git-reviewable workspace state,
• cron jobs only need to append a run-log line,
• the work should survive migration between hosts without plugin state assumptions,
• or the operator wants the simplest possible audit trail.

Use Workboard when the board itself should track agent claims, linked tasks, session context, proof, comments, diagnostics, or Gateway-local lifecycle events. Use both when the board coordinates execution but the workspace file remains the durable project log.

Cron, Heartbeat, and Workboard

Cron and heartbeat answer “when should OpenClaw wake up?” Workboard and Task Flow answer “what work is in progress, who owns it, and how do we resume or stop it?”

A stable recurring workflow usually needs all three layers separated:

1. Schedule: cron or heartbeat decides when to check.
2. Orchestration: Task Flow handles multi-step progress if the run is more than one detached task.
3. Visibility and review: Workboard or TASKS.md records owner, evidence, blockers, and completion review.

If cron fires but leaves no artifact, task record, card update, or workspace log, the operator still cannot trust it. Start with the cron reliability guide:

• /guides/openclaw-cron-and-heartbeat-24x7

Completion Checklist

Before marking Workboard or Task Flow work done, confirm:

• the original owner and authorization source are still valid,
• no stop condition fired,
• required approvals are recorded,
• the agent stayed inside the intended tool and data boundary,
• task or flow status matches the linked artifacts,
• proof is inspectable without opening private secrets,
• audit logs or card events explain the path taken,
• rollback evidence exists when the work changed state,
• and the operator accepted the outcome, not only the agent.

Related CoClaw pages:

• /automation
• /guides/openclaw-task-board-template
• /guides/openclaw-operability-and-observability
• /guides/openclaw-cron-and-heartbeat-24x7
• /guides/openclaw-exec-approvals-and-safe-bins
• /guides/openclaw-backup-and-rollback