A workflow is a procedure with a trigger. The trigger tells the workflow when to run; the procedure tells it what to do. That is the whole definition. Everything else — schedules, payloads, delivery, failure recovery — is a refinement of those two pieces.

This piece covers the three shapes a workflow trigger can take, how to build a minimum viable workflow, the discipline that keeps workflows from breaking, and the patterns that hold up as you grow.

What a workflow is

A workflow has three parts: a trigger, a payload, and optional delivery.

The trigger is the when. It can be a time (cron), a call (on-demand), or an event (webhook, message, file change). The trigger determines when the workflow fires, which determines what failure modes you have to design for.

The payload is the what. It is the set of instructions the agent follows when the workflow fires — from a single file write to a multi-step pipeline. The complexity of the payload is independent of the trigger; a simple trigger can carry a complex payload, and a complex trigger can carry a simple one.

Optional delivery is where the result goes when the workflow finishes. A fully working workflow can write to a file and stop. It can write to a file and then send a message. It can write to a file and then trigger another workflow. Delivery is where workflows compose, and where the failure tree grows.

The piece on cron schedules, payloads, and delivery in OpenClaw covers the three shapes in depth. This piece is the beginner companion — the same concepts without the platform-specific details.

The minimum viable workflow

A workflow that actually works has five lines. It fires on a schedule, writes a one-line status to a file, and stops. That is the entire payload.

Trigger: daily at 5am
Read the daily notes from yesterday
Write a one-line status summary to /memory/daily-status.md
Log the run timestamp
Exit

What this workflow does: it proves the pipeline works. The trigger fires. The agent reads the right file. The agent writes to the right file. The log exists. If something in that chain breaks, the failure is visible.

What this workflow does not do: it does not send a message, it does not call an external API, it does not make decisions, and it does not retry on failure. Those capabilities are added as the workflow matures.

The cron workflow

A cron workflow fires on a time schedule. Cron is the right trigger for anything that needs to happen at a regular cadence: a daily brief every morning, an hourly check every hour, a weekly summary every Monday.

The discipline for cron workflows is idempotency — designing the payload so it is safe to run more than once. If the cron fires while the previous run is still in progress, or if the operator manually re-triggers the workflow, the second run produces the same result — it does not double-write, double-send, or double-create.

The practical pattern: before doing anything, check whether it was already done. Write a status file at the start of the run. Check for the status file before starting. If it exists and is recent, skip. If it is stale or absent, run. This pattern adds two lines to the workflow and prevents the most common cron failure mode.

The cron versus heartbeat glossary entry covers the distinction: cron is time-based, external schedule; heartbeat is time-based, internal schedule. For most beginner workflows, cron is the right trigger.

The piece on effective cron design covers the advanced patterns — what to do when the payload is large, how to handle partial failure, and how to design for recovery when the cron fires while the previous run is still in progress.

The on-demand workflow

An on-demand workflow fires when something calls it — a user asks, a parent agent decides, a button is pressed. On-demand is the right trigger for anything ad-hoc or interactive.

The discipline for on-demand workflows is partial-state awareness. Unlike a cron workflow, which starts from a clean state on a schedule, an on-demand workflow may fire in the middle of something else. The payload should check the current state before making changes. If the previous run left the system in an intermediate state, the current run needs to know that before it proceeds.

The practical pattern: the first step of the payload is always a read. Read the current state, the logs, the last daily note. Then decide what to do. An on-demand workflow that dives straight into writing without reading first is a workflow that will eventually overwrite something it should not have.

The crons, skills, loops, lobsters, and workboard piece covers where on-demand workflows fit in the broader ecosystem.

The event workflow

An event workflow fires when something happens — a webhook arrives, a file is written, a message hits an inbox. Event is the right trigger for anything that needs to react to the world.

The discipline for event workflows is out-of-order handling. Events can arrive out of order, in bursts, or duplicated. A webhook that fires three times in one second should not produce three runs.

The practical pattern: assign a unique idempotency key to each incoming event. Store the key in a simple log or database when the event is processed. If the same key arrives again, skip processing and log the duplicate. This prevents the duplicate-processing failure mode that is the most common cause of event workflow failures in production.

The agent eval workflow piece covers how to test workflows — including event workflows — before they ship.

Composing workflows

The simplest workflows are independent: they fire, they do their thing, they stop. The next step up is composition: the output of one workflow becomes the input of the next.

The pattern: a daily brief cron fires and writes a summary file. A weekly summary workflow fires and reads the last seven daily summary files, then writes a weekly report. A monthly report workflow fires and reads the last four weekly reports and writes a monthly digest. Each workflow is independent; the composition happens at the delivery layer.

The cost of composition is failure surface area. Each workflow in the chain is a potential failure point. If the daily brief fails on Monday, the weekly summary on Friday is working with six days of data instead of seven. The discipline: keep chains short until there is a clear reason to lengthen them.

What makes a workflow break

Five failure modes appear in almost every broken workflow.

Model unavailable. The workflow calls a model API and gets a 503 or timeout with no retry. The fix: add exponential backoff, and a dead-letter path when the retry budget is exhausted.

Payload too large. The workflow puts a large file or API response into context. The context window fills, the model behavior becomes unpredictable. The fix: summarize before appending, truncate at a fixed size.

No verification step. The workflow completes but does not check the result — it produces an empty summary or a message addressed to the wrong recipient. The fix: after every write, read and validate. Retry or alert if validation fails.

No audit log. The workflow ran but nobody can prove what it did. The fix: log the trigger, the inputs, the key decisions, the outputs, and the exit code. The log is the first place the operator looks when something is wrong.

No recovery path. The workflow failed midway — file half-written, API called but response not processed. The fix: design the workflow to be safely re-runnable (idempotency) and checkpoint state before each step.

The piece on context management and system prompts covers why payloads are context too — and why a payload that is too large for the context window is a workflow that will eventually fail in a way that is hard to diagnose.

The first workflow to build

The recommendation is specific: a daily cron that writes a one-line status to a file. If that works, the pipeline is real.

The one-line status is not the point. The point is that the pipeline works end to end. The trigger fires. The agent reads its instructions. The agent writes to the file. The file is written with the right content at the right time. If that chain is solid, everything else builds on it.

The second workflow to build: a daily cron that reads the previous day's daily notes and writes a summary. That is the workflow that proves the agent can read what it wrote and make something useful out of it. The third: a weekly summary that reads the last seven daily summaries and writes a weekly report. Each step adds one new capability. Each is testable in isolation. Each is a workflow you can actually use, not a demo.

What this is not

This piece is not a guide to the OpenClaw cron system specifically. The trigger syntax, payload format, and delivery options are platform-specific. The concepts — idempotency, partial-state awareness, out-of-order handling — apply to any workflow system.

This piece is not a guide to workflow complexity. A workflow that takes three inputs, calls two external APIs, and sends a message is not a beginner workflow. Complexity is added as the use case demands it.

This piece is not a guide to workflow testing. The agent eval workflow piece covers how to test workflows rigorously before they ship.

See also