# OpenClaw Standing Orders Standing orders are [[OpenClaw]]'s mechanism for **persistent operating authority**: a written mandate that gives an agent permission to do *X* under conditions *Y* without re-asking each time. Defined primarily in `AGENTS.md` files inside a workspace, they make autonomous loops legitimate and auditable rather than ad-hoc. The pattern matters because chat-driven agents are otherwise stuck in synchronous request/response. Standing orders unlock the "while I sleep, do this" mode that makes overnight coding supervision, automated triage, and scheduled briefings safe to deploy. ## What a Standing Order Specifies - **Scope** ; what the agent is authorized to act on (which repos, which channels, which tools) - **Triggers** ; what fires the order (cron schedule, inbound event, heartbeat, webhook, threshold) - **Approval gates** ; for which actions does it still need a human in the loop - **Escalation rules** ; what to do when uncertain or blocked - **Reporting cadence** ; when and where to surface results ## Execute-Verify-Report Pattern Programs running under standing orders follow the documented **Execute-Verify-Report** loop: 1. **Execute** ; do the work as instructed 2. **Verify** ; check that the work meets the stated success criteria 3. **Report** ; surface what was done, what wasn't, and why ; in the agreed channel This is the discipline that prevents silent drift. A standing order without a Report step is a black hole. ## Time-Based Triggers Time-based triggers are enforced via **automations** (called cron jobs before OpenClaw 2.0): a separate scheduling layer that wakes the agent at `*/15 * * * *`, `0 7 * * 1-5`, etc., and dispatches the matching standing order. Standing orders define *what*; automations define *when*. Other dispatch primitives include heartbeat, polls, and webhooks. Since [[2026-10-03 OpenClaw 2.0 - easier setup, shared sessions, same security defaults|OpenClaw 2.0]], "Automations" is the name in the agent tool, Control UI, CLI and docs. `openclaw automations` mirrors `openclaw cron`, and existing cron commands, settings, schedule expressions and jobs keep working. Two changes matter for standing orders: an automation's connected tools keep only the authority captured when it was created or reauthorized (rechecked against current policy on every run), and recurring automations show their standing approval grants, which you can revoke so the next run asks again. ## Risk Posture Standing orders are powerful, which means the boundary work matters. Recommended posture: - Start narrow ; small scope, tight schedule, explicit approval gates - Add a **command-logger** [[OpenClaw Hooks|hook]] for audit - Run risky orders in **sandboxed sessions** when possible - Review the report channel before widening scope ## Composition A typical autonomous routine layers four primitives: 1. A **standing order** with the policy and triggers 2. An **automation** (formerly cron job) firing at the right cadence 3. **Sub-agents** doing the parallel work in the background 4. **Hooks** observing each step for audit ## References - Standing Orders: https://docs.openclaw.ai/automation/standing-orders - Automations: https://docs.openclaw.ai/automation/cron-jobs - OpenClaw 2.0 automations changes: https://docs.openclaw.ai/releases/2026.8.1/automations-and-scheduling ## Related - [[OpenClaw]] - [[OpenClaw Hooks]] - [[OpenClaw Sub-Agents]] - [[OpenClaw Skills]] - [[Claude Code Routines]]