Standing orders grant your agent permanent operating authority for defined programs. Instead of prompting the agent for each task, you define programs with clear scope, triggers, and escalation rules, and the agent executes autonomously within those boundaries: “You own the weekly report. Compile it every Friday, send it, and only escalate if something looks wrong.”
Why standing orders
Without standing orders: you prompt the agent for every task, routine work gets forgotten or delayed, and you become the bottleneck.
With standing orders: the agent executes autonomously within defined boundaries, routine work happens on schedule, and you only get involved for exceptions and approvals.
How they work
Standing orders are defined in your agent workspace files. The recommended approach is to include them directly in AGENTS.md (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 and reference it from AGENTS.md.
Each program specifies:
- Scope - what the agent is authorized to do
- Triggers - when to execute (schedule, event, or condition)
- Approval gates - what requires human sign-off before acting
- Escalation rules - when to stop and ask for help
The agent loads these instructions every session via the workspace bootstrap files (see Agent Workspace for the full list of auto-injected files) and executes against them, combined with cron jobs for time-based enforcement.
Put standing orders in AGENTS.md to guarantee they’re loaded every session. The workspace bootstrap automatically injects AGENTS.md, SOUL.md, TOOLS.md, IDENTITY.md, USER.md, HEARTBEAT.md, BOOTSTRAP.md, and MEMORY.md - but not arbitrary files in subdirectories.
Anatomy of a standing order
Standing orders plus cron jobs
Standing orders define what the agent is authorized to do. Cron jobs define when it happens. They work together:
The cron job prompt should reference the standing order rather than duplicating it:
Examples
Example 1: content and social media (weekly cycle)
Example 2: finance operations (event-triggered)
Example 3: monitoring and alerts (continuous)
Execute-verify-report pattern
Standing orders work best when combined with strict execution discipline. Every task in a standing order should follow this loop:
- Execute - Do the actual work (don’t just acknowledge the instruction)
- Verify - Confirm the result is correct (file exists, message delivered, data parsed)
- Report - Tell the owner what was done and what was verified
This pattern prevents the most common agent failure mode: acknowledging a task without completing it.
Multi-program architecture
For agents managing multiple concerns, organize standing orders as separate programs with clear boundaries:
Each program should have:
- Its own trigger cadence (weekly, monthly, event-driven, continuous)
- Its own approval gates (some programs need more oversight than others)
- Clear boundaries (the agent should know where one program ends and another begins)
Best practices
- Start with narrow authority and expand as trust builds
- Define explicit approval gates for high-risk actions
- Include “What NOT to do” sections - boundaries matter as much as permissions
- Combine with cron jobs for reliable time-based execution
- Review agent logs weekly to verify standing orders are being followed
- Update standing orders as your needs evolve - they’re living documents
Avoid
- Grant broad authority on day one (“do whatever you think is best”)
- Skip escalation rules - every program needs a “when to stop and ask” clause
- Assume the agent will remember verbal instructions - put everything in the file
- Mix concerns in a single program - separate programs for separate domains
- Forget to enforce with cron jobs - standing orders without triggers become suggestions
- Automation: all automation mechanisms at a glance.
- Cron jobs: schedule enforcement for standing orders.
- Hooks: event-driven scripts for agent lifecycle events.
- Webhooks: inbound HTTP event triggers.
- Agent workspace: where standing orders live, including the full list of auto-injected bootstrap files (
AGENTS.md, SOUL.md, etc.).
