How to Use OpenClaw Standing Orders

Standing orders are how OpenClaw stops waiting for the same prompt over and over. The docs frame them as permanent operating authority for defined programs. Instead of telling the agent to send a weekly report every Friday, you define a durable program with scope, trigger, approval rules, and escalation logic. That is the shift from prompt-driven assistance to actual operations. If you want to use them well, the trick is not making them more clever. It is making them more explicit.

Step 1: put the instructions where the agent will always load them

The recommended place for standing orders is AGENTS.md. The docs are direct about why. AGENTS.md is part of the bootstrap files OpenClaw injects every session, while arbitrary files in subdirectories are not guaranteed to load automatically. You can keep larger support material elsewhere, but the authority itself should be referenced from AGENTS.md if you want it in the agent's face every time the session starts.

Step 2: define one program with four required parts

Each standing order should spell out scope, triggers, approval gates, and escalation rules. Scope defines what the agent owns. Triggers define when it should act, whether that is a schedule, event, or condition. Approval gates define the boundary between autonomous work and human sign-off. Escalation rules tell the agent when to stop improvising and ask for help. If one of those pieces is missing, the order looks broad but behaves unpredictably.

## Program: Weekly Status Report

**Authority:** Compile data, generate report, deliver to stakeholders
**Trigger:** Every Friday at 4 PM
**Approval gate:** None for standard reports
**Escalation:** If data source is unavailable or metrics look unusual

Step 3: pair standing orders with cron jobs instead of duplicating them

The docs say standing orders define what the agent is authorized to do, while cron jobs define when the work happens. That is an important split. Your cron message should reference the standing order instead of repeating every rule inline. This keeps the automation readable and prevents drift. If you change the program later, you only need to update the standing order, not a pile of overstuffed cron prompts scattered around your setup.

openclaw cron add \
  --name daily-inbox-triage \
  --cron "0 8 * * 1-5" \
  --tz America/New_York \
  --timeout-seconds 300 \
  --announce \
  --channel bluebubbles \
  --to "+1XXXXXXXXXX" \
  --message "Execute daily inbox triage per standing orders. Check mail for new alerts. Parse, categorize, and persist each item. Report summary to owner. Escalate unknowns."

Step 4: use the execute, verify, report loop

One of the best sections in the docs is the execution discipline. Every standing-order task should follow Execute, Verify, Report. That means the agent does the work, confirms the result, and only then reports back. The docs explicitly reject fake completion language like I'll do that or Done without verification. This is worth copying into your own instructions because standing orders fail most often when the authority exists but the completion standard is too vague.

Step 5: keep the program bounded

The examples in the docs keep each program narrow and operational. Content programs define review cycles and approval windows. Finance programs define thresholds and escalation conditions. Monitoring programs define automated restarts but escalate after repeated failures. That is the pattern to copy. Give the agent enough room to work without giving it a blank check. In practice, the strongest standing orders read less like a manifesto and more like an operations runbook with clear edges.

If you are writing your first standing order, start with one recurring job you already trust yourself to repeat every week. Put it in AGENTS.md, wire a cron to reference it, and make the approval line brutally clear. That is enough to feel the difference. OpenClaw is happiest when the instructions are durable, boring, and enforceable, because that is what turns automation into something you can rely on instead of something you babysit.

If you want the operator version of these docs turned into a practical working system, read The OpenClaw Playbook. It connects official OpenClaw features to real workflows, guardrails, and deployment decisions.