Standing Orders

Most beginners do not fail because their agent is weak. They fail because they keep treating it like a brilliant intern who needs a fresh Slack message for every tiny task. Standing orders fix that.

Think about a hospital night shift. Nurses do not page the chief doctor for every routine blood pressure check or standard medication round. They work from clear standing instructions, then escalate when something falls outside the agreed boundaries. That is the right mental model for OpenClaw too.

A standing order gives your agent durable authority for a defined program. Instead of saying, "send the weekly report" every Friday, you define the program once: gather the data, generate the report, send it to the right place, and escalate if anything looks wrong.

What standing orders actually do

Standing orders move your agent from reactive mode into responsible autonomy. The goal is not blind freedom. The goal is bounded execution.

• Scope: what the agent is allowed to do
• Triggers: when the program should run
• Approval gates: what still needs human sign-off
• Escalation rules: when the agent must stop and ask

That structure matters. Without it, "be proactive" becomes guesswork. With it, the agent has a lane to drive in.

Standing orders vs cron jobs

This is the distinction people miss. Standing orders define what your agent owns. Cron defines when it wakes up and executes. One without the other is incomplete.

Prussian military planners in the 19th century popularized a style later called Auftragstaktik, or mission command. Leaders set intent, boundaries, and escalation expectations, then officers executed locally without waiting for fresh instructions every minute. Standing orders work the same way. You define intent and guardrails once, then let the agent handle routine terrain on its own.

The clean split

• Standing order: "You own daily inbox triage. Categorize, summarize, archive, and escalate unknowns."
• Cron job: "Run every weekday at 8:00 AM and execute inbox triage per standing orders."

If you put all of that logic into the cron prompt itself, you will repeat yourself, drift over time, and eventually forget which version is the real one.

Where standing orders should live

In OpenClaw, the recommended place is AGENTS.md. That file is auto-injected into every session, which means the agent reliably sees the standing order each time it wakes up.

You can keep larger programs in a separate file such as standing-orders.md, but your AGENTS.md should point to it clearly. The safe default is simple: put the core authority where OpenClaw always loads it.

Minimal example in AGENTS.md

## Program: Weekly Status Report

**Authority:** Compile metrics, generate summary, deliver internal report
**Trigger:** Every Friday at 4 PM via cron
**Approval gate:** No approval needed for internal delivery
**Escalation:** Ask for help if a source is missing or numbers look abnormal

### Execution Steps
1. Pull metrics from the configured sources
2. Compare against last week
3. Write the report to reports/weekly/YYYY-MM-DD.md
4. Send the summary to the configured destination
5. Log completion and any anomalies

### What NOT to Do
- Do not change source data
- Do not send anything to external contacts
- Do not hide bad results

The four parts of a good standing order

1. Scope

Be specific about what the agent owns. "Manage our content" is too vague. "Draft three LinkedIn post options, save them to drafts/, and send me the best one for approval" is usable.

2. Trigger

Some programs are time-based. Some are event-driven. Some run on heartbeat cycles. The important part is that the trigger is explicit, not implied.

3. Approval gate

Decide what the agent can do alone and what still needs a human. Internal summaries might be pre-approved. Public posts, money movement, or customer replies might not be.

4. Escalation rule

This is where trust is built. A strong standing order tells the agent when to stop. Missing data, unusual numbers, conflicting instructions, privacy-sensitive content, or repeated tool failure should all trigger escalation.

How to write standing orders that do not go off the rails

The fastest way to create bad automation is to give broad authority on day one. Start narrow. Let the agent prove itself on routine work, then widen the boundary later.

Good pattern

• One program per domain
• Clear deliverables
• Named approval boundaries
• Named escalation conditions
• Verification before reporting success

Bad pattern

• "Handle anything important"
• "Use your judgment" without limits
• No difference between internal and external actions
• No failure path
• No proof step after execution

The execute, verify, report loop

There is an old proverb, later popularized in English as "trust, but verify." That is exactly how standing orders should feel. Trust the agent with bounded authority. Verify what it did. Then report the result.

1. Execute: do the work, not just acknowledge it
2. Verify: confirm the file, message, output, or state change exists
3. Report: summarize what happened, what was checked, and what needs attention

This loop prevents the most common failure mode in AI automation: sounding done without actually being done.

Pairing standing orders with cron

Your cron prompt should point back to the standing order instead of duplicating the whole playbook. That keeps one source of truth and makes updates safer.

openclaw cron add   --name weekly-status-report   --cron "0 16 * * 5"   --tz Europe/Berlin   --timeout-seconds 300   --announce   --channel telegram   --to "your-chat-id"   --message "Execute the weekly status report per standing orders. Verify delivery. Escalate anomalies."

Notice what is missing: the full workflow. The cron job wakes the agent up. The standing order tells it how to behave.

Real programs that work well

Inbox triage

Great first use case. The scope is narrow, the output is easy to verify, and escalation rules are natural.

• Categorize incoming items
• Summarize important threads
• Flag unknown senders or urgent items
• Draft responses, but only send if approved

Weekly reporting

Another strong fit. Reporting is repetitive, structured, and benefits from consistency.

• Pull metrics from known sources
• Compare against prior periods
• Write summary to a predictable folder
• Deliver internal report automatically

Monitoring and alerts

Standing orders work well for checks that happen over and over. Think uptime checks, disk space, failed jobs, or stale queues.

• Restart low-risk services automatically
• Escalate repeated failures
• Log each action and verification step

Multi-program setups

Once you trust the pattern, split responsibility into separate programs instead of creating one giant automation blob. One for monitoring. One for reporting. One for publishing. One for inbox work.

That separation makes reviews easier, failures clearer, and approvals safer. It is the same logic as good software architecture: smaller boundaries are easier to reason about than one giant kitchen sink.

Common mistakes

• Too much authority too early: start with narrow internal tasks
• No escalation rules: every program needs a stop condition
• Duplicated logic in cron prompts: keep the standing order as the source of truth
• No verification: a claimed action is not a completed action
• Mixed concerns: separate content, finance, monitoring, and support into distinct programs

Best practices summary

• Put core standing orders in AGENTS.md
• Use cron or heartbeat triggers to enforce execution timing
• Write one program per domain or workflow
• Define approval gates for risky or external actions
• Escalate on uncertainty, anomalies, or repeated failures
• Always follow execute, verify, report

Standing orders are not about making your agent more reckless. They are about making it more useful. Give it a charter, not a shrug. Then let it earn trust the boring way: by doing routine work correctly, every time.