If you've built something with an AI agent and now want it to run itself — daily, hourly, whatever — the honest answer is that "just add a cron job" undersells how differently the main options behave once your laptop closes or your process crashes at 3am.
Here are the four you'll actually run into, and the specific way each one fails.
1. Claude Code Routines (cloud-hosted)
Routines run in Anthropic's cloud, so they fire even with your machine off. The catch: a routine only loads skills that are committed to the repository it clones. A skill sitting in your personal ~/.claude/skills/ directory is invisible to it.
This is the single most common way people get "success" with the wrong behavior — the routine doesn't error when it can't find your skill, it just improvises something plausible-looking instead. That output can pass a glance and still be nothing like what the skill would have produced.
Fix: install skills at project scope, commit them, and run a command that lists the committed skill files before you schedule anything against them.
2. Hermes (local scheduler with real cron)
Hermes gives you actual cron semantics and can hold credentials locally. The tradeoff is availability: it only fires while Hermes itself is running. Close the app, and the schedule is dead until you reopen it — no catch-up, no backfill.
3. Codex (no scheduler of its own)
Codex doesn't ship a scheduler. You wrap codex exec in launchd, systemd, or a CI cron trigger yourself. This gives you the most control, but also means you own every failure mode those tools have — including the one below.
4. CI (GitHub Actions, etc.)
This is the one that doesn't care whether your laptop is open. It's the right home specifically whenever a missed run loses data permanently — most commonly analytics, which usually has no backfill path. A closed laptop overnight silently loses that day's numbers with the other three options; CI just runs.
The credentials rule that saves you a bad afternoon
Whichever scheduler you pick, don't let the scheduled agent hold your API keys directly. The pattern that holds up: a separate collector process holds credentials, calls the third-party APIs, and writes sanitized JSON into your repo. The scheduled agent then only ever reads numbers out of git — it never touches a secret. If a scheduled step seems to need a credential, that's usually a sign the step is in the wrong layer, not that you need a secrets manager for the agent itself.
Verifying it's actually working
A green status tells you the process didn't crash. It tells you nothing about whether it did the right thing. Two checks that catch this:
- Run it once by hand and confirm the target file actually changed.
- Run it twice back-to-back with nothing new to do, and confirm the second run reports a no-op rather than silently claiming success again.
If you've never watched your scheduled job fail on purpose, you don't actually know what "failure" looks like in your logs — which means you won't recognize it when it happens for real.
We hit all four of these running a small fleet of scheduled agents across three sites, which is where the credentials-separation pattern above came from — it's now baked into the Distribution Autopilot Kit for anyone who wants the layering pre-built rather than assembled by hand. But the four options and their failure modes above are true regardless of what you're running.
Full answer: https://agentkitworks.com/answers/how-to-run-an-ai-agent-on-a-schedule
Top comments (0)