Steampunk clockwork mechanism with self-adjusting gears

How to Set Up Self-Improving AI Cron Jobs

Posted by:

|

On:

|

,
Steampunk clockwork mechanism with self-adjusting gears

What if your scheduled AI jobs got a little better every day?

Most scheduled AI tasks run the same prompt forever. If the output is mediocre on day one, it is still mediocre on day thirty, and you pay the same for it. TinkerClaw’s jobs keep notes on their own runs and build on them. Here is how that works, and the one rule I added after it went wrong.

Rewritten 16 October 2026. The March version said the jobs rewrite their own prompts with no human involved. Eight months in, that is the part I changed: the jobs learn freely, but changes to their instructions now come to me first.

The board

Cron run history: job names, model, token count and time of each run
Run history on the cron board. The reports themselves are blurred.

On the day of this screenshot the board held 22 jobs, 18 of them on, with 2,711 runs in the history. A morning briefing, a security check, memory consolidation overnight, a scan of other forks for ideas worth borrowing, a model-ranking refresh. Each run records which model did it and how many tokens it took.

The loop

Each run ends with a review step, and the review has somewhere to go:

  • Do the task. Write the briefing, run the scan, check the updates.
  • Compare. Read the job’s lessons file and the last few runs. Is this better or worse? What did it miss?
  • Write the lesson down. One dated entry in the job’s lessons file, which the next run reads before it starts.
  • Propose, don’t rewrite. If the instructions themselves should change, the job writes the proposed change into its report. I approve it or not.

How to set one up

In OpenClaw and TinkerClaw, a cron job can carry an agentTurn payload that runs in an isolated session, with a fresh transcript every run. The trick is two extra lines in the brief:

Schedule: daily at 08:00
Brief:
  1. Read lessons.md before you start.
  2. Do the task (report, scan, check).
  3. Compare with the last runs: what was missed?
  4. Append one dated lesson to lessons.md.
  5. If the brief itself should change, propose it in the report.

Why a human approves the brief

The first version let jobs rewrite their own prompts. It worked, until it didn’t: a prompt that edits itself drifts, a little each night, toward whatever the last run happened to reward. Lessons are cheap to keep and easy to read back. A changed brief changes every future run, so it gets a second pair of eyes. The jobs still improve on their own; they just can’t redefine their job without asking.

What we saw in the first month

  • Daily engagement report. Day 1 was a wall of numbers. By day 30 it highlighted trends, flagged anomalies and suggested actions.
  • Fork scanner. Day 1 listed forks. By day 30 it sorted them by what they changed and recommended what to borrow.
  • Wind-down summary. Day 1 was a diary. By day 30 it was a plan of fixes to the system.

Your scheduled jobs should know more tomorrow than they do today.

Everything on the site, by topic or date: Browse the Tinker Zone

Built with TinkerClaw. Every tool and experiment on this site runs on TinkerClaw, my open-source fork of OpenClaw. TinkerClaw on GitHub · What we changed in our OpenClaw fork