Pick the Right Trigger
Cron
Use cron when the task belongs to a clock: daily reports, backups, publishing checks, ranking snapshots, invoice reminders, or weekly summaries.
- Best for predictable cadence.
- Keep prompts short and task-specific.
- Prefer isolated sessions for repeatable output.
Webhook
Use webhooks when the task belongs to an external event: a form submission, GitHub issue, payment, calendar update, lead capture, or CMS publish event.
- Validate the sender before invoking the agent.
- Store the raw event id for dedupe.
- Return fast, then process in the background.
Heartbeat
Use heartbeats when the task is opportunistic: inbox triage, quiet monitoring, light project checks, reminders, or asking whether anything needs attention.
- Batch several checks into one pass.
- Let timing drift unless precision matters.
- Reply only when there is a useful signal.
Write a Task Contract
Every background agent needs a narrow contract
A background task should say exactly what it can read, what it can change, when it should notify a human, and what counts as done. Vague prompts are fine for chat. They are risky for unattended work.
Task: check new website leads once per hour.
Read: lead inbox, CRM notes, public prospect website.
Write: append CRM note and draft outreach only.
Notify: urgent if budget signal, broken form, or hot lead.
Do not: send email, edit the website, or contact the prospect.
Finish with: lead count, qualified leads, draft links, blockers.Separate read, draft, and act phases
The simplest safety upgrade is to split jobs into phases. Let the agent gather evidence and prepare the change automatically. Gate the public or irreversible action behind approval.
- Read: inspect inputs, pull status, gather context, summarize evidence.
- Draft: create the proposed file, message, issue comment, content section, or deployment note.
- Act: send, publish, deploy, delete, migrate, spend, or modify production data only when the rules allow it.
Control Context and Cost
Background runs should not inherit the whole world by default
Recent OpenClaw community discussion keeps circling the same production pain: cron and child sessions can become expensive or confusing when they inherit too much toolbox, transcript, or project context. Give each recurring task only the context it actually needs.
- Use a dedicated task prompt instead of a giant general instruction.
- Pass exact files, URLs, IDs, or project notes instead of broad workspace access.
- Prefer summaries and state files for recurring memory.
- Make the model choice explicit for cheap checks versus high-risk reasoning.
Keep a small state file
State turns a repeated task from "start over again" into "continue from the last known checkpoint". It also makes failures easier to audit.
{
"lastRun": "2026-07-04T04:00:00Z",
"lastEventId": "evt_12345",
"lastSuccess": "2026-07-04T04:00:18Z",
"consecutiveFailures": 0,
"lastHumanNotification": "2026-07-03T23:12:00Z"
}Add Approval Gates
Gate the consequence, not the research
Do not make a human approve every harmless lookup. That kills the point of agents. Gate the point where the result leaves the machine, touches production, spends money, or changes customer-visible data.
Usually automatic
- Status checks
- Read-only reports
- Draft creation
- Local file analysis
Usually approval-gated
- Email sends and public posts
- Production deploys
- Deletes and migrations
- Credential or access changes
Design Failure Handling
A failed tool call should create a recovery path
Current agent operations work is paying more attention to retry behavior, persistent session state, stderr handling, and tool failures. Treat tool failure as a normal state, not a surprise.
- Retry once for transient network, provider, or channel errors.
- Fallback to a read-only summary when the write path fails.
- Stop on authentication, permission, schema, or destructive-action uncertainty.
- Notify only when human action can actually unblock the task.
Use a dead-letter note for stuck work
If a task fails repeatedly, write the input, error, attempted fixes, and next manual step to a known place. That is faster than hunting through logs after the user notices the missing result.
Starter Blueprint
Safe daily content task
This pattern fits research, changelog, SEO, or documentation work where the agent can draft and commit, but public communications still need a clear report.
Trigger: cron, daily at 14:00 Australia/Brisbane.
Context: site repo, previous daily note, official release/source URLs.
Steps:
1. Check current repo status.
2. Research official updates and community issue themes.
3. Improve one page or add one focused guide.
4. Run build, parser, XML, diff, and HTTP smoke checks.
5. Commit and push only the scoped site changes.
6. Report the exact page, sources, and verification.Operator checklist before increasing autonomy
Someone knows which human is accountable for the task.
The task has a clear cron, webhook, heartbeat, or manual start path.
Last run, last event, and last success are visible.
The agent knows exactly when to stop and ask.
Failures leave enough evidence for a human or later agent to resume.
Source Notes
This guide reflects the July 2026 OpenClaw release stream, including v2026.7.1-beta.1, ongoing work around CLI onboarding proof, voice-call persisted state, Telegram progress callbacks, MCP stdio transport errors, supervisor stream errors, session compaction locks, and open discussion around tool-failure fallback and retry behavior.
It also follows the broader AI-agent trend toward orchestrated workflows with traceability, approval ownership, context isolation, and production recovery instead of unbounded autonomous action.
Sources: OpenClaw releases • Tool-failure fallback issue • CLI channel picker proof PR • Voice-call persisted state PR