OpenClaw standing orders are the part of agent automation that decides what your agent is allowed to own. Not what time it runs. Not where state is stored. Not whether a child task is still active. Standing orders are the operating contract: “This program belongs to you, these are the limits, here is when you must ask me.”
That sounds formal because it should be formal. A self-hosted agent that can run tools, read workspace files, send messages, publish drafts, or touch production systems needs more than a recurring prompt. It needs written authority with boundaries.
The official OpenClaw docs define standing orders as permanent operating authority for defined programs. Instead of prompting the agent for every routine task, you describe the program once with scope, triggers, approval gates, and escalation rules. The agent then executes inside those lines and reports back when the work is done or when something falls outside the contract.
This is the right mental model: standing orders are not memory. They are not cron jobs. They are not a workflow engine. They are the rulebook the agent reads before it acts.
What OpenClaw standing orders are
A standing order is a durable instruction for a recurring or ongoing program. “You own the weekly report” is a standing order only if it also says what the agent can pull, who gets the report, what needs approval, and when the agent must stop.
The OpenClaw docs give the simple version: without standing orders, the owner prompts the agent for every task and becomes the bottleneck. With standing orders, the agent handles routine work on its own and escalates exceptions.
That is the attraction. It is also the risk. If the order is vague, the agent may fill gaps with guesses. If the order is too broad, a small routine task can turn into accidental authority. A good standing order is narrow enough that the agent knows exactly what it owns and exactly what it must not touch.
For example, this is weak:
Handle my blog every morning.This is useful:
Program: Daily docs blog draft
Authority: Pick the first unchecked docs topic, research it, write the post, generate a hero image, and publish to WordPress as draft only.
Trigger: 7 AM daily automation.
Approval gate: Never publish live. Boss reviews every draft.
Escalation: Stop if credentials fail, source docs are unavailable, or the topic has already been published.The second version gives the agent room to execute without turning it loose. It names the program, sets the trigger, draws a hard approval gate, and says when to stop.
Why standing orders are different from memory
Agent memory answers a different question: what should the agent remember? Standing orders answer: what is the agent authorized to do?
That difference matters in OpenClaw because workspace memory, session history, and bootstrap files can all affect an agent’s context. A memory note might say the owner likes image-rich blog posts. A standing order says the blog agent must generate a featured image before publishing a draft. One is preference. The other is an execution rule.
Do not hide authority inside casual memory. Put authority where the agent is meant to see it every time and where you can review it like an operations document.
The agent workspace docs describe the workspace as the agent’s home and default working directory. OpenClaw bootstrap files such as `AGENTS.md`, `SOUL.md`, `IDENTITY.md`, `USER.md`, and `MEMORY.md` can be loaded into sessions. The standing-orders docs recommend putting orders directly in `AGENTS.md` because that file is injected every session. For larger setups, you can use a dedicated `standing-orders.md`, then reference it from `AGENTS.md` so it is not forgotten.
That last part is easy to miss. An arbitrary file sitting in a subdirectory is not useful just because it exists. If the agent does not reliably load it, the order becomes a note to yourself.
The four parts every standing order needs
The OpenClaw docs list four fields for each program: scope, triggers, approval gates, and escalation rules. Treat those as required, not decoration.
Scope
Scope says what the agent can do. Keep it concrete. “Monitor operations” is too broad. “Check the three service health endpoints, restart the local worker if one fails, and report the result” is better.
Scope should also say what data sources, files, tools, or accounts the agent may use. If a program needs Gmail, WordPress, a local repo, or a cloud account, name it. If it must never touch live production, say that too.
Triggers
Triggers say when the program runs. A trigger can be a schedule, an event, or a condition. In OpenClaw, exact schedules usually belong to automations. Event reactions may use hooks or webhooks. The standing order still needs to name the trigger so the agent knows why it woke up and which program applies.
A useful automation prompt references the standing order instead of repeating the whole program. That keeps the schedule small and the authority in one place.
Approval gates
Approval gates say what the agent cannot do alone. This is where you protect high-risk actions: publishing live, spending money, deleting data, contacting external customers, changing production config, or sending messages from a personal account.
Good approval gates are blunt. “Ask before major changes” is weak. “Draft WordPress posts only; live publish requires Boss to confirm the exact title” is much harder to misread.
Escalation rules
Escalation rules say when the agent should stop and ask for help. The best ones are specific: data source unavailable, credential failure, duplicate topic, cost above threshold, anomaly outside a defined range, or three failed retries.
Escalation is not failure. It is how the program avoids pretending everything is fine when the facts changed.
Where to put standing orders in OpenClaw
The default answer is `AGENTS.md`. The standing-orders docs recommend it because OpenClaw injects that file every session. If the order is short, put it there directly. If the order is long, put a clear pointer in `AGENTS.md` and store the full details in a dedicated file.
Use direct language. Standing orders are not the place for brand fluff or vague aspirations. Write them like an operator will debug them later.
## Program: Draft-only WordPress publishing
Authority:
- Research, write, humanize, generate images, upload media, and create WordPress drafts.
- Use author Afzal Malik.
- Set Yoast title, focus keyword, and meta description.
Trigger:
- Scheduled docs-blog automation at 7 AM.
- Direct owner request for a blog draft.
Approval gate:
- Always use status=draft.
- Never publish live unless Boss explicitly confirms the exact post.
Escalation:
- Stop if WordPress auth fails.
- Stop if the source URL cannot be fetched.
- Stop if the topic is already marked published.
- Report any image-generation failure instead of silently shipping a text-only draft.That example is not pretty, and that is fine. A standing order should be easy to audit, not pleasant to frame.
There is one exception worth noting. The standing-orders docs say `openclaw agent exec` skips workspace bootstrap files. That makes it useful for strict one-shot CI or scripting entry points where each run should be self-contained. If you expect standing orders to govern a run, do not assume an `agent exec` entry point loaded them. Pass the required instructions explicitly.
Standing orders plus automations
The clean split is simple: standing orders define what the agent is allowed to do, and automations define when it happens.
OpenClaw automations are Gateway-owned scheduled jobs. The automations docs say the scheduler persists jobs, wakes the agent at the right time, and can deliver output to a chat channel, a webhook, or nowhere. Jobs can be one-shot, interval-based, cron-based, stream-triggered, or event-triggered. Automation runs create background task records.
A standing order by itself does not run. It is authority waiting for a trigger. An automation without a standing order can run, but it may rely on a giant prompt that drifts over time. Put them together and the design is easier to maintain.
Standing order:
You own daily inbox triage. Classify alerts, persist each item, and escalate unknown senders.
Automation:
Run every weekday at 8 AM. Message: "Execute daily inbox triage per standing orders."This avoids a common maintenance trap. If you later change the triage policy, you edit the standing order once. You do not hunt through every schedule, webhook, and reminder that pasted an older copy of the same rules.
A practical template for your first standing order
Start with one narrow program. Pick something routine, bounded, and easy to verify. A weekly report is better than “manage my business.” A draft-only blog run is better than “handle content.”
## Program: [Name]
Purpose:
- [One sentence explaining the job.]
Authority:
- [What the agent may do.]
- [Which files, tools, accounts, or APIs it may use.]
Trigger:
- [Schedule, event, or condition.]
- [Which automation, hook, webhook, or owner request starts it.]
Approval gates:
- [Actions that need human approval.]
- [Exact wording for hard rules, such as draft-only or no external sends.]
Escalation:
- [Credential failure.]
- [Missing or stale source data.]
- [Unexpected cost, anomaly, duplicate, or unclear instruction.]
- [Retry limit.]
Execution steps:
1. [Do the work.]
2. [Verify the output.]
3. [Report what was done and what was verified.]
What not to do:
- [Forbidden action.]
- [Forbidden destination.]
- [Forbidden assumption.]
Log:
- [Where completion, links, ids, or notes should be recorded.]The “what not to do” section is not negative thinking. It is part of the authority model. Agents are useful because they can act without you typing every step. That same quality makes boundaries important.
How standing orders fit with Task Flow, hooks, and background tasks
OpenClaw has several automation surfaces because they solve different jobs. The automation overview is clear about the split:
- Automations handle precise schedules and one-shot reminders.
- Heartbeat handles approximate periodic checks in the main session.
- Hooks react to lifecycle and message events.
- Standing orders give persistent instructions and authority boundaries.
- Task Flow coordinates multi-step flows above individual tasks.
- Background tasks track detached work so it can be inspected and audited.
Use standing orders when the question is “May the agent do this?” Use automations when the question is “When should it run?” Use hooks when the question is “What should happen when this event fires?” Use Task Flow when the question is “Where is this multi-step run right now?” Use background tasks when the question is “What detached work ran, and how did it end?”
This separation is not unique to OpenClaw. LangGraph separates short-term thread checkpoints from long-term stores. Inngest presents durable step functions for event-driven and scheduled work. Prefect tracks flow runs with states, retries, timeouts, schedules, and deployments. The pattern is the same: long-running automation needs state, triggers, authority, and observability to be different things.
OpenClaw’s version is tailored to self-hosted agents. The workspace files carry the operating rules. The Gateway scheduler wakes the agent. Task and flow records show what happened. The owner can review the run without pretending the chat transcript is a reliable database.
Common standing-order mistakes
Writing a wish instead of an order
“Keep me updated on important things” is not a standing order. It has no scope, no trigger, no approval gate, and no escalation rule. The agent has to guess what matters.
Making the first order too broad
Start small. Give the agent one program. Let it run. Review the logs. Expand after the boring version works.
Forgetting approval gates
If a program can send, publish, delete, spend, or modify production, write the approval gate in plain language. Do not rely on the agent to infer risk from context.
Putting the only copy in a file that is not loaded
If the agent never sees the order, it is not an order. Put it in `AGENTS.md` or reference it from there.
Duplicating the full policy inside every automation
That creates drift. Use the automation to trigger the work. Keep the authority in the standing order.
Skipping verification
A standing order should require the agent to execute, verify, and report. “Done” is not enough. For a blog post, verification might include word count, draft status, edit link, image upload id, and humanizer score. For monitoring, it might include endpoint status and restart outcome.
FAQ about OpenClaw standing orders
Are OpenClaw standing orders the same as cron jobs?
No. Cron-style automations decide when a run starts. Standing orders define what the agent is authorized to do during that run.
Should standing orders live in memory?
No. Memory can record preferences and past decisions, but authority should live in a bootstrap file the agent reliably loads, usually `AGENTS.md`.
Can a standing order publish content live?
Only if the owner explicitly grants that authority. For most content workflows, draft-only is the safer default. Put the live-publish rule behind a clear approval gate.
When should I use Task Flow with standing orders?
Use Task Flow when the standing-order program has multiple steps, waits, child tasks, retries, or a status you need to inspect later. A simple one-shot reminder does not need a flow.
Do hooks replace standing orders?
No. Hooks react to events. Standing orders define authority. A hook can start work, but the standing order should still say what the agent may do and when it must stop.
How often should I review standing orders?
Review them after the first few runs, then on a regular schedule. Weekly is sensible for active programs. Look for unclear escalations, missing approval gates, and repeated manual fixes.
Start with one boring program
The best standing order is not the one that sounds most autonomous. It is the one you can trust at 7 AM when you are not watching.
Pick one routine workflow. Write the scope, trigger, approval gates, escalation rules, execution steps, and “what not to do” list. Pair it with an automation only after the authority is clear. Then inspect the first few runs and tighten the wording where the agent hesitated or guessed.
That is how OpenClaw standing orders become useful: not as magic, but as operating discipline for agents that are finally allowed to do real work.
