ClawKit Logo
ClawKitReliability Toolkit

Autonomous Agent Workflows

What "autonomous" actually means

Autonomous workflows run on schedule without human input — but they still need structure. The patterns here prevent the two most common failure modes: silent death (the cron runs but produces nothing) and goal drift (the agent does something, just not what you asked).

OpenClaw's cron system lets you schedule agents to run on a fixed schedule, hand off results between jobs, and coordinate research swarms. This guide covers the patterns that make scheduled workflows actually reliable.

Jump to Section

Daily Content Pipeline Research Swarm Pattern Silent Cron Death Prevention Goal Drift Prevention Productized Agent Services Monitoring & Alerting

Daily Content Pipeline

The most common autonomous workflow: fetch data on a schedule, process it, deliver output to a human-readable destination (Telegram, email, markdown file). The key constraint is that each job must run in an isolated session — otherwise the 6 AM scout job contaminates the 8 AM summary job with stale context.

Three-job daily content pipeline
# Step 1 — Scout: fetch and score raw inputs (6:00 AM)
name: content_scout
schedule: "0 6 * * *"
session: isolated
context_files:
  - project-state.md        # topic filters and scoring rubric
prompt: |
  Fetch RSS feeds from project-state.md.
  Score each item 1-10 for relevance. Write top 5 to daily-logs/scout-{date}.md.
model: claude-haiku-4-5     # fast, cheap; scoring is mechanical
output: daily-logs/scout-{date}.md

---

# Step 2 — Writer: draft from scout output (8:00 AM)
name: content_writer
schedule: "0 8 * * *"
session: isolated
context_files:
  - daily-logs/scout-{date}.md   # INPUT only — does not share scout's session
prompt: |
  Read scout-{date}.md. Write a 200-word newsletter blurb for each of the top 3 items.
  Save to daily-logs/drafts-{date}.md.
model: claude-sonnet-4-6        # better writing quality
output: daily-logs/drafts-{date}.md

---

# Step 3 — Publisher: send to Telegram (9:00 AM)
name: content_publisher
schedule: "0 9 * * *"
session: isolated
context_files:
  - daily-logs/drafts-{date}.md
prompt: |
  Read drafts-{date}.md. Send each blurb as a separate Telegram message.
  Log sent status to daily-logs/published-{date}.md.
model: claude-haiku-4-5
output: daily-logs/published-{date}.md

File handoff is the correct pattern. Each job reads the previous job's output as a declared context_files entry, not as shared session state. This makes the pipeline auditable: you can inspect each intermediate file to see exactly what each stage produced.

Research Swarm Pattern

A research swarm runs multiple isolated agents in parallel, each focused on a different subtopic, then merges their outputs into a single document. Use this when a research task is too broad for one context window, or when you want to parallelize across sources (Reddit, Google Scholar, GitHub, industry blogs) without one source contaminating another's analysis.

Parallel research swarm — 3 agents, 1 merge step
# Run all three scouts in parallel: openclaw run --parallel
# Each is an isolated session with its own context

# swarm-reddit.yaml
name: research_reddit
session: isolated
prompt: |
  Search Reddit r/LocalLLaMA and r/MachineLearning for posts this week
  mentioning OpenClaw, agent reliability, or memory management.
  Extract 3 most-cited pain points. Write to research/reddit-{date}.md.
model: claude-sonnet-4-6    # untrusted user content — mid-tier minimum

---

# swarm-github.yaml
name: research_github
session: isolated
prompt: |
  Fetch GitHub issues from the openclaw/openclaw repo opened this week.
  Categorize by: crash, performance, UX, feature-request.
  Write summary to research/github-{date}.md.
model: claude-sonnet-4-6

---

# swarm-merge.yaml — runs AFTER both scouts complete
name: research_merge
session: isolated
context_files:
  - research/reddit-{date}.md
  - research/github-{date}.md
prompt: |
  Merge the two research inputs into a single 1-page executive summary.
  Highlight overlapping themes. Save to research/summary-{date}.md.
model: claude-opus-4-6      # synthesis requires stronger reasoning

Silent Cron Death Prevention

Silent death is when a cron job runs on schedule, produces no output, and reports no error. The job "succeeded" from the scheduler's perspective — it ran without crashing — but no work was done. This happens when the agent misinterprets the prompt, runs a skill that returns empty data, or writes to a wrong file path. You only discover it a week later when you notice nothing was published.

Silent death checklist

  • • Every cron job must write a completion sentinel (last line: STATUS: done)
  • • A watchdog cron checks for the sentinel and alerts if missing
  • • Output files must have a minimum size threshold (e.g., >200 bytes)
  • • Never rely on exit code 0 alone — check the output file exists and is non-empty
Sentinel pattern — job writes status, watchdog checks it
# In every cron prompt, add this requirement:
# "The LAST line of your output file MUST be: STATUS: done"

# watchdog.yaml — runs 1 hour after publisher (9 AM)
name: watchdog
schedule: "0 10 * * *"
session: isolated
context_files: []
prompt: |
  Check that these files exist and contain "STATUS: done" on their last line:
    - daily-logs/scout-{date}.md
    - daily-logs/drafts-{date}.md
    - daily-logs/published-{date}.md

  If any file is missing or does not contain STATUS: done:
    1. Send a Telegram alert: "PIPELINE FAILURE: {filename} missing or incomplete"
    2. Write the failure to daily-logs/watchdog-{date}.md
    3. Do NOT attempt to re-run the failed job automatically

  If all files are healthy: write "PIPELINE OK" to daily-logs/watchdog-{date}.md.
model: claude-haiku-4-5    # mechanical check — cheap and fast

Goal Drift Prevention

Goal drift occurs when an agent gradually shifts its behavior away from the original objective — not through a single wrong decision, but through accumulated small deviations over multiple sessions. The agent does not break; it just optimizes for a subtly wrong target. Prevention requires periodic re-grounding against the original objective, not just against the last session's state.

Weekly drift audit — compares outputs against original goals
# drift-audit.yaml — every Monday 9 AM
name: drift_audit
schedule: "0 9 * * 1"
session: isolated
context_files:
  - project-state.md                    # original goals (never edited by agent)
  - daily-logs/published-2026-*.md      # all published content from past week
prompt: |
  Read project-state.md section "Content Goals" carefully.
  Then read all published-*.md files from the past 7 days.

  For each published piece, rate it 1-10 against each stated goal.
  Flag any piece that scores below 6 on any goal.
  Write your analysis to daily-logs/drift-audit-{date}.md.

  If more than 2 pieces scored below 6, send a Telegram alert:
  "DRIFT WARNING: Agent output diverging from goals — review drift-audit-{date}.md"

model: claude-opus-4-6    # strong reasoning for comparison task

Productized Agent Services

A productized agent service runs the same workflow repeatedly for multiple clients or projects, parameterized by a config file. Instead of one agent for your newsletter, you have one agent template and 10 config files — one per client. The agent reads its config on startup and behaves accordingly.

Parameterized agent config — one template, multiple clients
# clients/client-a.yaml
name: "TechStartup Weekly"
telegram_chat_id: "111222333"
rss_feeds:
  - https://techcrunch.com/feed/
  - https://news.ycombinator.com/rss
topics: ["AI", "SaaS", "developer tools"]
publish_time: "08:00"
tone: "concise, technical, no hype"

---

# clients/client-b.yaml
name: "Crypto Pulse"
telegram_chat_id: "444555666"
rss_feeds:
  - https://coindesk.com/arc/outboundfeeds/rss/
topics: ["DeFi", "Bitcoin", "regulation"]
publish_time: "07:00"
tone: "neutral, data-focused"

---

# The agent prompt reads its client config on startup:
# "Read your client config from clients/{CLIENT_NAME}.yaml.
#  All decisions about topics, tone, and delivery must follow that config."

# Run both clients in parallel:
openclaw run --cron scout --env CLIENT_NAME=client-a &
openclaw run --cron scout --env CLIENT_NAME=client-b &

Monitoring & Alerting

For autonomous workflows that run unattended, your monitoring strategy should be: assume failure, verify success. Check for positive evidence of completion (output file exists, sentinel present, file size above threshold) rather than absence of errors.

Full monitoring stack for a daily pipeline
# 1. Per-job sentinel (each job writes "STATUS: done" as its last line)
# 2. Daily watchdog — checks all sentinels, alerts on Telegram if any fail
# 3. Weekly drift audit — checks output quality, flags systematic goal drift

# 4. Log retention — auto-archive old logs (Sunday 3 AM)
name: log_archive
schedule: "0 3 * * 0"
session: isolated
prompt: |
  Move all files in daily-logs/ older than 7 days to archive/daily-logs/.
  Create archive/ if it does not exist.
  Write "Archived {count} files" to daily-logs/archive-log-{date}.md.
  STATUS: done
model: claude-haiku-4-5

---

# 5. Health summary — weekly status report (Monday 10 AM)
name: health_report
schedule: "0 10 * * 1"
session: isolated
context_files:
  - daily-logs/watchdog-*.md
  - daily-logs/drift-audit-*.md
prompt: |
  Summarize pipeline health for the past week:
  - How many days had watchdog failures?
  - Were any drift warnings sent?
  - What was the average output quality score?
  Send a Telegram message with the weekly health summary.
model: claude-sonnet-4-6

Related Guides

Autonomous workflows depend on these systems:

Production Agent Patterns

SOUL.md, model routing, heartbeat — the 6 core patterns

Apify + OpenClaw

Add web scraping to your autonomous pipeline

Agent Memory & Context

How OpenClaw manages context windows across long sessions

Sub-Agent Session Errors

Troubleshoot cron session isolation failures

Did this guide solve your problem?

Need Help?

Try our automated tools to solve common issues instantly.

Run Local DoctorConfig Wizard