OpenClaw standing orders

Prompting an agent for every routine task makes you the bottleneck and lets routine work slip. OpenClaw’s answer is the standing order: permanent operating authority for a defined program, written down once, so the agent owns the weekly report, compiles it every Friday, sends it, and escalates only when something looks wrong. Here is where standing orders live and why that location matters, what a program contains, how they pair with automations, the docs’ three examples, the execution discipline that keeps them honest, and how to organise several programs.

Where they live and what they contain

• Standing orders are defined in the agent workspace files, ideally directly in the agents file that the workspace bootstrap injects every session, or in a dedicated standing-orders file referenced from it for larger setups; the bootstrap injects the agents, soul, identity, user, bootstrap and memory files but not arbitrary files in subdirectories, so a program hidden elsewhere is not loaded.
• The one-shot agent exec entry point skips workspace bootstrap files on purpose, so a strict CI or scripting run is self-contained rather than governed by standing orders.
• Each program specifies four things: scope, what the agent is authorised to do; triggers, when to execute, by schedule, event or condition; approval gates, what needs human sign-off before acting; and escalation rules, when to stop and ask for help.
• The docs’ anatomy is a weekly status report program with an authority line, a Friday trigger enforced by an automation, an approval gate that flags anomalies for review, an escalation rule for unavailable sources or metrics more than two standard deviations from the norm, five execution steps, and a what-not-to-do section: no reports to external parties, no changes to source data, and no skipped delivery when the numbers look bad.

Standing orders define what the agent is authorized to do. Automations define when it happens.

Orders plus automations

The two mechanisms work together: the standing order says the agent owns the daily inbox triage, the eight o’clock automation says execute the triage per standing orders, and the agent reads the order, executes the steps and reports the results. The automation job’s prompt should reference the standing order rather than duplicate it; the docs’ example adds a weekday job with a timezone, a five-minute timeout, an announce flag with a channel and recipient, and a message that says to execute the triage per standing orders, check mail for new alerts, parse, categorise and persist each item, report a summary and escalate unknowns. Standing orders without triggers become suggestions, which is why the avoid list ends with forgetting to enforce them.

Examples and discipline

• Three worked programs: content and social media on a weekly cycle, with all posts requiring owner review for the first thirty days and content rules about brand voice, never identifying as AI in public content and focusing on audience value; financial processing triggered by a new data file or a monthly cycle, with analysis needing no approval, recommendations needing the owner, and escalation on any single item above five hundred, a category twenty percent over budget, an unrecognisable transaction, or a failure after two retries; and continuous system monitoring on every heartbeat, with automatic restarts, escalation when a restart fails twice, and a response matrix for downed services, low disk, stale tasks and offline channels.
• The execute-verify-report pattern makes every task do the work, confirm the result, then tell the owner what was done and verified: saying it will be done is not execution, done without verification is not acceptable, a failure gets one retry with an adjusted approach and then a reported diagnosis, never a silent failure, and never more than three attempts before escalating. The docs call this the cure for the most common agent failure, acknowledging a task without completing it.
• For several concerns, keep separate programs with their own trigger cadence, approval gates and clear boundaries, plus a shared escalation section that applies across all of them.

The OpenClaw agent workspace lists the bootstrap files that make a standing order load, and OpenClaw automations is the timing layer that enforces it.

Do and avoid

Start with narrow authority and expand as trust builds, define explicit approval gates for high-risk actions, include what-not-to-do sections, combine with automations, review the agent’s logs weekly, and treat the orders as living documents. Avoid granting broad authority on day one, skipping escalation rules, assuming verbal instructions will be remembered, mixing concerns in one program, and leaving orders without triggers. OpenClaw heartbeat is the cycle the monitoring example runs on, and OpenClaw session goals the per-session objective that complements a standing program.

On Diali

On Diali the agents file is the workspace file the dashboard seeds into the assistant, so standing orders written there load every session, and the automations screen supplies the schedule. Hosted OpenClaw on Diali is the assistant and The OpenClaw SOUL file the companion file that carries the voice a content program refers to.

• Scope, triggers, approval gates, escalation.
• Orders say what; automations say when.
• Execute, verify, report; three attempts, then escalate.