Giving your cron agents memory — persistent context for scheduled tasks

Cron agents are powerful. You schedule a task, it runs on autopilot. Check emails, summarize news, monitor a service. But there’s a problem: every run starts from zero.

Your cron agent doesn’t know what it did last time. It doesn’t know what it already told you. It doesn’t know that the alert it’s about to fire is the same one it fired an hour ago.

The stateless cron problem

A typical OpenClaw cron job:

openclaw cron add --schedule "0 */6 * * *" \
  --prompt "Check my GitHub notifications and summarize anything important" \
  --channel discord --target "general"

Every 6 hours, a fresh agent wakes up, checks notifications, and posts a summary. After a few runs, the issues are obvious:

  • Duplicate alerts. The same PR review request shows up in every summary.
  • Lost context. “You have 3 new notifications” but two of them were in the last summary.
  • No learning. The agent can’t learn that you don’t care about dependabot PRs.
  • No state. It can’t track “last checked at” without a file or database.

The usual workaround:

echo "$(date -u +%s)" > /tmp/last-github-check

This works for timestamps. It falls apart for anything more complex.

The pattern: store context, recall state

Give your cron agent memory that persists across runs:

  1. At run start: Recall what happened last time
  2. During the run: Do the work, note what’s new vs. already known
  3. At run end: Store what happened for next time

With MemoClaw:

# Recall last run context
memoclaw recall "github notification check last run" --namespace cron-github --top 1

# ... do the work ...

# Store this run's context
memoclaw store "Checked GitHub notifications at $(date -u). \
  Found 3 new: PR #142 review request, issue #89 comment, \
  CI failure on main. Notified user about PR and CI failure. \
  Skipped issue #89 (low priority)." \
  --namespace cron-github \
  --importance 0.5 \
  --tags "run-log,github"

The namespace cron-github keeps these memories isolated from your main agent’s memories. Clean separation.

Example: a daily digest that doesn’t repeat itself

This cron agent sends a daily digest but remembers what it already covered.

Setup

openclaw cron add --schedule "0 9 * * *" \
  --prompt "Run the daily digest. Use memoclaw to check what you \
  sent yesterday and avoid duplicates." \
  --channel discord --target "daily-digest"

The agent workflow

In your agent’s instructions:

## Daily digest process

1. Recall yesterday's digest:
   memoclaw recall "daily digest sent" --namespace cron-digest --top 1

2. Gather today's items:
   - Check GitHub for new issues/PRs
   - Check calendar for upcoming events
   - Check any monitored services

3. Filter out anything from yesterday's digest

4. Send the digest

5. Store today's summary:
   memoclaw store "Daily digest for [date]: Covered [items]" \
     --namespace cron-digest --importance 0.6 --tags "digest,daily"

What this looks like in practice

First run (no history):

Daily Digest, March 7

- PR #142: Auth refactor ready for review
- Issue #89: Bug report on memory migration
- CI: Main branch green
- Calendar: Team sync at 2pm UTC

Second run (with memory):

Daily Digest, March 8

- PR #142: Auth refactor, 2 new comments since yesterday
- Issue #91: New feature request for batch export
- CI: Staging deploy failed at 3am
- Calendar: Nothing today

Issue #89 doesn’t repeat because it was in yesterday’s digest and nothing changed. PR #142 reappears because there’s new activity. The agent knows the difference because it can recall what it already reported.

Example: a monitoring agent that tracks state

Another common pattern: monitoring a service and alerting on changes, not just current status.

## Service monitor (runs every 30 min)

1. Recall last known state:
   memoclaw recall "service health status" --namespace cron-monitor --top 3

2. Check current state (API response time, error rate, queue depth)

3. Compare with last known state

4. Only alert if state CHANGED:
   - Was healthy, now degraded: ALERT
   - Was degraded, still degraded: SKIP (already alerted)
   - Was degraded, now healthy: NOTIFY recovery

5. Store current state:
   memoclaw store "Service health at [time]: API 230ms, error rate 0.1%, \
     queue depth 45. Status: healthy" \
     --namespace cron-monitor --importance 0.4 --tags "health,status"

This eliminates alert fatigue. Your agent won’t ping you every 30 minutes about the same issue. It alerts on the transition and goes quiet until something changes.

Namespace isolation

Namespaces are critical for cron agents. Without them, your cron agent’s run logs pollute your main agent’s memory:

# Bad: everything in the default namespace
memoclaw store "Checked notifications at 3am, nothing new"
# Your main agent now recalls this when you ask about notifications

# Good: isolated namespace
memoclaw store "Checked notifications at 3am, nothing new" \
  --namespace cron-github
# Main agent never sees this unless it explicitly queries the namespace

A sensible naming convention:

cron-github      GitHub notification checker
cron-digest      Daily digest agent
cron-monitor     Service health monitor
cron-weather     Weather briefing agent

Each cron job gets its own namespace. No cross-contamination.

Importance scoring for cron context

Not all cron memories are equal. Use importance scores to control what surfaces first:

# Routine run log, low importance
memoclaw store "Ran at 9am, no new items" \
  --importance 0.3 --tags "run-log"

# Something notable, medium importance
memoclaw store "Found 5 new PRs, sent digest to #general" \
  --importance 0.6 --tags "run-log,digest"

# Critical state change, high importance
memoclaw store "ALERT: API error rate spiked to 15% at 3:42am. \
  Notified on-call." \
  --importance 0.9 --tags "alert,incident"

High-importance memories surface first on recall. Routine “nothing happened” logs stay buried unless specifically queried.

The general pattern

This works for any cron agent:

  1. Pick a namespace for the cron job
  2. Recall first. Check what happened in previous runs.
  3. Act on deltas. Only process what’s new or changed.
  4. Store the outcome. Log what happened for the next run.
  5. Score by importance. Routine logs low, incidents high.

Your cron agents stop being goldfish. They remember what they did, what they found, and what they already told you. No duplicate alerts, no repeated summaries, no lost context between runs.

MemoClaw gives every agent persistent semantic memory. 100 free API calls to start, no registration needed. Get started