Every OpenClaw cron job starts with a blank slate. Your agent wakes up, does its thing, and vanishes. Tomorrow it does it again with zero memory of what happened before.

That’s fine for simple tasks. But the moment you want an agent that tracks progress, notices trends, or builds on yesterday’s work, you hit a wall. The agent doesn’t remember yesterday.

Here’s how to fix that with MemoClaw.

The problem with stateless cron jobs

OpenClaw’s cron system spins up a fresh session each run. No chat history, no context, no memory. Your agent’s SOUL.md and workspace files carry over, but anything it learned during the previous run is gone.

The common workaround is writing to files. Append to a markdown file, read it back next session. It works until it doesn’t. The file grows, eats context window, and your agent spends half its tokens reading its own journal instead of doing actual work.

MemoClaw gives you a different approach: store what matters as memories with semantic search. Next run, recall only what’s relevant. Your context window stays clean.

The pattern: recall, act, store

Every cron agent that uses MemoClaw follows the same three-step flow:

1. Recall - Pull relevant memories at the start of the run
2. Act - Do the actual work, informed by what you recalled
3. Store - Save what happened so the next run has context

That’s it. Let’s build a real example.

Example: a daily standup agent

Say you want an agent that runs every morning at 9 AM, checks your GitHub repos for activity, and posts a standup summary to Discord. You want it to know what happened yesterday so it can say things like “PR #42 was still open yesterday, now it’s merged” instead of just listing today’s state.

Setting up the cron job

openclaw cron add \
  --schedule "0 9 * * *" \
  --label "daily-standup" \
  --prompt "Run the daily standup routine"

The agent’s instructions (in SOUL.md or the prompt)

Here’s what the agent does each run. I’ll break it down step by step.

Step 1: Recall yesterday’s context

memoclaw recall "yesterday's standup summary and open items" \
  --namespace standup \
  --top-k 3

This pulls the three most semantically relevant memories from the standup namespace. If yesterday’s agent stored a summary, it’ll come back here. The agent doesn’t need to know the exact date or key. Semantic search handles that.

Step 2: Do the work

The agent checks GitHub, gathers the data, and compares it against what it recalled. It can now say things like:

“Yesterday we had 3 open PRs. Two merged overnight (#42, #45). One is still waiting on review (#48). New issue filed: #51, bug in the auth flow.”

Instead of just:

“There’s 1 open PR and 1 new issue.”

Context makes the difference between a useful update and a dumb list.

Step 3: Store today’s summary

memoclaw store \
  --text "Standup 2026-03-07: 1 PR open (#48, waiting review). 2 PRs merged (#42, #45). New issue #51 (auth bug). Sprint velocity on track." \
  --namespace standup \
  --importance 0.7 \
  --tags "standup,daily,2026-03-07"

The importance score of 0.7 keeps it above casual notes but below critical corrections. Tags let you filter later if you need to.

Tomorrow’s run will recall this and have full context.

Namespace isolation keeps things clean

Here’s where namespaces earn their keep. If you’re running multiple cron jobs (standup, deployment monitor, weekly report), you don’t want them polluting each other’s recall results.

# Standup agent uses its own namespace
memoclaw recall "recent activity" --namespace standup

# Deploy monitor uses a different one
memoclaw recall "recent deployments" --namespace deploy-monitor

# Weekly report can pull from both when needed
memoclaw recall "week summary" --namespace standup
memoclaw recall "deployment issues this week" --namespace deploy-monitor

Each namespace is its own bucket. Recall only searches within the namespace you specify. The weekly report agent can deliberately reach into multiple namespaces to aggregate, but the daily agents stay in their lane.

What to store (and what not to)

Not everything deserves to be a memory. Store:

• Summaries, not raw data. “3 PRs merged, 1 open” beats dumping the full GitHub API response.
• Decisions and outcomes. “Decided to skip deploying Friday due to the auth bug” is worth remembering.
• State changes. “PR #48 moved from draft to review” gives the next run something to compare against.

Skip:

• Timestamps you can get from the source system anyway
• Anything longer than a paragraph (remember the 8192 char limit)
• Sensitive data like tokens or credentials. MemoClaw isn’t a secrets manager.

Importance scores matter for cron agents

When your agent runs daily, memories pile up. After a month you’ve got 30+ standup summaries. Semantic search handles this well, but importance scores help prioritize.

I use a simple scheme:

• 0.9-1.0: Corrections, blockers, things that must not be forgotten
• 0.6-0.8: Daily summaries, status updates
• 0.3-0.5: Minor observations, nice-to-knows
• Below 0.3: Probably not worth storing

When recall returns multiple results, higher-importance memories surface first. A blocker from two weeks ago still shows up above yesterday’s routine summary.

The full flow in one script

Here’s a simplified version of what the agent prompt looks like:

You are a daily standup agent. Every morning:

1. Recall recent standup context:
   memoclaw recall "recent standup summaries and open items" --namespace standup --top-k 5

2. Check GitHub activity:
   gh pr list -R myorg/myrepo --state all --limit 10
   gh issue list -R myorg/myrepo --state open --limit 10

3. Compare today's state with recalled context. Note what changed.

4. Post the standup update to Discord.

5. Store today's summary:
   memoclaw store --namespace standup --importance 0.7 --tags "standup,daily"
   Include: open items, merged PRs, new issues, blockers.

Five steps. The agent handles the details. MemoClaw handles the memory.

Cost check

Each cron run does one recall ($0.005) and one store ($0.005). That’s a penny per day. $0.30/month for a daily agent with persistent memory. If you’re on the free tier (100 calls per wallet), that’s 50 days of daily runs before you need to set up x402 payments.

What this unlocks

Once your cron agents have memory, you can build things that weren’t practical before. A deployment monitor that knows the last three deploys failed and escalates automatically. A content scheduler that remembers which topics performed well last month. A personal assistant that tracks your habits and notices patterns over weeks.

The pattern is always the same. Recall, act, store. The cron system gives you the schedule. MemoClaw gives you the continuity.

Your agents don’t have to wake up with amnesia anymore.