A cron is a schedule. The schedule fires a payload. The payload runs an agent turn. The agent turn does work — calls tools, walks loops, executes skills, drives workflows, advances cards. None of those layers is special by itself. The composition is what produces a useful automation.

This article is about the composition. It picks up from Cron Jobs in OpenClaw: Schedule Types, Payloads, and Delivery and asks: what does the agent turn inside a cron actually do, and how do the surrounding pieces (skills, loops, lobsters, workboard) fit?

The article is for operators who already understand cron basics and want the integration map. It does not re-derive the cron design discipline (that is Cron Jobs, Heartbeats, and Scheduled Work and the glossary pieces). It picks up where those leave off.

The cron as a trigger, not a worker

The first mental shift is to stop thinking of a cron as the thing that does the work. The cron is the trigger. The work happens in the agent turn that the cron spawns.

This shift changes how you design. A cron with a command payload (scripts/check-queue.sh) does the work directly. A cron with an agentTurn payload (--message "Reconcile the day's transactions") hands the work to the model. A cron with a systemEvent payload ("Next: clean the inbox") injects the trigger and lets whatever session picks it up do the work.

Most useful crons are in the middle. The cron is the trigger, the agent turn is the worker, and the worker is bounded by what the operator has set up.

Skills inside a cron-driven turn

A skill is a named bundle of instructions and tools. When an agent turn runs, the agent has the skills its agent profile allows. The cron does not grant or deny skills; the agent profile does. The cron just decides when the turn runs and what prompt the turn receives.

The design pattern: the cron's prompt names the skill. The agent turn picks the skill up and runs it.

openclaw automations add \
  --name "Inbox triage" \
  --cron "0 */1 * * *" \
  --tz "America/New_York" \
  --session isolated \
  --message "Use the inbox-triage skill. Mark each unread message as keep/skip/reply. Append the day's decisions to daily/$(date +%Y-%m-%d).md."

The skill itself is a markdown file or a plugin entry; the agent turn invokes it the same way it would in chat. The cron's prompt is the routing mechanism: it tells the turn which skill to use and what artifact to write.

The mistake to avoid is putting the skill instructions inside the cron's prompt. Skills belong in their own files so they can be reused across crons, chat, and other contexts. The cron's prompt should be a routing message, not the documentation.

Loops inside a cron-driven turn

A loop is a cycle. Inside an agent turn, a loop is the recurring intake → context → inference → tool → persist → repeat pattern that the agent walks each time it picks up a turn. The agent loop is six stages; the article Inside the Agent Loop walks through each one.

A cron does not "run a loop." A cron spawns a turn, and that turn walks the loop once. If the cron is recurring (every 5m), each fire is a fresh turn, and the loop runs once per fire. If the prompt asks the turn to "iterate until the queue is empty," the turn walks the loop multiple times within a single fire.

Two design patterns show up:

1. Single-fire loops. The cron fires, the turn walks the loop once, the turn terminates. Used for daily briefs, weekly reconciliations, anything where the work fits in one turn. 2. Iterating loops inside a turn. The cron's prompt tells the turn to walk the loop multiple times within the same fire. The turn exits when its termination condition is met (queue empty, deadline reached, budget spent). Used for "process everything pending" patterns.

The pattern that goes wrong: crons that fire faster than the loop can complete. A every 1m cron with a 5-minute loop produces overlapping runs, contention for the same state file, and quiet corruption. The fix is either to slow the cron down or to make the loop's termination tight.

Lobsters and the orchestration layer

Lobster is OpenClaw's local-first workflow runtime. A lobster pipeline is a typed JSON envelope that orchestrates multi-step work with resumable approvals. Crons do not directly invoke lobsters, but a cron's prompt can tell an agent turn to run a lobster pipeline.

openclaw automations add \
  --name "Daily reconciliation" \
  --cron "0 6 * * *" \
  --tz "America/New_York" \
  --session isolated \
  --message "Run the daily-reconciliation lobster pipeline at workflows/daily-reconciliation.lobster. Surface any approval gates."

The cron's job is to fire the trigger. The lobster's job is to orchestrate the steps. The agent turn's job is to bridge the cron and the lobster — invoke the pipeline, watch for approval gates, surface results.

This is the right shape for work that has multiple steps, multiple approvals, or resumability needs. A lobster can pause for human approval and resume later; the cron's turn just kicks it off. When the lobster finishes, the agent turn reports back (or doesn't, depending on delivery mode).

The mistake to avoid is putting the multi-step orchestration in the cron's prompt. If the work needs three stages with checkpoints, that is a lobster, not a prompt. The cron fires; the lobster orchestrates; the agent turn bridges.

Workboard and the state-graph layer

Workboard is OpenClaw's card-based state-tracking system. A workboard card has a status (backlog, ready, running, complete, failed, blocked), an assignee, and an audit trail of attempts, comments, and proofs. Crons drive workboard cards by having their agent turns create, advance, claim, complete, or block cards.

The integration has three parts:

1. The cron fires. A schedule hits, a payload runs, an agent turn starts. 2. The turn drives the card. The turn calls workboard_* tools to claim a card, append a comment, attach proof, advance the status. 3. The card's lifecycle is the audit trail. Each attempt the cron makes produces a workboard record. Failed runs leave a failed status with an error message. Successful runs produce a complete with proof.

A typical pattern is a heartbeat-style cron that drives a daily-triage workboard:

openclaw automations add \
  --name "Daily triage" \
  --cron "0 8 * * *" \
  --tz "America/New_York" \
  --session isolated \
  --message "Run the daily-triage workflow. For each ready card on the LIP-default board, claim it, append a 'triage-done' comment, and complete or block it. Do not start work; only triage."

The cron is the schedule. The turn is the worker. The workboard is the state graph. The composition is what makes the pattern auditable — every action has a card, every card has an audit trail, and the audit trail is the answer to "what did the cron do yesterday?"

The mistake to avoid is using a cron to do work that should be tracked on a workboard card but isn't. If the cron produces state changes that the operator needs to see, the turn should write those changes to a card. The card is the audit trail. The cron is just the trigger.

State graphs that span crons

The article State Graphs in Practice describes state graphs as explicit stages with named transitions. A cron can be the trigger for one or more transitions in a state graph.

The pattern:

1. The state graph has stages. Each stage is a known state with a validation check. 2. Crons fire the transitions. A cron fires when the state should move forward. 3. The agent turn runs the work. The turn executes the transition, validates the result, and updates the state. 4. A separate cron fires the next transition. The next stage's cron takes over.

This is how multi-stage pipelines look in practice. A daily ETL pipeline has stages (extract, transform, load, validate) and crons that fire each transition. The graph is explicit; the crons are the timing; the agent turns are the workers.

The mistake to avoid is putting the entire graph in a single cron's prompt. If the graph has four stages and the cron's prompt is "run the whole thing," the failure mode is opaque. A cron's prompt should be one stage, not all of them.

The composition rules

Five rules from the patterns above. Each one is a discipline that keeps the composition safe.

1. The cron is a trigger, not a worker. The cron's job is to fire. The agent turn's job is to do the work. If the work needs the model, the cron's payload is agentTurn. If the work is a shell probe, the payload is command. The cron is the smallest thing that produces a turn.

2. The cron's prompt is a routing message. It names the skill, lobster, or workboard card the turn should drive. It does not contain the skill's documentation. It does not contain the lobster's steps. It does not contain the workboard card's spec. The cron's prompt is the pointer, not the content.

3. The skill, lobster, and workboard card are reusable. A skill should not be defined inside a cron's prompt because the skill should be usable from chat, from other crons, from other agents. The same goes for lobsters and workboard cards. If the artifact lives in a cron's prompt, the artifact is locked to that cron.

4. The state lives in workboard cards, not in cron's prompt. State that needs to survive between cron runs lives on a card, in a file, or in a database. State that lives in a cron's prompt is gone when the cron fires next time. Crons do not have memory; the things they touch do.

5. The cron is the smallest trigger that does the job. If the work is recurring, the cron is recurring. If the work is event-driven, the cron is a stream schedule. If the work is one-shot, the cron is at. The schedule kind matches the work's shape; the schedule kind does not "happen to be" cron.

A worked example

A small composition that puts all the pieces together: a daily briefing that pulls from a lobster pipeline, drives a workboard card, and delivers to a chat channel.

# 1. The cron fires at 7 AM Eastern
openclaw automations add \
  --name "Daily briefing" \
  --cron "0 7 * * *" \
  --tz "America/New_York" \
  --session isolated \
  --message "Run the daily-briefing lobster at workflows/daily-briefing.lobster. Append the result to the daily-briefing workboard card. Announce the summary to slack:#ops." \
  --announce \
  --channel slack \
  --to "channel:C1234567890"

# 2. The lobster (workflows/daily-briefing.lobster) runs four steps:
#    - pull overnight calendar events
#    - pull inbox summary
#    - pull workspace state diff
#    - write the daily/YYYY-MM-DD.md artifact

# 3. The workboard card holds the audit trail:
#    - one card per day
#    - status moves ready → running → complete
#    - proof attached at the end

# 4. The agent turn bridges cron → lobster → workboard → chat

Each layer has one job. The cron is the trigger. The lobster is the orchestration. The workboard is the state. The chat channel is the delivery. The agent turn is the bridge.

What this changes for operators

The shift this kind of composition introduces is mostly about layering. An operator who understands the layers picks the right tool for each step. An operator who does not understand the layers puts everything in the cron's prompt and ends up with a cron that is hard to debug, hard to reuse, and easy to break.

The composition is what makes scheduled work maintainable. A skill that lives in a file is reusable across crons and chat. A lobster pipeline that lives in a file is auditable. A workboard card that records each run is the answer to "what did the cron do yesterday?" Each layer is a different concern; each layer's artifact lives in a different place.

The cron is the trigger. Everything else is what the trigger touches.

Related reading