Standing orders grant your agent permanent operating authority<\/strong> for defined programs. Instead of giving individual task instructions each time, you define programs with clear scope, triggers, and escalation rules \u2014 and the agent executes autonomously within those boundaries.<\/p>\n This is the difference between telling your assistant “send the weekly report” every Friday vs. granting standing authority: “You own the weekly report. Compile it every Friday, send it, and only escalate if something looks wrong.”<\/p>\n Without standing orders:<\/strong><\/p>\n With standing orders:<\/strong><\/p>\n Standing orders are defined in your agent workspace<\/a> files. The recommended approach is to include them directly in Each program specifies:<\/p>\n The agent loads these instructions every session via the workspace bootstrap files (see Agent Workspace<\/a> for the full list of auto-injected files) and executes against them, combined with cron jobs<\/a> for time-based enforcement.<\/p>\n \n Put standing orders in “`markdown theme={“theme”:{“light”:”min-light”,”dark”:”min-dark”}}<\/p>\n Authority:<\/strong> Compile data, generate report, deliver to stakeholders Standing Order: “You own the daily inbox triage” “`markdown theme={“theme”:{“light”:”min-light”,”dark”:”min-dark”}}<\/p>\n Authority:<\/strong> Draft content, schedule posts, compile engagement reports “`markdown theme={“theme”:{“light”:”min-light”,”dark”:”min-dark”}}<\/p>\n Authority:<\/strong> Check system health, restart services, send alertsWhy Standing Orders?<\/h2>\n
\n
\n
How They Work<\/h2>\n
AGENTS.md<\/code> (which is auto-injected every session) so the agent always has them in context. For larger configurations, you can also place them in a dedicated file like standing-orders.md<\/code> and reference it from AGENTS.md<\/code>.<\/p>\n\n
AGENTS.md<\/code> to guarantee they’re loaded every session. The workspace bootstrap automatically injects AGENTS.md<\/code>, SOUL.md<\/code>, TOOLS.md<\/code>, IDENTITY.md<\/code>, USER.md<\/code>, HEARTBEAT.md<\/code>, and MEMORY.md<\/code> \u2014 but not arbitrary files in subdirectories.\n<\/p>\nAnatomy of a Standing Order<\/h2>\n
Program: Weekly Status Report<\/h2>\n
\nTrigger:<\/strong> Every Friday at 4 PM (enforced via cron job)
\nApproval gate:<\/strong> None for standard reports. Flag anomalies for human review.
\nEscalation:<\/strong> If data source is unavailable or metrics look unusual (>2\u03c3 from norm)<\/p>\nExecution Steps<\/h3>\n
\n
What NOT to Do<\/h3>\n
\n
\n## Standing Orders + Cron Jobs\n\nStanding orders define **what** the agent is authorized to do. [Cron jobs](\/automation\/cron-jobs) define **when** it happens. They work together:\n\n<\/code><\/pre>\n
\n \u2193
\nCron Job (8 AM daily): “Execute inbox triage per standing orders”
\n \u2193
\nAgent: Reads standing orders \u2192 executes steps \u2192 reports results<\/p>\n\nThe cron job prompt should reference the standing order rather than duplicating it:\n\n```bash theme={"theme":{"light":"min-light","dark":"min-dark"}}\nopenclaw cron create \n --name daily-inbox-triage \n --cron "0 8 * * 1-5" \n --tz America\/New_York \n --timeout-seconds 300 \n --announce \n --channel bluebubbles \n --to "+1XXXXXXXXXX" \n --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."\n<\/code><\/pre>\nExamples<\/h2>\n
Example 1: Content & Social Media (Weekly Cycle)<\/h3>\n
Program: Content & Social Media<\/h2>\n
\nApproval gate:<\/strong> All posts require owner review for first 30 days, then standing approval
\nTrigger:<\/strong> Weekly cycle (Monday review \u2192 mid-week drafts \u2192 Friday brief)<\/p>\nWeekly Cycle<\/h3>\n
\n
Content Rules<\/h3>\n
\n
\n### Example 2: Finance Operations (Event-Triggered)\n\n```markdown theme={"theme":{"light":"min-light","dark":"min-dark"}}\n## Program: Financial Processing\n\n**Authority:** Process transaction data, generate reports, send summaries\n**Approval gate:** None for analysis. Recommendations require owner approval.\n**Trigger:** New data file detected OR scheduled monthly cycle\n\n### When New Data Arrives\n\n1. Detect new file in designated input directory\n2. Parse and categorize all transactions\n3. Compare against budget targets\n4. Flag: unusual items, threshold breaches, new recurring charges\n5. Generate report in designated output directory\n6. Deliver summary to owner via configured channel\n\n### Escalation Rules\n\n- Single item > $500: immediate alert\n- Category > budget by 20%: flag in report\n- Unrecognizable transaction: ask owner for categorization\n- Failed processing after 2 retries: report failure, do not guess\n<\/code><\/pre>\nExample 3: Monitoring & Alerts (Continuous)<\/h3>\n
Program: System Monitoring<\/h2>\n
\nApproval gate:<\/strong> Restart services automatically. Escalate if restart fails twice.
\nTrigger:<\/strong> Every heartbeat cycle<\/p>\nChecks<\/h3>\n
\n
Response Matrix<\/h3>\n